Thank you. I apologize for missing the other normative items. With
those, plus the elaboration on the SRMS, the status as PS makes good sense.
Yours,
Joel
On 5/21/18 11:45 AM, Ahmed Bashandy wrote:
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: