On October 30, 2017 at 2:12:18 PM, Ahmed Bashandy (bashandy)
(basha...@cisco.com <mailto:basha...@cisco.com> ) 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.
