Re: [mpls] Opsdir last call review of draft-ietf-mpls-sr-over-ip-02

["MORTON, ALFRED C (AL)" <[e-mail]>]

Thanks Adrian.

@OPS-DIR - consider these comments resolved.

Al

> -----Original Message-----
> From: Adrian Farrel [mailto:[e-mail]]
> Sent: Sunday, February 17, 2019 6:19 AM
> To: MORTON, ALFRED C (AL) <[e-mail]>; [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: RE: Opsdir last call review of draft-ietf-mpls-sr-over-ip-02
> 
> Hi Al,
> 
> Thanks very much for reviewing.
> 
> Responses in line.
> 
> > Thanks for preparing this draft.
> > Providing transition methods is very welcome to
> > Operations.
> 
> We aim to please 😊
> 
> > 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.
> 
> 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.
> 
> > 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.
> 
> 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
> 
> > Section 3.1 FIB construction relies on about 5 drafts:
> > 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
> 
> > 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/
> 
> Yes