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

["Les Ginsberg (ginsberg)" <[e-mail]>]

Alvaro –

V14 of the draft has been posted.
Responses to your comments inline.

From: Alvaro Retana [mailto:[e-mail]]
Sent: Wednesday, November 01, 2017 12:55 PM
To: Les Ginsberg (ginsberg) <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: RE: AD Review of draft-ietf-spring-segment-routing-12

On October 28, 2017 at 10:51:52 AM, Les Ginsberg (ginsberg) ([e-mail]<mailto:[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)…

[Les:] Recursive definition issue addressed.

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”...

[Les:] Yes – this has been clarified by some editorial changes.

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.

[Les:] This has been discussed in some previous emails. We think the current content of the draft is appropriate in this regard. Anything approaching the level described in the suggested rfc5706 would require its own document. We do not think this content is appropriate for an architecture document.

...
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.

[Les:] The description of how to map an index to multiple SRGB ranges has been removed. The equivalent description is in the SR-MPLS document and we think it is more appropriate there given this is an SR-MPLS specific advertisement. If there is still an issue we will need to address it in the SR-MPLS text.

...
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?

[Les:] The signaling is not a local decision – the decision to support protected/unprotected (for example) is a local decision.

Text has been added to describe the purpose of the various attributes.

...
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.



[Les:] Text has been added to state the motivation for Binding SID.

...
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.



[Les:] Let me know if new version has helped.

...
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.



[Les:] Yes – but like virtually all of the references to SR drafts the reference is  informational i.e., we provide it not because the architecture has a dependency but because it is useful if the reader wishes to learn more about that particular aspect.

...
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 “(“.

[Les:] Thanx.

   Les





...
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.