Wim - From: HENDERICKX, Wim (Wim) [mailto:[email protected]] Sent: Tuesday, January 12, 2016 1:02 AM To: Les Ginsberg (ginsberg); Fedyk, Don; [email protected] Cc: Martin Horneffer; [email protected]; LITKOWSKI Stephane SCE/OINIS Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution: SRGB INCONSISTENCY
Les, in your scenario you assume 2 issues on the node. [Les:] Actually I am trying not to make any assumptions. What we know is that the router has advertised an invalid SRGB. This can only be because of a bug. At this point I am saying I do not know what the nature of the bug is and I cannot predict with any reliability what other impacts it will have. Any of the options you consider below depend upon an assumption that the node which has advertised an invalid SRGB will behave in a certain way – which is something you cannot know. And any of the choices you make could actually make the problem worse by introducing loops or forwarding traffic to the wrong destination. The network is compromised because you have a faulty node. Let’s not risk making it worse by trying to be clairvoyant. Les First it advertises an inconsistent SRGB and 2nd it behaves wrong in the data-plane. My view is that the reason for agreeing on a consistent behaviour ensures constructing a SRGB out of the info received to minimise traffic impact. If the control plane and data-plane is faulty on a node, there is little to do, other than fixing the faulty SW. We need to think in which circumstances this will happen and what the result would be: I am trying to list different option to determine what the best strategy is for achieving this by thinking what can happen: * Adding a new node which got wrongly configured or a startup scenario: option 1 and option 2 can work to minimise network impact * Merging networks which were both in operation: I believe option 2 is better for minimising network impact, since you try to make something work * Faulty SW: neither option is helping * Other? I am not biased on one option vs another, trying to analyse the different behaviours/strategies. From: "Les Ginsberg (ginsberg)" <[email protected]<mailto:[email protected]>> Date: Tuesday 12 January 2016 at 06:28 To: Wim Henderickx <[email protected]<mailto:[email protected]>>, "Fedyk, Don" <[email protected]<mailto:[email protected]>>, Bruno Decraene <[email protected]<mailto:[email protected]>> Cc: Martin Horneffer <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, Stephane Litkowski <[email protected]<mailto:[email protected]>> Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB INCONSISTENCY Wim – Please explain to me how the receivers – who you are proposing to make one of the choices below – know what the node which advertised the overlapping ranges is actually doing when it installs local labels in its forwarding plane? For example, suppose in the example below the receivers choose to ignore the second label range [1099, 2099]. So the neighbor of the faulty node pushes label 5000 for the prefix which has SID 100. What happens when the packet arrives at the problematic node? A)If “faulty node” is using the overlapping range, then label 5000 will be associated with the prefix with SID 1100 – and the packet will be forwarded out some interface using the label that “faulty node’s neighbor” has associated with SID 1100. B)If “faulty node” is NOT using anything but the first range, then label 5000 isn’t an SR assigned label. The packet might get dropped – or it might get forwarded using an LDP label (for example) if LDP happens to be using label 5000. C)Maybe “faulty node” has an inconsistency between what it advertised and what it is actually using. It meant to advertise: [1000, 1099] [2000, 2099] [5000, 6099] but the second entry got corrupted during formatting. Now label 5000 is associated with the prefix having SID 200 – and we have similar behavior to “A” above. The list of possibilities goes on and on – and yes – one of the possibilities is that you “get lucky” and faulty node happens to be doing what you hoped it might and forwarding “works”. But there is no way for you to know what faulty node is actually doing. So all this speculation about which choice might result in the “best behavior” is like playing the lottery. Why would we want to do this? I certainly do not. Les From: HENDERICKX, Wim (Wim) [mailto:[email protected]] Sent: Monday, January 11, 2016 8:18 PM To: Fedyk, Don; [email protected]<mailto:[email protected]> Cc: Les Ginsberg (ginsberg); Martin Horneffer; [email protected]<mailto:[email protected]>; LITKOWSKI Stephane SCE/OINIS Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution: SRGB INCONSISTENCY Don, I get that but the key question is if the looser that is picked is the one who creates the biggest network impact or not. This is what I mean with right or wrong. I just want to have a discussion on both options and agree on the best strategy to minimise the impact in a network when this would happen. Option 2 is basically something along this line and was suggested before afaik. A) [1000, 1099] => overlap with second [1099, 2099] => overlap with first [5000, 6099] ð Ignore label range [1099, 2099], sid index 100 will be translated to label 5000. sid index > 200 will not be translated + information logged B) [1000, 1099] => overlap with second [1099, 2099] => overlap with first & last [2099, 3099] => overlap with second ð Ignore label range [1099, 2099] & [2099, 3099], sid index 0 will be translated to label 1000. sid index > 100 can not be translated + information logged C) [1000, 1099] => overlap with last [2000, 2099] [900, 1000] => overlap with first ð Ignore label range [900, 1000] sid index 0 will be translated to label 1000. sid index > 200 can not be translated + information logged From: "Fedyk, Don" <[email protected]<mailto:[email protected]>> Date: Monday 11 January 2016 at 22:41 To: Wim Henderickx <[email protected]<mailto:[email protected]>>, Bruno Decraene <[email protected]<mailto:[email protected]>> Cc: "Les Ginsberg (ginsberg)" <[email protected]<mailto:[email protected]>>, Martin Horneffer <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, Stephane Litkowski <[email protected]<mailto:[email protected]>> 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:[email protected]] On Behalf Of HENDERICKX, Wim (Wim) Sent: Monday, January 11, 2016 3:07 PM To: [email protected]<mailto:[email protected]> Cc: Les Ginsberg (ginsberg); Martin Horneffer; [email protected]<mailto:[email protected]>; 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 <[email protected]<mailto:[email protected]>> Date: Monday 11 January 2016 at 17:53 To: Wim Henderickx <[email protected]<mailto:[email protected]>> Cc: Martin Horneffer <[email protected]<mailto:[email protected]>>, "Les Ginsberg (ginsberg)" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, Stephane Litkowski <[email protected]<mailto:[email protected]>> 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:[email protected]] Sent: Wednesday, January 06, 2016 8:19 PM To: DECRAENE Bruno IMT/OLN Cc: Martin Horneffer; Les Ginsberg (ginsberg); [email protected]<mailto:[email protected]>; 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 <[email protected]<mailto:[email protected]>> Date: Wednesday 6 January 2016 at 19:03 To: Wim Henderickx <[email protected]<mailto:[email protected]>> Cc: Martin Horneffer <[email protected]<mailto:[email protected]>>, "Les Ginsberg (ginsberg)" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, Stephane Litkowski <[email protected]<mailto:[email protected]>> 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:[email protected]] On Behalf Of Henderickx, Wim (Wim) Sent: Tuesday, January 05, 2016 7:41 PM To: Martin Horneffer; Les Ginsberg (ginsberg); [email protected]<mailto:[email protected]>; 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 <[email protected]<mailto:[email protected]>> on behalf of Martin Horneffer <[email protected]<mailto:[email protected]>> Date: Tuesday 5 January 2016 at 13:05 To: "Les Ginsberg (ginsberg)" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, Stephane Litkowski <[email protected]<mailto:[email protected]>> 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 [email protected]<mailto:[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, 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
