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

[Alvaro Retana <[e-mail]>]

 On October 28, 2017 at 10:51:52 AM, Les Ginsberg (ginsberg) (
[e-mail] ) wrote:

Les:

Hi!

Apologies for the long delay in responding. The transference of the pen
from Stefano resulted in a longer delay than it should have.

Thanks for taking this on!

As a new author: are you aware of any undeclared IPR for this document?

A new version has been published which addresses your comments. Specific
replies inline.

My replies (to what I think still needs work or answers to questions) are
below.

In general, I think that the definition of “SR Domain” still needs work.  I
would also strongly recommend that you include a Deployment/Operations
Section.

The update looks like a lot of changes: more than 400 lines (according to
rfcdiff) — but I think they are mostly clarifying.  Instead of returning
the document to the WG, I am going to start an IETF Last Call for this
document — it will be extended (4 weeks) to account for the upcoming
meeting in Singapore, US Holidays and to give the WG an opportunity to
re-review.

Thanks!

Alvaro.


...

Major:



M1. The Introduction mentions several types of segments, and it says that
the LDP LSP, RSVP-TE LSP, and BGP LSP segments are “illustrated in
[I-D.ietf-spring-segment-routing-mpls]”.  But that is only true for the
first two, for which examples are shown.  Where are these segment types
defined?  The definition, and not the examples, is the Major issue here.
This document being the main architecture document should include the
complete description.  BTW, the list is only about the “MPLS
instantiation”, are there similar types of segments for IP?



[Les:] The list has been modified – but some definitions will still be
found in [I-D.ietf-spring-segment-routing-mpls] where it makes sense to do
so. We prefer that so that we do not duplicate definitions.

Ok — I would have preferred the definitions to show up here, but it’s ok,
as long at they are defined somewhere.

I went to look at the most recent version
of I-D.ietf-spring-segment-routing-mpls (-11), but there’s no definition of
those segments.  <sigh> :-(    I’ll take a look at that document and see if
they’re needed.



M2. From Section 2. (Terminology): “Using the same SRGB on all nodes within
the SR domain ease operations and troubleshooting and is expected to be a
deployment guideline.”  It is “expected to be a deployment guideline”
where/when??  Given that this document is the general architecture, I
figured that maybe draft-ietf-spring-segment-routing-mpls contained that
deployment recommendation, but all that document says is: “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.”  So…where are the Deployment/Operational
considerations related to the SRGB?  I note that neither document
(draft-ietf-spring-segment-routing or
draft-ietf-spring-segment-routing-mpls) include them.  I would expect some
information to be in this (general) document and other more specific
information (like the considerations about using the same SRGB) to be in
the more specific document (draft-ietf-spring-segment-routing-mpls, in this
case).



[Les:] Definition of the SRGB has been enhanced and the definition of an SR
Domain has been introduced and discussed. We hope this clarifies deployment
considerations as regards SRGB/SRLB.

SR Domain was already defined — the difference seems to be the somewhat
nebulous new text:

   Segment Routing Domain (SR Domain)...If multiple protocol instances are
   deployed, the SR domain most commonly includes all of the protocol
   instances in a single SR domain.  However, some deployments may wish
   to sub-divide the network into multiple SR domains, each of which
   includes one or more protocol instances.  It is expected that all
   nodes in an SR Domain are managed by the same administrative entity.

…which makes the definition depend on itself: "SR domain most commonly
includes all of the protocol instances in a single SR domain” (the domain
includes all the instances in the domain)…

Note that one of the point above was the lack of Deployment/Operational
Considerations in this document — the added text above opens the door even
more for such considerations: when would someone decide to sub-divide the
network into multiple domains?  What might the considerations be?

As for the SRGB definition, you did take out the part about “using the same
SRGB…is expected to be a deployment guideline” and changed it to it being
“strongly recommended”.  I still have the same question as before: what are
the Deployment/Operational considerations related to the SRGB?  You did
keep the text about how it “eases operations and troubleshooting”, but
didn’t provide guidance related on when/why.

BTW, 3.1.2 says that "Where possible, it is recommended that a consistent
SRGB be configured on all nodes in an SR Domain.” — I’m assuming
“consistent” is the same as “the same”...

In short, the changes didn’t really help me.  I think that this document
(which introduces a new technology) should have an Operational
Considerations section; take a look at rfc5706.


...

M3. From Section 2. (Terminology): “…a global segment is represented by a
globally-unique index.”



M3.1.  I couldn’t find anywhere a discussion about the use of the index.
When it is discussed in 3.1.2, it seems to be an understood concept: “A
Prefix-SID is allocated in the form of an index in the SRGB…”  Even if
straightforward, I think the concept of the index should be explained
(maybe with an example) and not assumed.  I again went to look at
draft-ietf-spring-segment-routing-mpls, but that document just points back
to this one: “The notion of indexed global segment, defined in
[I-D.ietf-spring-segment-routing]…”



[Les:] Definition of SID has been made more explicit and how an index is
used to obtain the Segment in the SR MPLS case has been explicitly defined
in Section 3.1.2.

Thanks for that…one question, I didn’t understand what "X is the 0 based
index” means in the algorithm.


...

M7. Section 3.4. (IGP-Adjacency Segment, Adj-SID) also tries to explain
functionality starting from the extensions.



[Les:] Here as well we have removed references to IGP specifics and
discussed the functionality on its own.



M7.1. “The encodings of the Adj-SID include the a set of flags among which
there is the B-flag.  When set, the Adj-SID refers to an adjacency that is
eligible for protection (e.g.: using IPFRR or MPLS-FRR).”  If the Adjacency
Segment is one that is locally significant to the node advertising it, what
is the purpose of signaling that it is eligible for protection?  Wouldn’t
that be a local decision as well?  Maybe an example of how the architecture
is expected to work would help.

I still have the same question: what is the purpose/value to signal whether
an Adj-SID is eligible for protection?  Isn’t that a local decision anyway?


...

M8. Section 3.5. (Binding Segment).  A binding segment is not described
anywhere in this document – please do so!  Section 3.5.1. (Mapping Server)
mentions a “Remote-Binding SID S advertised by the mapping server”, and
says that more “details are described in the SR/LDP interworking procedures
([I-D.ietf-spring-segment-routing-ldp-interop]”, but that draft doesn’t
mention a Binding Segment.  Section 5. (IGP Mirroring Context Segment) says
that “the binding segment [is] defined in SR IGP protocol extensions (
[I-D.ietf-isis-segment-routing-extensions],
[I-D.ietf-ospf-segment-routing-extensions] and
[I-D.ietf-ospf-ospfv3-segment-routing-extensions])”; however, those
documents don’t mention a Binding Segment, they just (except for the OSPFv2
draft) define TLVs.  Note that I-D.ietf-ospf-segment-routing-extensions
points back to this document when referring to the definition of a Binding
SID, completing a circular reference.



[Les:] Section on Binding Segment has been rewritten and the  Mirror
Context discussion is a sub-section of that section.

It seems to me that the description is not as clear as it could be.  The
initial sentence sounds general enough so that any/all SR Policy is
bound/related to a BSID.  Suggestion: start the description with the
motivation.


...

M10. Section 3.6. (Inter-Area Considerations)



M10.1. This section shows an example of the behavior: maintain the SID
across area boundaries.  But it doesn’t actually say how the architecture
is expected to work.  IOW, in the example the SID is maintained, but should
that always happen (MUST, SHOULD)? Or is it just an example (MAY)?



[Les:] With the introduction of the “SR Domain” definition we believe this
point is now clarified.

Please see my comments above about the SR Domain definition.  I need you to
walk me through how that definition (which just says that there may be one
or more domains) clarifies the inter-area behavior in the example.


...

Minor:

 ...

P1.4. Speaking of use cases, I-D.ietf-spring-oam-usecase doesn’t actually
include use cases that will affect the architecture.  It includes use case
of how to use monitoring system defined in it.  Same comment for the
mention in Section 9.

The document is still referenced in Section 9 as a use case document.


...

Nits:

...

N9.
s/([I-D.ietf-spring-segment-routing-ldp-interop]/[I-D.ietf-spring-segment-routing-ldp-interop]




[Les:] I do not see what you are correcting here. ???

There’s an extra “(“.


...

N11. It would be nice if the examples used IPv6 instead of IPv4.

[Les:] Hmmm…the Inter-area example does use IPv6, but the anycast example
uses IPv4. Is this now forbidden?

No, just trying to play nice with others — just a nit.