Les, > From: Les Ginsberg (ginsberg) [mailto:[email protected]] > Sent: Saturday, > October 24, 2015 12:00 AM > > Bruno - > > When there is a conflict, the problem with trying to decide which > advertisement should be preferred is that there really is no way of knowing > with certainty which advertisement is the correct one.
Mostly agreed. But I'm not that concerned about finding "the correct one" or the good one. I'm concerned about the consequences of the error handling behavior. I'd like that we evaluate them and possibly minimize the adverse consequences. In the scenario where the Mapping Server (MS) advertise range of SIDs, the error handling of draft-ginsberg-spring-conflict-resolution introduces a significant risk of breaking a significant part of the network. The error handling of draft-ietf-isis-segment-routing-extensions do not. So I'd like to better understand why you are proposing to change the spec and the implementations, and why in this specific direction. In your email, you are arguing that some network deployment of MS would not advertise range of SIDs, and in such condition the conflict and the consequences would be more limited. Ok, but evaluating a different scenario does not address my point. Finally, you are discussing the relative popularity of both deployments. You are welcome to present data (facts) about this. If you don't, even though I could have arguments, I don't see the value of discussing this because I don't think that this is the point. Even if MS range are used by 20% of SPRING deployments, taking the risk to break the connectivity of this range of routers (e.g. 100 routers or more), in case of a single error (typo or bug) does not seem desirable. In summary, as part of the error handling discussion, I'd like that we evaluate the consequences and possibly minimize the adverse ones. A network wide breakage seems a large one to me. -- Bruno > You have made certain > assumptions below as to what is the most advantageous preference - and in a > given scenario your assumptions may be quite reasonable. But here is an > alternate scenario where I think different assumptions could be made with an > equal justification. > > Again consider a brown field deployment. SRMS is used to advertise SIDs for > those nodes which are not yet SR capable. So, for Node X which has a Node > address of 1.1.1.1 SRMS might advertise: > > 1.1.1.1/32 100 range 1 > > This in fact is the correct value and all is working well. > > At some point Node X gets upgraded to become SR capable. Part of the new > configuration is to assign the SID locally, but in doing so the operator > makes an > error and configures: > > 1.1.1.1/32 200 range 1 > > Because the operator wants to do "make before break" the SRMS > advertisement is NOT removed when Node X is upgraded (there should be no > rush to do so) - so we have a conflict. Using your logic below, network would > switch to using SID 200 for 1.1.1.1/32 - which in fact is the wrong choice. > > I think this scenario is just as plausible as the scenario you presented. > > You also seems to suggest that SRMS advertisements are far more likely to > have ranges greater than 1, something like: > > 1.1.1.1/32 100 range 100 > > but I think this assumption is questionable. For this to work, the following > things have to be true: > > 1)A significant set of the node addresses in the network have to fit within > the > defined range > 2)All the SIDs which are assigned (even locally) need to follow a > monotonically > increasing mapping of address-to-SID > > There may be networks where the above constraints will be met - but I have > seen enough deployments w irregular address assignments not to expect such > regularity. > > I am not saying you are wrong - I am saying we can all come up with cases > where a given set of rules offers advantages - but as there are many sets of > optimal rules depending on how your network is deployed/upgraded - any > argument of this type is simply unresolvable. Every answer is advantageous > under one set of conditions and disadvantageous under another set. > > HTH > > Les > > > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] > > Sent: Friday, October 23, 2015 1:05 AM > > To: Les Ginsberg (ginsberg) > > Cc: [email protected] > > Subject: RE: New Version Notification for draft-ginsberg-spring-conflict- > > resolution-00.txt > > > > Les, > > > > Mapping Server (MS) is typically deployed in brown field deployments > where > > some routers are not (yet) Segment Routing (SR) compliant, i.e. LDP only. > > In this scenario, the MS advertises the SIDs for the whole range of router's > > loopback. The SR routers also advertise their own SID in Prefix-SID sub-TLV > > attached to their loopback. Hence, in the nominal situation, SIDs are > > advertised both by loopback owners and by the MS. > > > > In this situation, with a _single_ erroneous advertisement from the MS (e.g. > > a typo from an operator or a software bug) _all_ the SID/Segments in the > > network becomes in conflict. > > draft-ginsberg-spring-conflict-resolution proposes 2 options: > > a) ignore the SID in conflict > > b) select one based on a tie-breaker > > > > "a" would result in all SID/Segments of the network to become invalidated. > > i.e. breaking the whole MPLS network. In my view, this is not a desirable > > reaction, especially in reaction to a single error. > > "b" seems better. Yet the tie-breaker does not make a distinction between > > Prefix-SID sub-TLV and MS advertisement. IMO Prefix-SID sub-TLV should be > > privileged for 2 reasons: > > - To learn a data from (node) X, I'd rather trust X itself rather than Y. > > Especially from X point of view. (IOW, let me speak for myself) > > - Prefix-SID sub-TLV advertises a single SID while MS advertise many. > > Assuming a single error (which seems reasonable as the network was > > running correctly before), it seems less risky to take the risk for a > > single SID > > rather than for the whole MS advertisement. > > > > > > That is also the opinion of draft-ietf-isis-segment-routing-extensions which > > already specify this behavior: > > For a given prefix, if both a MS entry with its Prefix-SID Sub-TLV > > and a Prefix TLV (e.g.: TLV135) with its Prefix-SID are received, the > > Prefix-SID advertised within the Prefix TLV MUST be preferred while > > the MS entry MUST be ignored. > > > > > > Bottom line, I don't understand why you are proposing to change this > > specification. Could you please elaborate on your reasons and challenge > > mines as needed? > > > > Thanks, > > Regards; > > Bruno > > > > > From: Les Ginsberg > Sent: Thursday, October 22, 2015 9:21 PM > > > > > > Bruno - > > > > > > In Section 3.2.5 of the draft: > > > > > > " ... For other sources, It may seem intuitive to assign priority based > > > on > > > point of origination (e.g. intra-area preferred over inter-area, > > > prefix reachability advertisements preferred over SRMS > > > advertisements, etc.). However, any such policy makes it more likely > > > that inconsistent choices will be made by routers in the network and > > > increase the likelihood of forwarding loops or blackholes." > > > > > > If this point is agreed to then changes to the IGP drafts - such as > > > the IS-IS SR draft section that you quoted (actually Section 2.4.5 of > > > that draft) - would be necessary. > > > > > > So yes - it is our intent to have the protocol drafts changed if the > > > conflict resolution language in this area is accepted. > > > > > > Les > > > > > > > > > > -----Original Message----- > > > > From: [email protected] > > [mailto:[email protected]] > > > > Sent: Thursday, October 22, 2015 9:00 AM > > > > To: Les Ginsberg (ginsberg) > > > > Cc: [email protected] > > > > Subject: RE: New Version Notification for > > > > draft-ginsberg-spring-conflict- resolution-00.txt > > > > > > > > Les, > > > > > > > > As an individual contributor, I have a clarification question > > > > regarding > > > Segment > > > > Identifier Conflicts > > > > https://tools.ietf.org/html/draft-ginsberg-spring-conflict-resolutio > > > > n- > > > > 00#section-3 > > > > > > > > In the IGP, (Prefix, SID) mapping may be advertised via either > > > > Prefix-SID (sub-TLV attached to an IP Prefix) or Mapping Server > > > > (Mapping Server > > > Prefix- > > > > SID in the Binding TLV). > > > > The draft generalizes both by defining and using a generalized > > > > mapping entry. > > > > Hence the draft seems to make no distinction between Prefix-SID and > > > > Remote-Binding SID advertised by the Mapping Server. Is this a > > > > correct understanding? > > > > > > > > OTOH, the "IS-IS Extensions for Segment Routing" IS-IS WG draft, > > > > specify that a distinction must be made: > > > > " For a given prefix, if both a MS entry with its Prefix-SID Sub-TLV > > > > and a Prefix TLV (e.g.: TLV135) with its Prefix-SID are received, the > > > > Prefix-SID advertised within the Prefix TLV MUST be preferred while > > > > the MS entry MUST be ignored." > > > > https://tools.ietf.org/html/draft-ietf-spring-segment-routing-06#sec > > > > tion- > > > > 3.6.1 > > > > > > > > So is your intention to: > > > > - change the IS-IS specification to remove this rule (preference for > > > > Prefix- > > > SID > > > > Sub-TLV)? > > > > - or adapt your draft to accommodate for this rule? > > > > > > > > Thanks, > > > > Regards, > > > > Bruno > > > > > > > > > From: Les Ginsberg (ginsberg) > Sent: Wednesday, October 14, 2015 > > > > > 8:44 PM Folks - > > > > > > > > > > Would like to call your attention to this new draft. > > > > > > > > > > Les > > > > > > > > > > -----Original Message----- > > > > > From: [email protected] [mailto:[email protected]] > > > > > Sent: Wednesday, October 14, 2015 10:57 AM > > > > > To: Peter Psenak (ppsenak); Les Ginsberg (ginsberg); Stefano > > > > > Previdi > > > > > (sprevidi) > > > > > Subject: New Version Notification for > > > > > draft-ginsberg-spring-conflict- resolution-00.txt > > > > > > > > > > > > > > > A new version of I-D, > > > > > draft-ginsberg-spring-conflict-resolution-00.txt > > > > > has been successfully submitted by Les Ginsberg and posted to the > > > > > IETF repository. > > > > > > > > > > Name: draft-ginsberg-spring-conflict-resolution > > > > > Revision: 00 > > > > > Title: Segment Routing Conflict Resolution > > > > > Document date: 2015-10-14 > > > > > Group: Individual Submission > > > > > Pages: 14 > > > > > URL: > > > > > https://www.ietf.org/internet-drafts/draft-ginsberg-spring- > > > > conflict- > > > > > resolution-00.txt > > > > > Status: > > > > > https://datatracker.ietf.org/doc/draft-ginsberg-spring- > > conflict- > > > > > resolution/ > > > > > Htmlized: > > > > > https://tools.ietf.org/html/draft-ginsberg-spring-conflict- > > > > > resolution-00 > > > > > > > > > > > > > > > Abstract: > > > > > In support of Segment Routing (SR) routing protocols advertise a > > > > > variety of identifiers used to define the segments which direct > > > > > forwarding of packets. In cases where the information advertised > > > > > by > > > > > a given protocol instance is either internally inconsistent or > > > > > conflicts with advertisements from another protocol instance a > means > > > > > of achieving consistent forwarding behavior in the network is > > > > > required. This document defines the policies used to resolve these > > > > > occurrences. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Please note that it may take a couple of minutes from the time of > > > > > submission until the htmlized version and diff are available at > > tools.ietf.org. > > > > > > > > > > The IETF Secretariat > > > > > > > > > > _______________________________________________ > > > > > spring mailing list > > > > > [email protected] > > > > > 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. > > > > > > __________________________________________________________ > > __________________________________________________________ > > _____ > > > > 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, France Telecom - > > 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 authorization. > > If you have received this email in error, please notify the sender and > > delete > > this message and its attachments. > > As emails may be altered, France Telecom - Orange shall not be liable if > > this > > message was modified, changed or falsified. > > Thank you. _________________________________________________________________________________________________________________________ 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 [email protected] https://www.ietf.org/mailman/listinfo/spring
