Uma - I'd like to close this point of discussion as regards the conflict-resolution draft.
For the record, I agree with Peter. But from the standpoint of conflict resolution it matters not for what purpose SRMS is being used - we have to consider SRMS advertisements as well as SIDs associated w prefix advertisements. I hope that point has been clearly explained. If you wish to continue the discussion with the architecture draft authors as to whether further discussion of SRMS as a network provisioning tool should/should not be added to a document please feel free to do so - but I would ask that you do so in another thread. Thanx. Les > -----Original Message----- > From: Peter Psenak (ppsenak) > Sent: Friday, May 13, 2016 12:31 AM > To: Uma Chunduri; Stefano Previdi (sprevidi) > Cc: Les Ginsberg (ginsberg); spring@ietf.org; bruno.decra...@orange.com > Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution - WG adoption > call > > Uma, > > I don't know whether you need a text in the draft/RFC to use some > functionality one way or the other. The fact is that SRMS is a SID > provisioning > tool. You can use it for SR/LDP interoperability, but you can also use it in > a SR > only network to provide SIDs from a central place instead of configuring them > on each device. There is nothing that prevents you to use it one way or the > other. The fact that SRMS is defined in the SR/LDP interop drfat does not > mean it is restricted to be used for that purpose. > > I let authors of the SR architecture drafts to decide whether they want to add > the text. As an author of the OSPF SR draft, I do not see anything in the text > that you put below that would contradict what I'm saying here. > > thanks, > Peter > > > On 5/12/16 20:19 , Uma Chunduri wrote: > > Peter, > > > as a matter of fact, SRMS is a SID provisioning tool, > > whether you like it or not. > > It's not about your or my linking - I was talking about what's the > > defined scope so far (architecture doc or protocol docs) and how you > > want to extend the scope. > > Well, if you want to extend the current scope of SRMS as a "">2)As a > > global provisioning tool" - Plz. do so but not while providing > > conflict resolution solution. > > > It provides all the functionality that is required > > for such provisioning tool. > > >You can not restrict its usage to SR/LDP interop case. > > I didn't restrict anything - Plz. see SRMS stuff so far: > > 1. > > _https://tools.ietf.org/html/draft-ietf-spring-segment-routing-08#sect > > ion-3.6_ > > > > /" //3.6.1. Mapping Server/ > > ///A Remote-Binding SID S advertised by the mapping server M for > > remote/ ///prefix R attached to non-SR-capable node N signals the > > same/ ///information as if N had advertised S as a Prefix-SID. > > Further/ ///details are described in the SR/LDP interworking > > procedures/ ///([I-D.ietf-spring-segment-routing-ldp-interop].//"/ > > 2. ISIS: > > _https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extension > > s-06#section-2.4_ > > > > /" //This functionality is called the/ /////'Mapping Server' and it's > > used when, in a heterogeneous network,/ ///////not all nodes are > > capable of advertising their own SIDs/Labels.//"/ 3. OSPF: > > _https://tools.ietf.org/html/draft-ietf-ospf-segment-routing-extension > > s-08#section-4_ > > > > /"// In some cases it is useful to advertise attributes for a range of/ > > ///prefixes. The Segment Routing Mapping Server, which is described > > in/ ///[//I-D.filsfils-spring-segment-routing-ldp-interop/ > > <https://tools.ietf.org/html/draft-ietf-ospf-segment-routing-extension > > s-08>/], > > is an example/ > > ///where we need a single advertisement to advertise SIDs for > > multiple/ ///prefixes from a contiguous address range.//"/ Again, plz. > > extend the scope first and consider the same in resolution solution. I > > am fine with it. > > -- > > Uma C. > > -----Original Message----- > > From: Peter Psenak [mailto:ppse...@cisco.com] > > Sent: Thursday, May 12, 2016 11:03 AM > > To: Uma Chunduri; Stefano Previdi (sprevidi) > > Cc: Les Ginsberg (ginsberg); spring@ietf.org; > > bruno.decra...@orange.com > > Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution - WG > > adoption call Hi Uma, On 5/12/16 19:49 , Uma Chunduri wrote: > >> Stefano, > >> > >> Thanks for your response. > >> > >> > 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. > >> > >> My point below: We are creating a conflict resolution solution for a non- > existing requirement of using SRMS viz., ">2)As a global provisioning tool". > >> From your statement above, it seems you have less interest to make this > as a requirement/scope of SRMS; I am more aligned in that path.... > > as a matter of fact, SRMS is a SID provisioning tool, whether you like > > it or not. It provides all the functionality that is required for such > > provisioning tool. You can not restrict its usage to SR/LDP interop case. > > thanks, > > Peter > >> > >> On the second point: > >> > >> > the architecture draft is data-pane agnostic so I presume you > >> refer > to draft-ietf-spring-segment-routing-mpls. > >> > >> AFAIS,https://tools.ietf.org/html/draft-ietf-spring-segment-routing-0 > >> 8 talks > > about both data planes right from abstract to multiple places (which > > it ought to). > >> I leave this to you/WG on where you want to document this -but IMO > >> conflict resolution "solution document" in the current form potentially > introducing fundamental requirements to the system like cross protocol > verification (with in/across AS). Perhaps some discussion should be there in > data plane document then. > >> > >> -- > >> Uma C. > >> > >> > >> -----Original Message----- > >> From: Stefano Previdi (sprevidi) [mailto:sprev...@cisco.com] > >> Sent: Wednesday, May 11, 2016 4:46 AM > >> To: Uma Chunduri > >> Cc: Les Ginsberg (ginsberg);bruno.decra...@orange.com > >><mailto:bruno.decra...@orange.com>; > >>spring@ietf.org <mailto:spring@ietf.org> > >> Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution - WG > >>adoption call > >> > >> > >>> On May 6, 2016, at 10:16 PM, Uma Chunduri > <uma.chund...@ericsson.com <mailto:uma.chund...@ericsson.com>> > 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-extension > >>>s-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 > >>> <mailto:bruno.decra...@orange.com>; > > spring@ietf.org <mailto: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 > >>><mailto:bruno.decra...@orange.com>; > >>>spring@ietf.org <mailto: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 > >>> <mailto:bruno.decra...@orange.com>; > > spring@ietf.org <mailto: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. Smaller range wins > >>> > >>> 2. IPv6 entry wins over IPv4 entry > >>> … > >>> “ > >>> What happens in case of prefix conflict or SID conflict > >>> with only > prefix advertisements (range 1). Say multiple prefixes have same SID in one > protocol instance and in different protocols. > >>> I see 2 levels of resolution required viz., one at > >>> within the > protocol and one among the protocols. No discussion on this. > >>> > >>> [Les:] The full set of rules specified in the draft provide deterministic > resolution in all cases. You have snipped only the first two rules. If a > preference is not obtained based on the first two rules you continue on to > rule #3, then rule #4, etc. > >>> > >>> Similarly in case of SID conflict (range 1), it’s not > >>> specified which > protocol’s SID need to be considered. Are you assuming some sort of Admin > distance play a role in resolution? > >>> [Les:] No – admin distance plays no role here. > >>> > >>> I don’t see any discussion in the document and needs more clarity > there too. > >>> o Also what happens if a prefix or SID conflict happens with SRMS range > 1 and a prefix advertisement (2 cases) > >>> a. of one protocol and > >>> b. multiple protocols? > >>> > >>> [Les:] The source of the SID advertisement (what protocol/protocol > instance or whether it is SRMS based) plays no role. The tie breaker rules as > defined are complete and provide a deterministic answer in all cases. > >>> If you believe that is not true please provide a specific example where > you apply all the rules in the order specified and still do not determine the > preferred entry. > >>> > >>> > >>> - On the below assumption: (Section 3.2.4) > >>> “This has the nice property > >>> that a single > misconfiguratoion of an SRMS > >>> entry with a large range will not be preferred over a > >>> large > number of > >>> SIDs advertised in prefix reachability advertisements.” > >>> While anything can happen in theory, I found it bit odd to see why SRMS > entry is being advertised and for the same prefix, SID is also advertised > through reachability advertisements? > >>> This is against the spirit of SRMS advertisement, isn’t it? While this can > happen, it seems we are claiming resolution solution by focusing more on > this case in the current version of the document. > >>> > >>> [Les:] There are two legitimate use cases for SRMS: > >>> > >>> 1)To advertise SIDs for non-SR capable nodes 2)As a global > >>> provisioning tool > >>> > >>> Let’s examine the first case. I have an LDP enabled network and I begin > introducing SR capable nodes. At a given moment in time Router A is NOT SR > capable and SRMS advertisements cover prefix SIDs for the addresses > associated with Router A. > >>> I then upgrade Router A to become SR capable. Because I want to do > >>> “make-before-break” I do not immediately remove the SRMS > >>> advertisements covering the addresses associated with Router A. I > >>> upgrade A, add configuration of SIDs locally on Router A, and > >>> verify that the advertisements originating from protocols on Router > >>> A > > are correct. If an inconsistency is introduced when configuring the > > SIDs on Router A then I will have an SRMS advertisement and a > > prefix-reachability advertisement that conflict. Until the conflict is > > corrected we use the conflict resolution rules to provide > > deterministic forwarding behavior. > >>> > >>> This to me is a normal and expected upgrade scenario. > >>> > >>> > >>> This is one of the reasons of my first comment below. You got to > separate the reachability advertisements and SRMS advertisements; as in > principle these are defined for different purposes. I don’t see we need > algorithm to prefer reachability advertisement over SRMS advertisement (if > we don’t compare these 2 categories). > >>> > >>> > >>> > >>> [Les:] I disagree – hopefully my comments have helped you to > understand why. > >>> > >>> Les > >>> > >>> > >>> as the sections you have quoted clearly state. > >>> > >>> Why? Because we need consistent use of SIDs in the forwarding plane. > From forwarding perspective it matters not whether the SID was advertised > by protocol instance #1 or #2 or by an SRMS. > >>> > >>> What matters is that the SID I use to determine what label I install in my > forwarding plane is the same SID that my neighbors will use. Otherwise > forwarding will be broken. > >>> > >>> Les > >>> > >>> > >>> From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Uma > >>> Chunduri > >>> Sent: Wednesday, April 27, 2016 4:31 PM > To:bruno.decra...@orange.com > >>> <mailto:bruno.decra...@orange.com>; > > spring@ietf.org <mailto:spring@ietf.org> > >>> Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution - WG > >>> adoption call > >>> > >>> Dear Authors, > >>> > >>> Have few comments on the draft: > >>> > >>> 1. > >>> As I indicated during meeting - I am not sure why we have to club > verification of SIDs advertised through regular protocol reachability > >>> prefixes and the ranges advertised through 'Mapping > >>> Server' > (SRMS). I didn't see any compelling reason to do this. > >>> SIDs advertised through reachability prefixes doesn't > >>> have > ranges unlike SRMS advertisements. > >>> As SRMS advertisements are primarily for nodes which > >>> are not > SR capable and I feel we should not mix this with nodes which are SR > capable. > >>> > >>> This isolation helps restricting the resolution work primarily > >>> for > multiple SRMS entries advertised through one node or multiple nodes. > >>> SRMS advertisements are indeed little bit unique in that > >>> you are > advertising "configuration" on behalf of node X from node Y > >>> with ranges (both prefix ranges and SID ranges). > >>> > >>> > >>> 2. > >>> Regarding the scope of conflict resolution: > >>> > >>> > >>> Section 1 > >>> > >>> " The problem to be addressed is protocol independent i.e., > segment > >>> related advertisements may be originated by multiple nodes using > >>> different protocols and yet the conflict resolution MUST be the > same > >>> on all nodes regardless of the protocol used to transport the > >>> advertisements." > >>> > >>> Section 3.2.8 > >>> " o In cases where multiple routing protocols are in use > >>> mapping > >>> entries advertised by all routing protocols MUST be included." > >>> > >>> This sounds like we are seeking to resolve conflicting entries > >>> outside > and across the protocols? > >>> Each IGP has separate mechanism for advertising mapping entry and > I this is not clear with the current version of the draft how we can cross > verify > SID/Prefix conflict across the protocol. > >>> Can you clarify this? > >>> > >>> > >>> -- > >>> Uma C. > >>> > >>> > >>> -----Original Message----- > >>> From: spring [mailto:spring-boun...@ietf.org] On Behalf Of > >>>bruno.decra...@orange.com <mailto:bruno.decra...@orange.com> > >>> Sent: Thursday, April 14, 2016 12:55 AM To:spring@ietf.org > >>><mailto:spring@ietf.org> > >>> Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution - WG > >>>adoption call > >>> > >>>> From:bruno.decra...@orange.com > <mailto:bruno.decra...@orange.com> > Sent: > > Thursday, April 14, 2016 > >>>> 9:51 AM > >>>> > >>>> Dear WG, > >>>> > >>>> As we discussed at our meeting last week, working group adoption > >>>> has been requested for draft-ginsberg-spring-conflict-resolution. > >>>> Please reply to the list with your comments, including although not > >>>> limited to whether or not you support adoption. > >>> > >>> We will end the call on April 29, 2016. > >>> > >>> > >>>> Thanks, > >>>> > >>>> --John and Bruno > >>>> > >>>> > >>>> > >>>> > __________________________________________________________ > >>>> > __________________________________________________________ > >>>> _____ > >>>> > >>>> Ce message et ses pieces jointes peuvent contenir des informations > >>>> confidentielles ou privilegiees et ne doivent donc pas etre > >>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu > >>>> ce message par erreur, veuillez le signaler a l'expediteur et le > >>>> detruire ainsi que les pieces jointes. Les messages electroniques > >>>> etant susceptibles d'alteration, Orange decline toute responsabilite si > ce message a ete altere, deforme ou falsifie. Merci. > >>>> > >>>> This message and its attachments may contain confidential or > >>>> privileged information that may be protected by law; they should > >>>> not be distributed, used or copied without authorisation. > >>>> If you have received this email in error, please notify the sender > >>>> and delete this message and its attachments. > >>>> As emails may be altered, Orange is not liable for messages that > >>>> have been modified, changed or falsified. > >>>> Thank you. > >>>> > >>>> _______________________________________________ > >>>> spring mailing list > >>>>spring@ietf.org <mailto:spring@ietf.org> > >>>>https://www.ietf.org/mailman/listinfo/spring > >>> > >>> > __________________________________________________________ > __________ > >>> _ _ ___________________________________________________ > >>> > >>> Ce message et ses pieces jointes peuvent contenir des informations > >>> confidentielles ou privilegiees et ne doivent donc pas etre > >>> diffuses, exploites ou copies sans autorisation. Si vous avez recu > >>> ce message par erreur, veuillez le signaler a l'expediteur et le > >>> detruire ainsi que les pieces jointes. Les messages > > electroniques etant susceptibles d'alteration, Orange decline toute > > responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > >>> > >>> This message and its attachments may contain confidential or privileged > information that may be protected by law; they should not be distributed, > used or copied without authorisation. > >>> If you have received this email in error, please notify the sender and > delete this message and its attachments. > >>> As emails may be altered, Orange is not liable for messages that have > been modified, changed or falsified. > >>> Thank you. > >>> > >>> _______________________________________________ > >>> spring mailing list > >>>spring@ietf.org <mailto:spring@ietf.org> > >>>https://www.ietf.org/mailman/listinfo/spring > >>> > >>> _______________________________________________ > >>> spring mailing list > >>>spring@ietf.org <mailto:spring@ietf.org> > >>>https://www.ietf.org/mailman/listinfo/spring > >> > >> _______________________________________________ > >> spring mailing list > >>spring@ietf.org <mailto:spring@ietf.org> > >>https://www.ietf.org/mailman/listinfo/spring > >> _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
