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

[Martin Vigoureux <[e-mail]>]

Alvaro,

speaking as Shepherd.
Regarding Q1&Q2: Indeed, Section 2 is the core of the document, and in 
my view the section containing what is worth standardizing. Document was 
already trimmed as part of the shepherd review.
If Section 2 was to be moved out of the document then yes, I think it 
could naturally become an Informational document. Yet, I see value in 
having both a generic architecture and specific documents on how it can 
be implemented using a specific technology.
Also, Standard Track documents do not need to be long to be useful.

Regarding Q3: since, as you say, we can not state whether a given piece 
of IPR is valid or not, I am not sure whether we can discuss the 
applicability of IPR disclosures (made against other documents) to this 
document, and vice versa.

-m

Le 24/08/2017 à 04:38, Alvaro Retana (aretana) a écrit :
> Dear authors:
>
>
>
> I just finished reading this document.  Please take a look at my
> comments below.
>
>
>
> 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.
>
>
>
> 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?
>
>
>
> 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 didn’t find a discussion on the list about any of these points.
>
>
>
> Thanks!
>
>
>
> Alvaro.
>
>
>
>
>
> Major
>
>
>
> 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).
>
>
>
>
>
> M2. [I mentioned these issues in the review of
> draft-ietf-spring-segment-routing as well.]
>
>
>
> 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.
>
>
>
> M2.2. The concept of an SRLB is not defined in the Architecture document
> either.
>
>
>
>
>
> M3. Still in Section 2, from this text:
>
>
>
>       *  When different SRGBs are used, the outgoing label value is set
>
>          as: [SRGB(next_hop)+index].  If the index can't be applied to
>
>          the SRGB (i.e.: if the index points outside the SRGB of the
>
>          next-hop or the next-hop has not advertised a valid SRGB), then
>
>          no outgoing label value can be computed and the next-hop MUST
>
>          be considered as not supporting the MPLS operations for that
>
>          particular SID.
>
>
>
> …several questions/comments…
>
>
>
> M3.1. [minor] I hope to see an explanation of the
> “[SRGB(next_hop)+index]” notation.
>
>
>
> M3.2. What is a “valid SRGB”?  I don’t think the validity of the SRGB is
> described in the Architecture document.
>
>
>
> M3.3. I’m assuming that once the “next-hop MUST be considered as not
> supporting” then the packets are dropped, right?
>
>
>
> 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).
>
>
>
>
>
> 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”.
>
>
>
>
>
>
>
> Minor
>
>
>
> 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.
>
>
>
> P2. Informative References to VPN, VPLS, VPWS, LDP, RSVP-TE…would be nice.
>
>
>
> 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
>
>
>
> 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.
>
>
>
> P5. References.  Please take a look at rfc8174 and update the
> “Requirements Language” and associated references.
>
>
>
>
>
>
>
> 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!).
>
>
>
> N2. It would be very nice if the examples used IPv6 addresses.
>