> On May 6, 2016, at 10:16 PM, Uma Chunduri wrote:
>
> Les,
>
> 2 quick things.
>
> 1.
> >[Les:] There are two legitimate use cases for SRMS:
>>1)To advertise SIDs for non-SR
> capable nodes
>>2)As a global provisioning tool
> I am hearing #2 for the first time. I don’t see this
> either discussed earlier in the WG list or captured in architecture
> document
>
> https://tools.ietf.org/html/draft-ietf-spring-segment-routing-07. Even in the
> protocol extensions document for example
>
> https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions-06#section-2.4
> we always discussed this from non-SR
> capable nodes PoV. So I request to add this in
> architecture document before factoring this for solution in conflict
> resolution.
using a SRMS for advertising SID on behalf of SR capable nodes does not
introduce any change in the SR architecture so not sure what we need to
document here.
>
> 2. Also this is the first time ever we have a requirement for cross
> protocols verification we ought to discuss the implications of this
> and protocols involved (with in AS or otherwise) in the architecture document
> (at least briefly).
the architecture draft is data-pane agnostic so I presume you refer to
draft-ietf-spring-segment-routing-mpls.
with the ipv6 data-plane SR conflicts are in fact solved by ipv6 addressing
techniques ;-)
s.
>
> --
> Uma C.
>
> From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Les Ginsberg
> (ginsberg)
> Sent: Wednesday, May 04, 2016 9:38 AM
> To: Uma Chunduri; bruno.decra...@orange.com; spring@ietf.org
> Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution - WG adoption
> call
>
> Uma –
>
> To restate, the problem being addressed here is to guarantee consistent use
> of SIDs in the forwarding plane network-wide in the presence of conflicting
> advertisements. The set of advertisements includes both SIDs advertised in
> protocol prefix reachability advertisements and SRMS advertisements because
> problems occur based upon inconsistencies in what is installed in the
> forwarding plane of different routers. It matters not whether Router A used a
> SID advertised by a protocol prefix reachability advertisement or by an SRMS
> advertisement – what matter is whether the SID used is consistent with what
> the neighbors of Router A use. So simply ensuring that OSPF (for example)
> resolves SIDs in a consistent way does not fully address the problem space.
>
> More inline.
>
> From: Uma Chunduri [mailto:uma.chund...@ericsson.com]
> Sent: Tuesday, May 03, 2016 3:59 PM
> To: Les Ginsberg (ginsberg); bruno.decra...@orange.com; spring@ietf.org
> Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution - WG adoption
> call
>
> Les,
>
> With all due respects, cross protocol verification of prefix and SID
> conflicts as an “architectural change” and it can severely impact the
> existing implementations (at least the one I work on).
>
> [Les:] It is quite correct – and I can confirm based on personal experience –
> that support for conflict resolution is a significant effort.
>
> Also I have couple of cases where current version of the draft is not clear
> about resolution.
>
> IMO, first we need clarity with in a protocol instance resolution rules
> before going to resolve the same across protocols (I mentioned few cases
> below) .
> Separation of reachability advertisements and SRMS would help “cross
> protocol” verification of the ranges and SRMS is not applicable to all
> protocols.
>
>
> In-line [Uma]:
>
> --
> Uma C.
>
> From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
> Sent: Saturday, April 30, 2016 10:11 PM
> To: Uma Chunduri; bruno.decra...@orange.com; spring@ietf.org
> Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution - WG adoption
> call
>
> Uma –
>
> We are indeed defining conflict resolution across all the SID advertisements
> regardless of source (protocol or SRMS) –
>
> [Uma]: While you can theoretically do anything for current implementation
> this kind of cross protocol verification is a new architectural requirement.
>Because it seems “a central entity” need to gather all
> different protocol instances SRMS advertisements and should settle with
> resolution.
>
> - Also note SRMS is not applicable for BGP but it seems all prefix
> SIDs need to be verified with IGP instances SRMS advertisements. Is this
> true? While the document mostly talks about these and compares with prefix
> advertisement.
> [Les:] The issue is protocol agnostic.
>
> - Algorithm proposed needs more clarity: Take Section 3.2.4
>
> o
> “ 1. Small
