> On May 6, 2016, at 10:16 PM, Uma Chunduri <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-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. 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; 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
> Sent: Thursday, April 14, 2016 12:55 AM
> To: spring@ietf.org
> Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution - WG adoption
> call
>
> > From: 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
> > 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
> https://www.ietf.org/mailman/listinfo/spring
>
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
