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

[Alvaro Retana <[e-mail]>]

 On October 30, 2017 at 2:12:18 PM, Ahmed Bashandy (bashandy) (
[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. Section 2.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.