Skip to main content

Last Call Review of draft-ietf-ospf-ospfv3-segment-routing-extensions-16
review-ietf-ospf-ospfv3-segment-routing-extensions-16-opsdir-lc-clarke-2018-10-26-00

Request Review of draft-ietf-ospf-ospfv3-segment-routing-extensions
Requested revision No specific revision (document currently at 23)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2018-11-16
Requested 2018-10-23
Authors Peter Psenak , Stefano Previdi
I-D last updated 2018-10-26
Completed reviews Genart Telechat review of -19 by Pete Resnick (diff)
Genart Last Call review of -18 by Pete Resnick (diff)
Secdir Last Call review of -16 by Yaron Sheffer (diff)
Rtgdir Last Call review of -17 by Tomonori Takeda (diff)
Opsdir Last Call review of -16 by Joe Clarke (diff)
Assignment Reviewer Joe Clarke
State Completed
Request Last Call review on draft-ietf-ospf-ospfv3-segment-routing-extensions by Ops Directorate Assigned
Reviewed revision 16 (document currently at 23)
Result Has nits
Completed 2018-10-26
review-ietf-ospf-ospfv3-segment-routing-extensions-16-opsdir-lc-clarke-2018-10-26-00
I have been assigned to review 
draft-ietf-ospf-ospfv3-segment-routing-extensions  on behalf of the ops
directorate.  This document defines OSPFv3 extensions needed for segment
routing (SR).  And therein lies my first nit.  While the document begins to set
forth this overarching scope, a small paragraph in section 1 further limits it
to MPLS dataplanes only.  I think perhaps the abstract should be updated to
clarify that.

Other items I found are listed below.

Overall, there are a lot of terminology used like RSVP, LDP, LSP, SID, etc.  I
think this document would benefit from a terminology section.

With respect to TLV types 8, 9, 14, and 15, they are defined in
draft-ietf-ospf-segment-routing-extensions, and it took me a while to figure
out where you were getting those values and why they weren't spelled out in the
IANA considerations.  You have a normative reference to this, which is good,
but you only mention it with respect to the algorithm parameters.  I think
another mention is required.

I'm going to be pedantic here.  According to RFC7770, when a new OSPF Router
Information LSA TLV is defined, the spec needs to explicitly state if it's
applicable to OSPFv2, v3, or both.  While you reference the TLVs from
draft-ietf-ospf-segment-routing-extensions, I didn't see that either document
_explicitly_ states that they are applicable to both.

===

Section 2.1

s/length is other then 3 or 4/length is other than 3 or 4/

===

Section 3.2

s/If more then one SID/Label/If more than one SID/label/

===

Section 3.2

"When a router receives multiple overlapping ranges, it MUST
      conform to the procedures defined in
      [I-D.ietf-spring-segment-routing-mpls]."

It would be useful to include a section pointer here.  I think your referring
to Section 2.3 where the router ignores the range?   Is it likely that will
change to something other than "ignore?"  If not, maybe it's just worth
mentioning that here.

===

Section 3.3

s/If more then one SID/Label/If more than one SID/Label/

===

Section 3.3

"The originating router MUST NOT advertise overlapping ranges."

You specify what a router should do if it receives overlapping ranges above.  I
think the same text should be used here, too.

===

Section 5

"Other bits: Reserved.  These MUST be zero when sent and are
         ignored when received."

The normative language changes.  In other places you say the bits SHOULD be 0. 
I suggest:

Other bits: Reserved.  These SHOULD be set to 0 when sent and MUST be ignored
when received.

===

Section 7.4.1

s/state lower then 2-Way/state lower than 2-Way/

===