Re: [spring] I-D Action: draft-ietf-spring-segment-routing-mpls-12.txt

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

Hi Alvaro

sorry for the late reply.

I am including the questions and comments in the link [1] and the reply 
to each one of them
See "Ahmed" underneath each question and comment



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.

This document specifies concepts and externally visible behaviors such as
- Specifies what "MPLS Instantiation of Segment Routing" means
- Specifies the rules governing the value of the local label 
corresponding to a SID
- Specifies the rules governing the SRGB and and SRLB
- Specifies what to do when a router violates the rules governing the SRGB
- Defines and addresses incoming label collision
- Specifies rules governing redistributing prefixes that have prefix-SIDs
- Defines and addresses Outgoing Label Collision
- details for the forwarding behavior including what to do when some or 
all next-hops are not SR capable

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:
This question is answered within the reply to Q1


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:
I believe we made all the relevant IPR declarations. But if you think 
that some IPR applicable to draft-ietf-spring-segment-routing are also 
applicable to this draft we will make these declarations also towards 
this draft


M1. Section 2. (MPLS Instantiation of Segment Routing) explains how “in 
the MPLS instantiation, the SID values are allocated within a reduced 
20-bit space out of the 32-bit SID space.”  However, I couldn’t find 
where draft-ietf-spring-segment-routing defines the SID space as using 
32 bits (or any other length).  In fact, the closest that document comes 
is when it defines an SID and mentions “Examples of SIDs are: an MPLS 
label, an index value in an MPLS label space, an IPv6 address.”   I’m 
assuming the “32-bit SID space” comes from the fact that the extensions 
define an SID of that length.  All this is to say that as you describe 
how SR operates in the MPLS dataplane, do so not explicitly depending on 
the implementation of the extensions (which in fact seem to already 
account for different lengths).
Ahmed:
this new version (version 12) gives extensive and specific details about 
how to calculate the local and outgoing label  given the SID index

M2.1. “The notion of indexed global segment, defined in 
[I-D.ietf-spring-segment-routing]…”  That document doesn’t properly 
define the concept/use of the index.  There are several mentions in this 
document that I think rely on a proper definition/discussion of the concept.
Ahmed
the new version (version 12) clearly specifies the use of the index and 
how it is translated to local and outgoing labels

M2.2. The concept of an SRLB is not defined in the Architecture document either.
Ahmed:
Addressed in this version (version 12)


M3.1. [minor] I hope to see an explanation of the “[SRGB(next_hop)+index]” notation.
Ahmed
This version clearly addresses this part in section 2.4 by specifying the structure of SRGB and how to calculate the label given the SRGB ranges

M3.2. What is a “valid SRGB”?  I don’t think the validity of the SRGB is described in the Architecture document.
Ahmed
This version clearly specifies the rules governing the SRGB and specifies what other routers do when receiving SRGB advertisements that do not conform to these rules


M3.3. I’m assuming that once the “next-hop MUST be considered as not supporting” then the packets are dropped, right?
Ahmed
This version clearly specifies the forwarding behavior in section 2.10 and what to do when the next-hop does not support segment routing


M3.4. [Maybe I’m missing something obvious here.]  Going back to the validity of the SRGB advertised by a specific node, shouldn’t the ingress node verify that before imposing a path that will fail?  But I couldn’t find anything in the Architecture document that talks about the ingress node verifying that the path is valid (including the validity of the SRGB).
Ahmed
The version specifies what to do for the topmost label. Section 2.10 refers to [I.D.filsfils-spring-segment-routing-policy] when there is a need to calculate the labels underneath the topmost label


M4. Still in Section 2: “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.”  As I mentioned in my review of the Architecture document, that document doesn’t contain deployment guidelines related to the SRGB, and it doesn’t describe how “using the same SRGB…eases operations and troubleshooting”.
Ahmed:
We removed this paragraph


P1. The term “service chain” is used in the Abstract.  Given that the concept is not vital to the architecture and that there might be unnecessary confusion with SFC, I would suggest taking it out.
Ahmed
we removed this term


P2. Informative References to VPN, VPLS, VPWS, LDP, RSVP-TE…would be nice.
Ahmed
we removed these terms

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:
Frankly I do not understand the concern here.


P4. Section 2: “…the use of the binding segment as specified in 
[I-D.ietf-spring-segment-routing], also allows to substantially reduce 
the length of the segment list…”  Nice, but there is no description of 
the binding segment in draft-ietf-spring-segment-routing.
Ahmed:
We removed this statement

P5. References.  Please take a look at rfc8174 and update the 
“Requirements Language” and associated references.
Ahmed:
This one I missed while addressing the more important changes. I will 
address it in the next version



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
IMO references to routing protocols greatly helps in understanding the 
the instantiation of SR over MPLS. So I would rather leave them here

N2. It would be very nice if the examples used IPv6 addresses.
Ahmed
The objective of example is to clarify concepts. Because people are used 
to IPv4 a lot more than IPv6, then the use of IPv4 instead of IPv6 helps 
in achieving the objective of examples

On 2/23/2018 3:30 PM, Alvaro Retana wrote:
> Dear authors:
>
> I still haven’t seen a satisfactory reply to my AD Review of this 
> document [1].  The latest version doubled (!) the size of the document 
> (between versions -10 and -12)[2] without proper justification, or 
> (more importantly!) discussion on the list.
>
> I am returning the document to the WG for proper discussion of the 
> proposed changes.
>
> Alvaro.
>
> [1] 
> https://mailarchive.ietf.org/arch/msg/spring/97KtDebyroHfuNvllpNVb0s66H8/?qid=630f4b40ce9622377f9d39fe84fdab1a 
>
> [2] 
> https://www.ietf.org/rfcdiff?url1=draft-ietf-spring-segment-routing-mpls-10&url2=draft-ietf-spring-segment-routing-mpls-12 
>
>
> On February 23, 2018 at 8:06:56 AM, [e-mail] 
> <mailto:[e-mail]> ([e-mail] 
> <mailto:[e-mail]>) wrote:
>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>> This draft is a work item of the Source Packet Routing in Networking 
>> WG of the IETF.
>>
>> Title : Segment Routing with MPLS data plane
>> Authors : Ahmed Bashandy
>> Clarence Filsfils
>> Stefano Previdi
>> Bruno Decraene
>> Stephane Litkowski
>> Rob Shakir
>> Filename : draft-ietf-spring-segment-routing-mpls-12.txt
>> Pages : 24
>> Date : 2018-02-23
>>
>> Abstract:
>> Segment Routing (SR) leverages the source routing paradigm. A node
>> steers a packet through a controlled set of instructions, called
>> segments, by prepending the packet with an SR header. In the MPLS
>> dataplane, the SR header is instantiated through a label stack. This
>> document specifies the forwarding behavior to allow instantiating SR
>> over the MPLS dataplane.
>>
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-mpls/
>>
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-12
>> https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-mpls-12 
>>
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-segment-routing-mpls-12 
>>
>>
>>
>> Please note that it may take a couple of minutes from the time of 
>> submission
>> until the htmlized version and diff are available at tools.ietf.org 
>> <http://tools.ietf.org>.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> I-D-Announce mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt