Re: [Gen-art] Genart last call review of draft-ietf-spring-segment-routing-ldp-interop-11

[Ahmed Bashandy <[e-mail]>]

thanks for the review again

I  uploaded version 12 of the draft containing section 4.2.1 giving an 
overview of the mapping server

Thanks

Ahmed

On 5/21/18 9:13 AM, Joel Halpern Direct wrote:
> 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:
>>>
>>>
>>