Skip to main content

Last Call Review of draft-ietf-ospf-segment-routing-extensions-19

Request Review of draft-ietf-ospf-segment-routing-extensions
Requested revision No specific revision (document currently at 27)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2017-10-13
Requested 2017-09-29
Authors Peter Psenak , Stefano Previdi , Clarence Filsfils , Hannes Gredler , Rob Shakir , Wim Henderickx , Jeff Tantsura
I-D last updated 2017-10-05
Completed reviews Rtgdir Early review of -12 by Stig Venaas (diff)
Opsdir Last Call review of -17 by Susan Hares (diff)
Rtgdir Last Call review of -16 by John Drake (diff)
Genart Last Call review of -19 by Dan Romascanu (diff)
Genart Telechat review of -22 by Dan Romascanu (diff)
Assignment Reviewer Dan Romascanu
State Completed
Request Last Call review on draft-ietf-ospf-segment-routing-extensions by General Area Review Team (Gen-ART) Assigned
Reviewed revision 19 (document currently at 27)
Result Ready w/issues
Completed 2017-10-05
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at


Document: draft-ietf-ospf-segment-routing-extensions-19
Reviewer: Dan Romascanu
Review Date: 2017-10-05
IETF LC End Date: 2017-10-13
IESG Telechat date: Not scheduled for a telechat


A useful and well-written document. It requires previous reading and
understanding of OSPF, SPRING and other routing work. It is Ready for
publication. I found some unclear minor issues. I recommend to address them
before approval and publication.

Major issues:

Minor issues:

1. I am wondering why, at this stage of progress of the document, the type
values are still 'TBD, suggested value x'. Is there any other document defining

2. Section 3.1 - are there other algorithms planned to be added in the future?
If yes, do we need a registry? If no, what is this field an octet?

3. It would be useful to mention that the Length fields are expressed in
Octets. Also please clarify if padding is applied or not.

4. Section 3.3:

'The originating router MUST NOT advertise overlapping ranges.'

How are conflicts resolved at receiver?

5. I like Section 9 - Implementation Status - which I found rather useful. Is
there any chance to keep a trimmed down version of it, with synthetic
information on the lines of 'at the time the document was discussed a survey
was run, it showed that there were x implementation, y were implementing the
full specification, z were included in released production software ....'

6. Section 10 - beyond recommending the counting and logging of the mal-formed
TLVs and sub-TLVs, should not supplementary security recommendations be made?
for example - throttling mechanisms to preempt DoS attacks.

Nits/editorial comments: