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, 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
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
i-d-annou...@ietf.org <mailto:i-d-annou...@ietf.org>
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
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
