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.
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
