Subject: Opsdir last call review of draft-ietf-mpls-sr-over-ip-02

From: Al Morton <[email-masked]>
Date: Sat, 16 Feb 2019 13:07:34 -0800

Reviewer: Al Morton
Review result: Has Nits

Thanks for preparing this draft.
Providing transition methods is very welcome to
Operations.

These comments are best viewed with a monospace font, 
and should be treated as any Last Call comments (and optional).

There seem to be a few more opportunities to employ
Requirements Language in this draft (currently only
3 MUSTs and 2 MAYs), to improve the consistency of 
implementations and subsequent adoption in operations.

For example:
Section 2:
   o  Incremental deployment of the SR-MPLS technology may be
      facilitated by tunneling SR-MPLS packets across parts of a network
      that are not SR-MPLS enabled using an IP tunneling mechanism such
      as MPLS-in-UDP [RFC7510].  The tunnel destination address is the
	                                                           ^^^^
      address of the next SR-MPLS capable node along the path (i.e., the
      egress of the active node segment).  This is shown in Figure 1.

	  Setting the Dst address correctly seems to be a requirement,
because this material in Section 2 is referenced later, in 3.2.3.
This seems a reasonable spot for s/is/SHOULD be/ at least.

Section 3.1 FIB construction relies on about 5 drafts: 
much work in progress, just noting dependencies (no action)

SRGB - ?? spell-out at first use

Section 3.2.3. Additional Forwarding Procedures
... 
      IP Header Fields:  When encapsulating an MPLS packet in UDP, the
      resulting packet is further encapsulated in IP for transmission.
      IPv4 or IPv6 may be used according to the capabilities of the
      network.  The address fields are set as described in Section 2.
	                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      The other IP header fields (such as DSCP code point, or IPv6 Flow
      Label) on each UDP-encapsulated segment can be set according to
	                                          ^^^^^^^^^^
      the operator's policy:
Suggest:
s/can be set/SHOULD be configurable/

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 17 Feb 2019 11:18:59 -0000

Hi Al,

Thanks very much for reviewing.

Responses in line.

> Providing transition methods is very welcome to

We aim to please 😊

> implementations and subsequent adoption in operations.

You are right.
The original vision for this document was Informational (telling you how to use existing tools), so the Requirements language only crept in as we moved to Standards Track, and we should probably have more of it.

> This seems a reasonable spot for s/is/SHOULD be/ at least.

Well, in this specific case I'm going to agree with you, but for a different reason. You don't set a destination address, you pick a tunnel that has an end point.

So we should probably write...
OLD
      The tunnel destination address is the
      address of the next SR-MPLS capable node along the path (i.e., the
      egress of the active node segment).
NEW
      The tunnel selected MUST have its remote end point (destination)
      Address equal to the address of the next SR-MPLS capable node 
      along the path (i.e., the egress of the active node segment).
END

> much work in progress, just noting dependencies (no action)

Yes, it is sad for me that the SR work still lingers in the pipe.

> SRGB - ?? spell-out at first use

Good catch.
Segment Routing Global Block

>.... 

Yes

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Sun, 17 Feb 2019 13:46:19 +0000

Thanks Adrian.

@OPS-DIR - consider these comments resolved.

Al

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]]
> Sent: Sunday, February 17, 2019 6:19 AM
> To: MORTON, ALFRED C (AL) <[email-masked]>; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: Opsdir last call review of draft-ietf-mpls-sr-over-ip-02
> 
> Hi Al,
> 
> The original vision for this document was Informational (telling you how
> to use existing tools), so the Requirements language only crept in as we
> moved to Standards Track, and we should probably have more of it.
> 
> > For example:
> > Section 2:
> Well, in this specific case I'm going to agree with you, but for a
> different reason. You don't set a destination address, you pick a tunnel
> that has an end point.
>