Re: [spring] draft-ginsberg-spring-conflict-resolution - WG adoption call

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

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); [e-mail]; [e-mail]
> 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:[e-mail]]
> > Sent: Thursday, May 12, 2016 11:03 AM
> > To: Uma Chunduri; Stefano Previdi (sprevidi)
> > Cc: Les Ginsberg (ginsberg); [e-mail];
> > [e-mail]
> > 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:[e-mail]]
> >> Sent: Wednesday, May 11, 2016 4:46 AM
> >> To: Uma Chunduri
> >> Cc: Les Ginsberg (ginsberg);[e-mail]
> >><mailto:[e-mail]>;
> >>[e-mail] <mailto:[e-mail]>
> >> Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution - WG
> >>adoption call
> >>
> >>
> >>> On May 6, 2016, at 10:16 PM, Uma Chunduri
> <[e-mail] <mailto:[e-mail]>>
> 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:[e-mail]] On Behalf Of Les
> >>> Ginsberg (ginsberg)
> >>> Sent: Wednesday, May 04, 2016 9:38 AM
> >>> To: Uma Chunduri;[e-mail]
> >>> <mailto:[e-mail]>;
> > [e-mail] <mailto:[e-mail]>
> >>> 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:[e-mail]]
> >>> Sent: Tuesday, May 03, 2016 3:59 PM
> >>> To: Les Ginsberg (ginsberg);[e-mail]
> >>><mailto:[e-mail]>;
> >>>[e-mail] <mailto:[e-mail]>
> >>> 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:[e-mail]]
> >>> Sent: Saturday, April 30, 2016 10:11 PM
> >>> To: Uma Chunduri;[e-mail]
> >>> <mailto:[e-mail]>;
> > [e-mail] <mailto:[e-mail]>
> >>> 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:[e-mail]] On Behalf Of Uma
> >>> Chunduri
> >>> Sent: Wednesday, April 27, 2016 4:31 PM
> To:[e-mail]
> >>> <mailto:[e-mail]>;
> > [e-mail] <mailto:[e-mail]>
> >>> 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:[e-mail]] On Behalf Of
> >>>[e-mail] <mailto:[e-mail]>
> >>> Sent: Thursday, April 14, 2016 12:55 AM  To:[e-mail]
> >>><mailto:[e-mail]>
> >>> Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution - WG
> >>>adoption call
> >>>
> >>>> From:[e-mail]
> <mailto:[e-mail]> > 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
> >>>>[e-mail] <mailto:[e-mail]>
> >>>>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
> >>>[e-mail] <mailto:[e-mail]>
> >>>https://www.ietf.org/mailman/listinfo/spring
> >>>
> >>> _______________________________________________
> >>> spring mailing list
> >>>[e-mail] <mailto:[e-mail]>
> >>>https://www.ietf.org/mailman/listinfo/spring
> >>
> >> _______________________________________________
> >> spring mailing list
> >>[e-mail] <mailto:[e-mail]>
> >>https://www.ietf.org/mailman/listinfo/spring
> >>