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

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

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 <[e-mail]>
> Cc: [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> mehmet <[e-mail]>
> Subject: Benoit Claise's No Objection on draft-ietf-spring-segment-routing-
> 13: (with COMMENT)
> 
> 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.
> 
[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.

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

> Editorial:
> NETCONF would benefit from a reference to RFC6241

[Les:] Done.

   Les

>