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

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Thu, 24 Aug 2017 02:38:55 +0000

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.

---

From: Martin Vigoureux <[email-masked]>
Date: Thu, 24 Aug 2017 22:44:20 +0200

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 :
> 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.
>
>
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> 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!).
>
>
>

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Fri, 25 Aug 2017 12:43:40 +0000

On 8/24/17, 4:44 PM, "Martin Vigoureux" <[email-masked]> wrote:

Martin:

Hi!

> my view the section containing what is worth standardizing. 

What, exactly, is this document standardizing?

It is probably too late to argue about not having a separate mpls-focused document, so I’m not arguing against publication.  I am also not concerned about the length – it is good to see focused, clear documents.

…
> document, and vice versa.

Right.  That was a question/observation mostly for the IPR owners.  I’m just wondering whether the declaration was done against the right document since I can’t really tell what is new and different here that was not in the Architecture document.  I’ll be happy with the IPR holders just thinking about it…

Thanks!

Alvaro.