Skip to main content

Last Call Review of draft-ietf-mpls-sr-over-ip-02

Request Review of draft-ietf-mpls-sr-over-ip
Requested revision No specific revision (document currently at 07)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2019-02-26
Requested 2019-02-12
Authors Xiaohu Xu , Stewart Bryant , Adrian Farrel , Syed Hassan , Wim Henderickx , Zhenbin Li
I-D last updated 2019-02-16
Completed reviews Rtgdir Last Call review of -02 by Eric Gray (diff)
Opsdir Last Call review of -02 by Al Morton (diff)
Genart Last Call review of -02 by Robert Sparks (diff)
Tsvart Last Call review of -03 by Martin Stiemerling (diff)
Assignment Reviewer Al Morton
State Completed
Review review-ietf-mpls-sr-over-ip-02-opsdir-lc-morton-2019-02-16
Reviewed revision 02 (document currently at 07)
Result Has nits
Completed 2019-02-16
Thanks for preparing this draft.
Providing transition methods is very welcome to

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:
s/can be set/SHOULD be configurable/