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

["Ahmed Bashandy (bashandy)" <[e-mail]>]

Les replied to that on the thread "[spring] AD Review of 
draft-ietf-spring-segment-routing-12"

So Les and I are still working to resolve some overlap between 
architecture document and sr mpls document and we hope to have new 
versions soon.

Ahmed


On 11/30/2017 2:26 PM, Alvaro Retana wrote:
> Ahmed:
>
> Hi!
>
> It’s been almost a month, and I haven’t seen a reply from you.
>
> I will send the document back to the WG by the end of this week.
>
> Thanks!
>
> Alvaro.
>
> On November 2, 2017 at 6:49:10 PM, Alvaro Retana 
> ([e-mail] <mailto:[e-mail]>) wrote:
>
>> On October 30, 2017 at 2:12:18 PM, Ahmed Bashandy (bashandy) 
>> ([e-mail] <mailto:[e-mail]> ) wrote:
>>
>> Ahmed:
>>
>> Hi!  How are you?
>>
>> ...
>>
>>> The main questions/concerns that I have related to this document is 
>>> not just for the authors, but for the Shepherd and the Chairs too.
>>>
>>> Q1. Why is this document on the Standards Track? From the 
>>> Introduction: “This drafts describes how Segment Routing operates on 
>>> top of the MPLS data plane.”  Describes, yes.  On the other hand, 
>>> the Shepherd’s write-up says that it “specifies the generic 
>>> functions of the architecture” – I don’t see a specification, just a 
>>> description.  As such, I think this document should be Informational.
>>>
>>> #Ahmed: The new version of the draft specifies many things that are 
>>> applicable to instantiation of SR over MPLS
>>>
>> I’ll take your answer as confirming that the old version (-10) wasn’t 
>> really specifying anything.
>>
>> For this new version (-11), can you please be specific on what these 
>> “many things” are?
>>
>> I see some new Normative Language in the new 2.x sub-sections.  I 
>> have some specific comments on that:
>>
>> Q1.A. Section 2.2. (SID Representation in the MPLS Forwarding Plane):
>>
>> The MCC MUST ensure that any label value corresponding to any SID it
>>     installs in the forwarding plane follows the following rules:
>>
>>     o  The label value MUST be unique within the router on which the MCC
>>        is running. i.e. the label MUST only be used to represent the SID.
>>
>>     o  The label value MUST NOT be identical to or within the range of
>>        any reserved label value or range [reserved-MPLS  <https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-11#ref-reserved-MPLS>], respectively.
>>
>>
>> These seem to be new requirements for the MCCs. Given that the protocol extensions (and LDP) are defined (in Section 2) as MCCs, how are they supposed to follow these rules, specially the first one? As far as I can tell, the IGP extensions (for example) can carry Label/SID information from an advertising node, so I don’t know how a local MCC (remote to that advertising node, which is locally "installing forwarding entries in the MPLS data plane”) can guarantee what the label is used for (“only used to represent the SID”). Maybe I’m missing something and this is already specified somewhere else…??
>> The second rule is just what the MPLS Architecture already specifies, 
>> no nothing new, right? BTW, the link in the reserved-MPLS reference 
>> doesn’t work — a better reference might be rfc3032 or rfc7274.
>>
>>
>> Q1.B. Section 2.3. (Segment Routing Global Block and Local Block):
>>
>> The following rules apply to the list of MPLS ranges representing the
>>     SRGB
>>
>>     o  The list of label ranges MUST only be used to instantiate global
>>        SIDs into the MPLS forwarding plane
>>
>>     o  Every range in the list of ranges specifying the SRGB MUST NOT
>>        cover or overlap with a reserved label value or range [reserved-
>>        MPLS], respectively.
>>       . . .
>>     Just like SRGB, the SRLB need not be a single
>>     contiguous range of label, except the SRGB MUST only be used to
>>     instantiate global SIDs into the MPLS forwarding plane.
>>
>> The first rule (and the text below them) points to the global nature 
>> of the SR *global* Block. The architecture document already says that 
>> "In SR-MPLS, SRGB is a local property of a node and identifies the 
>> set of local labels reserved for global segments.” Nothing new 
>> specified here.
>>              
>>
>>                                    
>> Q1.C. Section2.4. (Mapping a SID Index to an MPLS label) introduces an algorithm to calculate the label value.  Note that the architecture document now includes an algorithm (in Section 3.1.2) as well — the algorithm in this document doesn’t look to be the same, but even if it is, it would be confusing to specify the same thing in two places.
>>                    
>>                    
>>                    
>> Q1.D. The rest of the sub-sections seem to rehash forwarding behaviors, which, because of the fact that the MPLS architecture is not changing, seem to add nothing interesting or important to this document.
>>                    
>>
>> Having said all that, I still don’t see a clear justification for this document to be in the Standards Track.
>>                            
>>>
>>> Q2. Section 2. (MPLS Instantiation of Segment Routing) is the only 
>>> one with any real content…but there are only a couple of things in 
>>> it that are not in the Architecture document: the introduction of 
>>> the SRLB, and some words about the index – both of which should be 
>>> really explained in the Architecture document, and not here.  I 
>>> wonder what the value of publishing this document really is. What 
>>> long-term archival value does it provide?
>>>
>>> #Ahmed: The long term plan is to move details of MPLS-specific 
>>> specifications to this document and keep the architecture document 
>>> more general
>>>
>> The “long term plan” ??  What do you mean?  The architecture document 
>> is already in IETF Last Call — are you saying that both documents 
>> still require more changes and are not ready for publication?  I 
>> really hope that is not what you mean.
>>
>> In any case, you did not answer my question about the value of the 
>> document as is.  No worries, the intent is not to stop publication, 
>> but to understand whether there is something I’m missing and the 
>> relationship to the proposed Status.
>>
>>
>>> Q3. I also have to wonder about the IPR declared for this document.  
>>> If most of the information here is already defined, described or 
>>> specified in draft-ietf-spring-segment-routing, should the IPR 
>>> declaration apply to that document as well (or maybe instead of this 
>>> one)?  It is not the IETF’s role (including the WG) to discuss 
>>> whether a piece of IPR is valid or not – I just want to make sure 
>>> the disclosures apply to the right document.
>>>
>>> #Ahmed: We will make sure that all IPR is declared
>>>
>> That was not my question!   And declaring IPR at this point in time 
>> is very, very late (rfc6701).
>>
>>
>>> I didn’t find a discussion on the list about any of these points.
>>>
>> I am concerned about all the text that has been added (which in my 
>> opinion doesn’t contribute much to the document), resulting in about 
>> a 70% increase the document length!  I will wait for your answer to 
>> my points above before returning the document to the WG for a 
>> thorough review.
>>
>>
>> I have some other specific comments below.
>>
>> Thanks!
>>
>> Alvaro.
>>
>> ...
>>
>>> P3. Section 2. (MPLS Instantiation of Segment Routing) says that “a 
>>> controller-driven network…MAY use the control plane to discover the 
>>> available set of local SIDs”.  The “MAY” implies that there is a 
>>> choice (i.e. it is optional) and that other discovery mechanisms 
>>> exist.  What are those other choices?  Note that earlier in this 
>>> section you already wrote that IGPs are used for flooding the 
>>> information. s/MAY/may
>>>
>>> #Ahmed: This document gives an example of a use of the SRLB. Listing 
>>> all possible uses of the SRLB is certainly not within the scope of 
>>> this document.
>>>
>> I’m not sure what your answer has to do with my comment…but giving 
>> examples is a good reason to *not* use Normative language.
>>
>> In any case, that piece of text was not changed from:
>>
>> In a controller-driven network, some controllers or
>>     applications MAY use the control plane to discover the available set
>>     of local SIDs on a particular router.  In such cases, the SRLB is
>>     advertised in the control plane (e.g., using
>>     [I-D.ietf-isis-segment-routing-extensions  <https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-10#ref-I-D.ietf-isis-segment-routing-extensions>]).
>>
>>                  
>>   …to…
>>                        
>> In a controller-driven network, some controllers or
>>     applications MAY use the control plane to discover the available set
>>     of local SIDs on a particular router [I.D. filsfils-spring-segment-
>>     routing-policy].
>>
>> The “MAY” is still there (which was the main point of the comment above), and you added a new reference to apparently illustrate the point that the control plane can be used "to discover the available set of local SIDs on a particular router”.  Isn’t that already specified in the architecture document?  Why do we need this new reference?
>>                        
>>                        
>> ...
>>>
>>> P5. References. Please take a look at rfc8174 and update the 
>>> “Requirements Language” and associated references.
>>>
>>> #Ahmed: I agree. I modified the paragraph about requirements 
>>> language to conform to rfc8174
>>>
>> You forgot to include the rfc8174 reference.
>>
>>> Nits
>>>
>>> N1. I think that the references to *-segment-routing-extensions are 
>>> superfluous.  BTW, the fourth paragraph of the Introduction uses a 
>>> reference to *-segment-routing-extensions to point at ISIS/OSPF (the 
>>> protocols!).
>>>
>>> #Ahmed: I agree. Now we have clear references to each IGP extensions 
>>> separately
>>>
>> The point was that I think all references to the extensions are 
>> superfluous — not a request to add them.
>>