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

From: Alvaro Retana <[email-masked]>
Date: Wed, 1 Nov 2017 15:55:00 -0400

On October 28, 2017 at 10:51:52 AM, Les Ginsberg (ginsberg) (
[email-masked] ) 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.

---

From: stefano previdi <[email-masked]>
Date: Thu, 2 Nov 2017 12:59:32 +0100

> On Nov 1, 2017, at 8:55 PM, Alvaro Retana <[email-masked]> wrote:
> 
> On October 28, 2017 at 10:51:52 AM, Les Ginsberg (ginsberg) ([email-masked] ) 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.
>> 
>> 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.

what exactly would you expect to find in such section ? We have the Manageability section which illustrates how SR can be managed. An operation/deployment section will have to be exhaustive and illustrative on the different use-cases that SR addresses and hence can become pretty large. 

To my view, the draft focuses on architecture, not on deployment or operation. These are mostly described in the different use-cases drafts.

> The update looks like a lot of changes: more than 400 lines (according to rfcdiff) — but I think they are mostly clarifying.  

indeed, not a single change in the architecture has been introduced or changed.

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

many thanks!

s.

> 
> 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:
> 
>    
> …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.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.
>> 
>> N9. s/([I-D.ietf-spring-segment-routing-ldp-interop]/[I-D.ietf-spring-segment-routing-ldp-interop]
>> 
>> 
>>  
>> 
>> [Les:] Hmmm…the Inter-area example does use IPv6, but the anycast example uses IPv4. Is this now forbidden?
>>

---

From: Alvaro Retana <[email-masked]>
Date: Thu, 2 Nov 2017 09:53:48 -0400

On November 2, 2017 at 7:59:31 AM, stefano previdi ([email-masked])
wrote:

Stefano:

Hi!

> I would also strongly recommend that you include a Deployment/Operations
Section.

what exactly would you expect to find in such section ? We have the
Manageability section which illustrates how SR can be managed. An
operation/deployment section will have to be exhaustive and illustrative on
the different use-cases that SR addresses and hence can become pretty large.

To my view, the draft focuses on architecture, not on deployment or
operation. These are mostly described in the different use-cases drafts.

Expectations: take a look at rfc5706.  There’s a lot in there, including
manageability, which this document already has.  To be specific, a couple
of things come to mind:

- considerations about when/why the same SRGB should be used.  The text
says that it is “strongly recommended”, but it would be nice to explain
further the pros/cons.

- considerations about deciding when/why someone may decide to sub-divide
the network into multiple domains vs keeping just one.  Is it a scalability
issue, or just operational simplicity?

Note that the use case documents justify the need for Segment Routing, they
don’t talk about how to deploy it.  The concepts above (SRGB and SR Domain)
are presented in this document and statements are made about them but no
further explanation is given — that is why I would strongly recommend (that
is not a MUST) that you include a Deployment/Operations Considerations
Section.

Thanks!

Alvaro.

---

From: Alvaro Retana <[email-masked]>
Date: Thu, 30 Nov 2017 14:04:30 -0800

Les:

Hi!

I don’t think I got a reply on the IPR question below.

Thanks!

Alvaro.

On November 1, 2017 at 3:55:00 PM, Alvaro Retana ([email-masked])
wrote:

Les:

Hi!

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 30 Nov 2017 22:10:12 +0000

Alvaro –

Sorry, I was waiting for a new rev of the draft addressing the second round of comments to be ready to publish. That is in progress – Ahmed and I are still working to resolve some overlap between architecture document and sr mpls document – but we hope to have new versions soon.

In the meantime, I am not aware of any undisclosed IPR.

    Les

From: Alvaro Retana [mailto:[email-masked]]
Sent: Thursday, November 30, 2017 2:05 PM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: AD Review of draft-ietf-spring-segment-routing-12

Les:

Hi!

Thanks!

Alvaro.

On November 1, 2017 at 3:55:00 PM, Alvaro Retana ([email-masked]<mailto:[email-masked]>) wrote:

Les:

Hi!