Subject: [spring] Benoit Claise's No Objection on draft-ietf-spring-segment-routing-13: (with COMMENT)

From: Benoit Claise <[email-masked]>
Date: Thu, 14 Dec 2017 03:18:28 -0800

Benoit Claise has entered the following ballot position for
draft-ietf-spring-segment-routing-13: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

The good news is that, whenever you have ingested the terminology section, you
pretty much understand how the protocols works. :-)

1.
Good to see that this new protocol spec. has a "manageability considerations".
However, a major comment (not sure if this should be a DISCUSS, so help me
understand). I have the same questions as Warren regarding:

    "In addition to the allocation policy/tooling that the operator will have
    in place, an implementation SHOULD protect the network in case of conflict
    detection by providing a deterministic resolution approach."

I guess you want to start by stressing the SID uniqueness in the different
scenario: distributed, centralized, hybrid. And from there, explain where this
apply. I guess the sentence only applies to the hybrid scenario, right? Then
you should explain how an implementation should first detect a conflict and
then protect.

2. Section 3.1.1

   The ingress node of an SR domain SHOULD validate that the path to a
   prefix, advertised with a given algorithm, includes nodes all
   supporting the advertised algorithm.

This is only in the distributed scenario, right? This is what you mean by
"advertised with a given algorithm" In other words, you mean "advertised with a
given IGP algorithm". In hybrid or centralized scenarios, the ingress node
might not know. See

   In a centralized scenario,  ...
   The SR architecture allows these SR controllers to discover which
   SID's are instantiated at which nodes and which sets of local (SRLB)
   and global labels (SRGB) are available at which node.

Editorial:
NETCONF would benefit from a reference to RFC6241

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 20 Dec 2017 23:53:38 +0000

Benoit -

Thanx for the review.
V14 has been published.

Please see inline.

> -----Original Message-----
> From: Benoit Claise (bclaise)
> Sent: Thursday, December 14, 2017 3:18 AM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> mehmet <[email-masked]>
> Subject: Benoit Claise's No Objection on draft-ietf-spring-segment-routing-
> 13: (with COMMENT)
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 
> The good news is that, whenever you have ingested the terminology section,
> you pretty much understand how the protocols works. :-)
> 
> 1.
[Les:] There is no fundamental difference in this regard between the distributed/centralized/hybrid scenarios.
SID conflicts can occur in any of these scenarios and the manner of handling them is not scenario specific.

The source(s) which populate the SID database may differ in the various scenarios, but the conflict resolution solution does not.

> "advertised with a given algorithm" In other words, you mean "advertised
> with a given IGP algorithm". In hybrid or centralized scenarios, the ingress
> node might not know. See
> 
[Les:] Any node has the means to know the set of algorithms supported by each node in the network because this support is advertised by the IGPs and supported by BGP-LS.

> NETCONF would benefit from a reference to RFC6241

[Les:] Done.

   Les