Thanks a lot for the review

The document specifies externally visible behavior that must be implemented by routers, otherwise SR and LDP routers cannot talk to each other. For example, section 4.2.2  specifies preference rules. Another example is the last two paragraphs in section 4.2.1. Hence I do not think it can be informational. A third example is section 4.2 which requires the existence of one SRMS in order for SR-only to speak to LDP-only routers

But I agree that a more crisp description of SRMS is warranted. I will add a section describing the SRMS functionality and specifying what to do when receiving both prefix-SID sub-tlv and SRMS advertisements in the next version, which I plan to send out in the next few days


Ahmed



On 5/14/18 1:01 PM, Joel Halpern wrote:
Reviewer: Joel Halpern
Review result: Ready with Issues

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

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-spring-segment-routing-ldp-interop-11
Reviewer: Joel Halpern
Review Date: 2018-05-14
IETF LC End Date: 2018-05-24
IESG Telechat date: Not scheduled for a telechat

Summary: This document appears to be ready for publication as an RFC.  The
question of whether it is an Informational RFC or a Proposed Standards track
RFC is one that the ADs should examine.

Major issues:
     This document is quite readable, and quite useful.  If my reading below
     (minor comment about section 4.2) is wrong, then everything is fine.
     However, reading the text, it does not appear to define SRMS.  Rather, it
     describes a good way to use SRMS to achive smooth SR - LDP integration and
     migration.  As such, this seems to me to be a really good Informational
     Document.

Minor issues:
     Section 4.2 states that it defines the SRMS (Segment Routing Mapping
     Server).  Looking at the relevant routing protocol document, they point to
     https://tools.ietf.org/html/draft-ietf-spring-conflict-resolution-05 as the
     defining source for the SRMS.  And that document does appear to define the
     SRMS.

Nits/editorial comments:



_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Reply via email to