Les,
it seems I missed most of the party… bad luck ;-) I fully agree with your approach and it looks we getting very close to “rough consensus” here. s. > On Jan 12, 2016, at 10:06 PM, Les Ginsberg (ginsberg) <ginsb...@cisco.com> > wrote: > > Bruno – > > Taking a step back – resummarizing my position: > > 1)SRGB configuration is a local matter. Conforming to the specification > requirement of NOT advertising overlapping SRGB ranges is totally within the > control of the local node. Misconfigurations can and MUST be detected BEFORE > they are advertised. > > 2)Receivers of an invalid SRGB MUST ignore the SRGB and treat the sending > node as NOT SR-MPLS capable. > > 3)All proposals to use part of the invalid advertisement run the risk of > making the problem worse and are based upon assumptions which cannot be > verified. > > 4)AS there is no valid reason why a node should send an invalid range (see #1 > above) I have no interest in investing analysis time or implementation and > test time in “guess work”. > > When we start discussing the second topic (SID conflicts) we have a > qualitatively different context. There independent configurations are in play > – so a single node does not have full control, human error plays a role, and > it makes sense to analyze the best resolution strategy. > But in the case of SRGB the local node has full control, human error can be > detected before it is advertised, and there simply is no justification for > trying to compensate for an implementation which has clearly shown it is > untrustworthy. > > Les > > > From: bruno.decra...@orange.com [mailto:bruno.decra...@orange.com] > Sent: Tuesday, January 12, 2016 9:50 AM > To: Les Ginsberg (ginsberg) > Cc: spring@ietf.org; Henderickx, Wim (Wim) > Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB > INCONSISTENCY > > Les, > > Please see inline [Bruno2] > > From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] > Sent: Tuesday, January 12, 2016 4:38 PM > To: DECRAENE Bruno IMT/OLN > Cc: spring@ietf.org; Henderickx, Wim (Wim) > Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB > INCONSISTENCY > > Bruno - > > From: bruno.decra...@orange.com [mailto:bruno.decra...@orange.com] > Sent: Tuesday, January 12, 2016 3:51 AM > To: Les Ginsberg (ginsberg) > Cc: spring@ietf.org; Henderickx, Wim (Wim) > Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB > INCONSISTENCY > > Les, > > Please see inline 1 point below [Bruno] > > From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] > Sent: Tuesday, January 12, 2016 12:41 AM > To: Fedyk, Don; HENDERICKX, Wim (Wim); DECRAENE Bruno IMT/OLN > Cc: LITKOWSKI Stephane SCE/OINIS; Martin Horneffer; spring@ietf.org > Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB > INCONSISTENCY > > Don - > > From: Fedyk, Don [mailto:don.fe...@hpe.com] > Sent: Monday, January 11, 2016 3:06 PM > To: Les Ginsberg (ginsberg); HENDERICKX, Wim (Wim); bruno.decra...@orange.com > Cc: LITKOWSKI Stephane SCE/OINIS; Martin Horneffer; spring@ietf.org > Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB > INCONSISTENCY > > Hi Les > > So you are saying a node that generates inconsistent SRGB (overlapping > ranges) all by itself should be treated Segment routing incapable and this > should be easy to detect by any correctly performing neighbor? > [Les:] Yes. Detection is easy – you simply check for overlapping ranges in > the advertisement from an individual node. > What is generating all the discussion is whether we should treat that node as > SR-MPLS incapable (a couple of variants there) or try to massage the received > information into a partially usable form. > > This is probably as good a time as any for me to reply to the latter proposal. > > All of the “use some of the information” variants (detailed at length in > Bruno’s posts) depend upon the node which sent the inconsistent SRGB > information itself performing the same transformation as the receivers. > [Bruno] This is a good technical point to identify. Thanks. I’ll add it in > the text. IINM, among the options being discussed: > Drop all, Drop from conflict, SR incapable do _not_ require any action on the > advertising node. not to mention consistent action with all others nodes. > > [Les2:] Drop from conflict makes an assumption that the faulty node is using > the ranges in the order advertised and that the reason the conflict exists is > because the later ranges were configured incorrectly. But we don’t know this > for certain. For example – the intended set of ranges is: > > [1000, 1099] > [2000, 2099] > > But something gets mangled when formatting the sub-TLV and what is advertised > turns out to be: > > [1000, 2099] > [2000, 2099] > > Using drop from conflict assumes you can use SIDs 0 – 1099 safely, but in > fact SIDs greater than 99 will use a label that the faulty node (which is > using the first set of ranges above) is NOT using for SR. > > This looks less egregious than other options only because the assumption that > the first range which is advertised is correct seems “reasonable” or “likely” > – but in fact we don’t know that. > > [Bruno2] Yes, and I have updated the text in my document to include your > point.. But I don’t think it’s about « reasonable” or “likely”. In my view, > it’s about trusting (or not) a received data which is correct from both a > syntax and semantic perspective. > We could define an option which would be dropping before the conflict. Would > that make a difference for you? > Because, I can equally build an example where your proposition would be > erroneous. e.g. > the intended set of ranges is: > [1000, 1099] > [2000, 2099] > > But something gets mangled when using formatting the sub-TLV and what is > advertised turns out to be: > [1000, 1199] > [2000, 2099] > > You believe you can use SID 110 based on the assumption that the ranges which > are advertised are correct, but in fact you don’t know that. > > And if we don’t believe in data which looks like correct from both a syntax > and semantic perspective, we should stop using protocols. > > That being said, I think we now have identified the key point of the > discussions. If so, now it would be about making a trade-off between Traffic > dropping or mis-routing. (as personally I see “implementation complexity” > being a significant point, compared these 2.) > > -- > > Drop the conflicting one, Merge, Merge and re-order _do_ require a new > behavior on the advertising node, consistent with all others nodes. > > [Les:] Agreed. > > But there is a higher order issue here for me – which is that all options > other than “Drop all” variants have to make an assumption about the faulty > node behavior which cannot be verified – which means the attempt to minimize > the damage may actually do further harm. This is not acceptable to me. > > Les > > Please comment if you disagree. > -- Bruno > > This to me is a non-starter. You have a node which has a bug in its > implementation. Trusting that the node will recognize that it has sent > invalid info and needs to transform it when using it internally isn’t > reasonable. Whether the bug which caused invalid info to be sent also affects > the use of that information internally is something you simply have no way to > know. Basing the behavior of the rest of the network on that assumption isn’t > reasonable to me – attempts to determine which data transformation might > yield “better” results is pure guesswork since you cannot rely on a buggy > implementation behaving in a predictable way. > > Les > > > Don > > From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Les Ginsberg > (ginsberg) > Sent: Monday, January 11, 2016 5:37 PM > To: Fedyk, Don; HENDERICKX, Wim (Wim); bruno.decra...@orange.com > Cc: LITKOWSKI Stephane SCE/OINIS; Martin Horneffer; spring@ietf.org > Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution: SRGB > INCONSISTENCY > > Folks – > > This thread is about SRGB inconsistency. SRGB inconsistency is an INTRA-node > issue. There is no SRGB conflict issue between nodes. > > There will be a separate thread about SID conflict issues – where inter-node > conflicts certainly are possible – but that is NOT what we are discussing in > this thread. > > Perhaps some folks would like to revise their responses with this in mind? > > Les > > > From: Fedyk, Don [mailto:don.fe...@hpe.com] > Sent: Monday, January 11, 2016 1:41 PM > To: HENDERICKX, Wim (Wim); bruno.decra...@orange.com > Cc: Les Ginsberg (ginsberg); Martin Horneffer; spring@ietf.org; LITKOWSKI > Stephane SCE/OINIS > Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB > INCONSISTENCY > > Hi Wim > > If I understand your Option 1) it can occur, for example, if two nodes that > have a conflicting SRGB but they are not directly connected and as such there > can be a race condition where they advertise SRGB conflict at roughly the > same time. So nodes in the middle have to decide who wins. (If that is the > case, that is the same issue we had in SPB for certain conflicts and the > solution was to use NodeID as a tie breaker to decide which node wins.) In > the SRGB case the loosing Node would also receive the winning nodes SRGB and > would “know” there is a conflict and it lost. It is true that the looser > could have had the SRGB established for a long time and suddenly become > Segment Routing incapable because of a higher priority node’s conflicting > config. However I think that is the nature of this situation SRGB > information it must be consistent. The thing to make sure of is that any > SRGB configuration can be relatively easily migrated to a non-conflicting > range and a configuration model that does not make it easy to accidentally > create SRGB conflicts into an existing network. > > Not sure I follow your option 2 but option 1 can be easy to determine winners > and losers (not right and wrong J ). > > Cheers, > Don > > From: spring [mailto:spring-boun...@ietf.org] On Behalf Of HENDERICKX, Wim > (Wim) > Sent: Monday, January 11, 2016 3:07 PM > To: bruno.decra...@orange.com > Cc: Les Ginsberg (ginsberg); Martin Horneffer; spring@ietf.org; LITKOWSKI > Stephane SCE/OINIS > Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution: SRGB > INCONSISTENCY > > I believe we agree to minimise the network impact when SRGB data is > inconsistent. > Option 1 is we ignore a advertisements of some nodes. The main issue I see > with this is determining who is right/wrong. Implementation is rather easy, > but you will impact traffic from certain nodes in some case as outlined below. > Option 2 is you try to disseminate something out of the information and try > to determine a consistent behaviour across all node. Implementation is more > difficult, but I believe there is more coverage/chances to meet the overall > objective. > > My 2 cents. > > From: Bruno Decraene <bruno.decra...@orange.com> > Date: Monday 11 January 2016 at 17:53 > To: Wim Henderickx <wim.henderi...@alcatel-lucent.com> > Cc: Martin Horneffer <m...@nic.dtag.de>, "Les Ginsberg (ginsberg)" > <ginsb...@cisco.com>, "spring@ietf.org" <spring@ietf.org>, Stephane Litkowski > <stephane.litkow...@orange.com> > Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB > INCONSISTENCY > > Hi Wim, > > I read that you are pointing out the difficulty to identify the inconsistency. > If so, this point is common to all options being discussed. > > I may be missing some of your points. This thread is about inconsistency in > the SRGB ranges advertised by _one_ node. I’m not sure to see your “startup > scenario” nor the “merge network scenario”. Could you please elaborate? > > Thanks, > Bruno > > From: Henderickx, Wim (Wim) [mailto:wim.henderi...@alcatel-lucent.com] > Sent: Wednesday, January 06, 2016 8:19 PM > To: DECRAENE Bruno IMT/OLN > Cc: Martin Horneffer; Les Ginsberg (ginsberg); spring@ietf.org; LITKOWSKI > Stephane SCE/OINIS > Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution: SRGB > INCONSISTENCY > > If you avoid an inconsistency in an SRGB announcement there is multiple > scenario’s in which you determine who is right/wrong: > • Assume you are in a startup scenario, it is very hard to determine > who is consistent and who is not > • If you are in a running network and you add a new node or have a > different config on 1 node, you can determine it > • If you merge a network and the config is wrong in one part but not in > the other part of the network. > > I see this strategy work in some case but in others I see challenges to > determine what is right and what is wrong, hence my question > > From: Bruno Decraene <bruno.decra...@orange.com> > Date: Wednesday 6 January 2016 at 19:03 > To: Wim Henderickx <wim.henderi...@alcatel-lucent.com> > Cc: Martin Horneffer <m...@nic.dtag.de>, "Les Ginsberg (ginsberg)" > <ginsb...@cisco.com>, "spring@ietf.org" <spring@ietf.org>, Stephane Litkowski > <stephane.litkow...@orange.com> > Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB > INCONSISTENCY > > Hi Wim, > > Many thanks for taking part in the discussion. > Could you please elaborate? e.g. what do you mean by ”who” and “wrong” on > what? > I could see multiple interpretations, but it would probably be faster if you > elaborate by yourself. > > Thanks > -- Bruno > > From:spring [mailto:spring-boun...@ietf.org] On Behalf Of Henderickx, Wim > (Wim) > Sent: Tuesday, January 05, 2016 7:41 PM > To: Martin Horneffer; Les Ginsberg (ginsberg); spring@ietf.org; LITKOWSKI > Stephane SCE/OINIS > Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution: SRGB > INCONSISTENCY > > My main question on the proposal is how do we tell who is right and who is > wrong? > > From: spring <spring-boun...@ietf.org> on behalf of Martin Horneffer > <m...@nic.dtag.de> > Date: Tuesday 5 January 2016 at 13:05 > To: "Les Ginsberg (ginsberg)" <ginsb...@cisco.com>, "spring@ietf.org" > <spring@ietf.org>, Stephane Litkowski <stephane.litkow...@orange.com> > Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution: SRGB > INCONSISTENCY > > Hello Les, Acee, Stephane, everyone, > > happy new year! > > From an operator's (carrier's) point of view I clearly and strongly support > this alternative solution: Treat an inconsistent set of SRGB announcements as > broken and ignore it. > > - It is the simplest solution. > - It only affects traffic of the badly configured and implemented router. > - It gives a clear indication to the operator where they have to repair > something. > > With respect to Stephane's comments: > - I would also support a repetition or clarification that an inconsistent > set of SRGB annoucements is broken. > - No strong opinion from my side as how to define the offending node as > non-SR-capable as I don't see any use case for nodes with only adjacency SIDs. > > Best regards, > Martin > > > Am 04.01.16 um 06:55 schrieb Les Ginsberg (ginsberg): > One of the topics discussed in > https://datatracker.ietf.org/doc/draft-ginsberg-spring-conflict-resolution/ > is how to handle inconsistent SRGB advertisements from a given node. > > The draft defines one possible solution -from Section 2: > > " Each range is examined in the order it was advertised. If it does > not overlap with any advertised range which preceded it the > advertised range is used. If the range overlaps with any preceding > range it MUST NOT be used and all ranges advertised after the first > encountered overlapping range also MUST NOT be used." > > This is one instance of a class of solutions which attempt to make use of > part of the advertisements even when there is some inconsistency (overlap) in > the set of SRGB ranges received. A more complete discussion of this class of > solutions can be seen in > https://mailarchive.ietf.org/arch/attach/spring/txtk0n56G.txt - many thanx to > Bruno for writing this. > > However, there is an alternative solution which was suggested (notably by > Acee Lindem) after the draft was written. This alternative is to ignore the > entire set of SRGB advertisements and treat the problematic router as if it > were not SR MPLS capable. This alternative was discussed during the > presentation in SPRING WG at IETF94 (see > https://www.ietf.org/proceedings/94/slides/slides-94-spring-2.pdf slide #3). > It is also discussed in Bruno's post > (https://mailarchive.ietf.org/arch/attach/spring/txtk0n56G.txt - see Section > 2.2). > > The basis of the alternative solution is that a correct implementation should > never allow inconsistent SRGB ranges to be successfully configured (let alone > advertised). So this is not a case of a misconfiguration – it is a case of a > defective implementation. It then seems appropriate to put the onus on the > originating router to only send valid SRGB advertisements rather than forcing > all the receivers to try to "correct" the invalid information in some > consistent way. This has a number of advantages: > > 1. It is by far the simplest to implement > 2. It isolates the router which is untrustworthy > 3. As the problem can only occur as a result of a defective > implementation the behavior of the originating router is unpredictable – it > is therefore safer not to use the information > > It is worth noting that since the invalid advertisement is the result of some > sort of defect in the originating router’s implementation, it is not safe to > assume that the source will actually be using the advertised SRGB in a manner > consistent with the selective choice made by the receiving routers. > > I therefore propose that the above quoted text from > https://datatracker.ietf.org/doc/draft-ginsberg-spring-conflict-resolution/ > be replaced with the following: > > “The set of received ranges is examined . If there is overlap between any two > of the advertised ranges the entire SRGB set is considered invalid and is > ignored. > The originating router is considered to be incapable of supporting the > SR-MPLS forwarding plane. Routers which receive an SRGB advertisement with > overlapping ranges SHOULD report the occurrence.” > > Comments? > > Les > > > > _______________________________________________ > spring mailing list > spring@ietf.orghttps://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, > 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, > 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, > 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
