It’s a very clear statement and reasonable. I support this. Best regards, Mach
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Les Ginsberg (ginsberg) Sent: Wednesday, January 13, 2016 5:06 AM To: bruno.decra...@orange.com Cc: spring@ietf.org; Henderickx, Wim (Wim) Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution: SRGB INCONSISTENCY 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> [mailto:bruno.decra...@orange.com] Sent: Tuesday, January 12, 2016 9:50 AM To: Les Ginsberg (ginsberg) Cc: spring@ietf.org<mailto: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<mailto: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> [mailto:bruno.decra...@orange.com] Sent: Tuesday, January 12, 2016 3:51 AM To: Les Ginsberg (ginsberg) Cc: spring@ietf.org<mailto: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<mailto: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<mailto:bruno.decra...@orange.com> Cc: LITKOWSKI Stephane SCE/OINIS; Martin Horneffer; spring@ietf.org<mailto: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<mailto:bruno.decra...@orange.com> Cc: LITKOWSKI Stephane SCE/OINIS; Martin Horneffer; spring@ietf.org<mailto: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<mailto:bruno.decra...@orange.com> Cc: Les Ginsberg (ginsberg); Martin Horneffer; spring@ietf.org<mailto: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 ☺ ). 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<mailto:bruno.decra...@orange.com> Cc: Les Ginsberg (ginsberg); Martin Horneffer; spring@ietf.org<mailto: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<mailto:bruno.decra...@orange.com>> Date: Monday 11 January 2016 at 17:53 To: Wim Henderickx <wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>> Cc: Martin Horneffer <m...@nic.dtag.de<mailto:m...@nic.dtag.de>>, "Les Ginsberg (ginsberg)" <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>, "spring@ietf.org<mailto:spring@ietf.org>" <spring@ietf.org<mailto:spring@ietf.org>>, Stephane Litkowski <stephane.litkow...@orange.com<mailto: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<mailto: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<mailto:bruno.decra...@orange.com>> Date: Wednesday 6 January 2016 at 19:03 To: Wim Henderickx <wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>> Cc: Martin Horneffer <m...@nic.dtag.de<mailto:m...@nic.dtag.de>>, "Les Ginsberg (ginsberg)" <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>, "spring@ietf.org<mailto:spring@ietf.org>" <spring@ietf.org<mailto:spring@ietf.org>>, Stephane Litkowski <stephane.litkow...@orange.com<mailto: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<mailto: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<mailto:spring-boun...@ietf.org>> on behalf of Martin Horneffer <m...@nic.dtag.de<mailto:m...@nic.dtag.de>> Date: Tuesday 5 January 2016 at 13:05 To: "Les Ginsberg (ginsberg)" <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>, "spring@ietf.org<mailto:spring@ietf.org>" <spring@ietf.org<mailto:spring@ietf.org>>, Stephane Litkowski <stephane.litkow...@orange.com<mailto: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<https://www.ietf.org/proceedings/94/slides/slides-94-spring-2.pdf%20slide%20#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.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. _________________________________________________________________________________________________________________________ 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
