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?
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.
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).
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.
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.
Addressed in this version (version 12)

M3.1. [minor] I hope to see an explanation of the “[SRGB(next_hop)+index]” 
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.
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?
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).
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”.
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.
we removed this term

P2. Informative References to VPN, VPLS, VPWS, LDP, RSVP-TE…would be nice.
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
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.
We removed this statement

P5. References. Please take a look at rfc8174 and update the “Requirements Language” and associated references.
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!).
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.
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.


[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, internet-dra...@ietf.org <mailto:internet-dra...@ietf.org> (internet-dra...@ietf.org <mailto:internet-dra...@ietf.org>) 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

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:

There are also htmlized versions available at:

A diff from the previous version is available at:

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:

I-D-Announce mailing list
i-d-annou...@ietf.org <mailto:i-d-annou...@ietf.org>
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

spring mailing list

Reply via email to