Re: [spring] AD Review of draft-ietf-spring-segment-routing-12

[stefano previdi <[e-mail]>]

> On Nov 1, 2017, at 8:55 PM, Alvaro Retana <[e-mail]> wrote:
> 
> On October 28, 2017 at 10:51:52 AM, Les Ginsberg (ginsberg) ([e-mail] ) wrote:
> Les:
> 
> Hi!
> 
>> Apologies for the long delay in responding. The transference of the pen from Stefano resulted in a longer delay than it should have.
>> 
> Thanks for taking this on!  
> 
> As a new author: are you aware of any undeclared IPR for this document?
> 
>> A new version has been published which addresses your comments. Specific replies inline.
>> 
> My replies (to what I think still needs work or answers to questions) are below.
> 
> In general, I think that the definition of “SR Domain” still needs work.  I would also strongly recommend that you include a Deployment/Operations Section.


what exactly would you expect to find in such section ? We have the Manageability section which illustrates how SR can be managed. An operation/deployment section will have to be exhaustive and illustrative on the different use-cases that SR addresses and hence can become pretty large. 

To my view, the draft focuses on architecture, not on deployment or operation. These are mostly described in the different use-cases drafts.


> The update looks like a lot of changes: more than 400 lines (according to rfcdiff) — but I think they are mostly clarifying.  


indeed, not a single change in the architecture has been introduced or changed.


> Instead of returning the document to the WG, I am going to start an IETF Last Call for this document — it will be extended (4 weeks) to account for the upcoming meeting in Singapore, US Holidays and to give the WG an opportunity to re-review.


many thanks!

s.


> 
> Thanks!
> 
> Alvaro.
> 
> 
> 
> ...
> 
>> Major:
>> 
>>  
>> M1. The Introduction mentions several types of segments, and it says that the LDP LSP, RSVP-TE LSP, and BGP LSP segments are “illustrated in [I-D.ietf-spring-segment-routing-mpls]”.  But that is only true for the first two, for which examples are shown.  Where are these segment types defined?  The definition, and not the examples, is the Major issue here.  This document being the main architecture document should include the complete description.  BTW, the list is only about the “MPLS instantiation”, are there similar types of segments for IP?
>> 
>>  
>> [Les:] The list has been modified – but some definitions will still be found in [I-D.ietf-spring-segment-routing-mpls] where it makes sense to do so. We prefer that so that we do not duplicate definitions.
>> 
> Ok — I would have preferred the definitions to show up here, but it’s ok, as long at they are defined somewhere.
> 
> I went to look at the most recent version of I-D.ietf-spring-segment-routing-mpls (-11), but there’s no definition of those segments.  <sigh> :-(    I’ll take a look at that document and see if they’re needed.
> 
> 
> 
> 
> 
>> M2. From Section 2. (Terminology): “Using the same SRGB on all nodes within the SR domain ease operations and troubleshooting and is expected to be a deployment guideline.”  It is “expected to be a deployment guideline” where/when??  Given that this document is the general architecture, I figured that maybe draft-ietf-spring-segment-routing-mpls contained that deployment recommendation, but all that document says is: “As described in [I-D.ietf-spring-segment-routing], using the same SRGB on all nodes within the SR domain eases operations and troubleshooting and is expected to be a deployment guideline.”  So…where are the Deployment/Operational considerations related to the SRGB?  I note that neither document (draft-ietf-spring-segment-routing or draft-ietf-spring-segment-routing-mpls) include them.  I would expect some information to be in this (general) document and other more specific information (like the considerations about using the same SRGB) to be in the more specific document (draft-ietf-spring-segment-routing-mpls, in this case).
>> 
>>  
>> [Les:] Definition of the SRGB has been enhanced and the definition of an SR Domain has been introduced and discussed. We hope this clarifies deployment considerations as regards SRGB/SRLB.
>> 
> SR Domain was already defined — the difference seems to be the somewhat nebulous new text:
> 
>    
> Segment Routing Domain (SR Domain)...If multiple protocol instances are
>    deployed, the SR domain most commonly includes all of the protocol
>    instances in a single SR domain.  However, some deployments may wish
>    to sub-divide the network into multiple SR domains, each of which
>    includes one or more protocol instances.  It is expected that all
>    nodes in an SR Domain are managed by the same administrative entity. 
> 
> …which makes the definition depend on itself: "SR domain most commonly includes all of the protocol instances in a single SR domain” (the domain includes all the instances in the domain)…
> 
> Note that one of the point above was the lack of Deployment/Operational Considerations in this document — the added text above opens the door even more for such considerations: when would someone decide to sub-divide the network into multiple domains?  What might the considerations be?
> 
> As for the SRGB definition, you did take out the part about “using the same SRGB…is expected to be a deployment guideline” and changed it to it being “strongly recommended”.  I still have the same question as before: what are the Deployment/Operational considerations related to the SRGB?  You did keep the text about how it “eases operations and troubleshooting”, but didn’t provide guidance related on when/why.  
> 
> BTW, 3.1.2 says that "Where possible, it is recommended that a consistent SRGB be configured on all nodes in an SR Domain.” — I’m assuming “consistent” is the same as “the same”...
> 
> In short, the changes didn’t really help me.  I think that this document (which introduces a new technology) should have an Operational Considerations section; take a look at rfc5706.
> 
> 
> 
> ...
> 
>> M3. From Section 2. (Terminology): “…a global segment is represented by a globally-unique index.” 
>> 
>>  
>> M3.1.  I couldn’t find anywhere a discussion about the use of the index.  When it is discussed in 3.1.2, it seems to be an understood concept: “A Prefix-SID is allocated in the form of an index in the SRGB…”  Even if straightforward, I think the concept of the index should be explained (maybe with an example) and not assumed.  I again went to look at draft-ietf-spring-segment-routing-mpls, but that document just points back to this one: “The notion of indexed global segment, defined in [I-D.ietf-spring-segment-routing]…”
>> 
>>  
>> [Les:] Definition of SID has been made more explicit and how an index is used to obtain the Segment in the SR MPLS case has been explicitly defined in Section 3.1.2.
>> 
> Thanks for that…one question, I didn’t understand what "X is the 0 based index” means in the algorithm.
> 
> 
> 
> ...
> 
>> M7. Section 3.4. (IGP-Adjacency Segment, Adj-SID) also tries to explain functionality starting from the extensions.
>> 
>>  
>> [Les:] Here as well we have removed references to IGP specifics and discussed the functionality on its own.
>> 
>>  
>> M7.1. “The encodings of the Adj-SID include the a set of flags among which there is the B-flag.  When set, the Adj-SID refers to an adjacency that is eligible for protection (e.g.: using IPFRR or MPLS-FRR).”  If the Adjacency Segment is one that is locally significant to the node advertising it, what is the purpose of signaling that it is eligible for protection?  Wouldn’t that be a local decision as well?  Maybe an example of how the architecture is expected to work would help.
>> 
> I still have the same question: what is the purpose/value to signal whether an Adj-SID is eligible for protection?  Isn’t that a local decision anyway?
> 
> 
> 
> ...
> 
>> M8. Section 3.5. (Binding Segment).  A binding segment is not described anywhere in this document – please do so!  Section 3.5.1. (Mapping Server) mentions a “Remote-Binding SID S advertised by the mapping server”, and says that more “details are described in the SR/LDP interworking procedures ([I-D.ietf-spring-segment-routing-ldp-interop]”, but that draft doesn’t mention a Binding Segment.  Section 5. (IGP Mirroring Context Segment) says that “the binding segment [is] defined in SR IGP protocol extensions ( [I-D.ietf-isis-segment-routing-extensions], [I-D.ietf-ospf-segment-routing-extensions] and [I-D.ietf-ospf-ospfv3-segment-routing-extensions])”; however, those documents don’t mention a Binding Segment, they just (except for the OSPFv2 draft) define TLVs.  Note that I-D.ietf-ospf-segment-routing-extensions points back to this document when referring to the definition of a Binding SID, completing a circular reference.
>> 
>>  
>> [Les:] Section on Binding Segment has been rewritten and the  Mirror Context discussion is a sub-section of that section.
>> 
> It seems to me that the description is not as clear as it could be.  The initial sentence sounds general enough so that any/all SR Policy is bound/related to a BSID.  Suggestion: start the description with the motivation.
> 
> 
> 
> ...
> 
>> M10. Section 3.6. (Inter-Area Considerations) 
>> 
>>  
>> M10.1. This section shows an example of the behavior: maintain the SID across area boundaries.  But it doesn’t actually say how the architecture is expected to work.  IOW, in the example the SID is maintained, but should that always happen (MUST, SHOULD)? Or is it just an example (MAY)?
>> 
>>  
>> [Les:] With the introduction of the “SR Domain” definition we believe this point is now clarified.
>> 
> Please see my comments above about the SR Domain definition.  I need you to walk me through how that definition (which just says that there may be one or more domains) clarifies the inter-area behavior in the example.
> 
> 
> 
> ...
> 
>> Minor:
>> 
>>  ...
>> 
>> P1.4. Speaking of use cases, I-D.ietf-spring-oam-usecase doesn’t actually include use cases that will affect the architecture.  It includes use case of how to use monitoring system defined in it.  Same comment for the mention in Section 9.
>> 
> The document is still referenced in Section 9 as a use case document.
> 
> 
> 
> ...
> 
>> Nits:
>> 
>> ... 
>> 
>> N9. s/([I-D.ietf-spring-segment-routing-ldp-interop]/[I-D.ietf-spring-segment-routing-ldp-interop]
>> 
>> 
>>  
>> 
>> [Les:] I do not see what you are correcting here. ???
>> 
> There’s an extra “(“.
> 
> 
> 
> ...
> 
>> N11. It would be nice if the examples used IPv6 instead of IPv4.
>> 
>> [Les:] Hmmm…the Inter-area example does use IPv6, but the anycast example uses IPv4. Is this now forbidden?
>> 
> No, just trying to play nice with others — just a nit.
>