Hi Les, Thanks for initiating the thread on SRGB inconsistency. Please see some comments inlined [Bruno]
From: Les Ginsberg (ginsberg) [mailto:[email protected]] Sent: Monday, January 04, 2016 6:55 AM To: DECRAENE Bruno IMT/OLN; [email protected] Subject: draft-ginsberg-spring-conflict-resolution: SRGB INCONSISTENCY 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). [Bruno] This seems like a valid option. I would not seem many difference compared to the "Drop All" options which drops all the SRGB ranges. The main difference would probably be the consequences on the local segments (e.g. adjacency segments) which would be dropped with this proposal and kept with the "Drop all option" 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. [Bruno] Agreed. However bug happens, hence we need to consider this case and define the behavior. Hence the discussion on what is the behavior we are looking for. It then seems appropriate to put the onus on the originating router [Bruno] We can clearly blame the originating router, and as a network operator, I will certainly. But that does not change the fact that an incorrect advertisement has been send. to only send valid SRGB advertisements rather than forcing all the receivers to try to "correct" the invalid information in some consistent way. [Bruno] The wrong advertisement has been sent and we need receivers to detect the error and react on it in a consistent manner. We are mostly not trying to "correct" anything. We are discussion what to be dropped and what to be kept, and the limit is not so easy to make. This has a number of advantages: 1. It is by far the simplest to implement [Bruno] It's not clear to me why this option would be significantly simpler to implement than the "Drop all" or "Drop from the conflict" option. Since this seems obvious for you ("by far"), could you please help me/us understand why and how much simpler. 2. It isolates the router which is untrustworthy [Bruno] So does "Drop all", so does dropping all its IGP adjacency given that this router is "untrustworthy", since this would really isolate the router. 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 [Bruno] That would be an argument to drop all IGP adjacency rather than just considering that SR does not work. What I'm trying to say, is that we'll probably all agree on dropping the conflicting/wrong advertisements. If you want to go beyond and drop valid advertisements, it's difficult to draw the limit between valid advertisement that you/one would considered potentially untrustworthy and valid advertisement that you/one would considered trustworthy. If we had that we are not "one" but many, this may explain why this gets difficult to find an agreement. 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. [Bruno] Agreed for the invalid info. For valid info, this is very debatable and difficult to draw the limit. We could say that such buggy implementation should be removed whole all networks worldwide for at least N years if you really want to put the bar very high. Works for me. 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? [Bruno] This sounds like you are not considering the proposition to describe an evaluate all/main options. As already expressed, I don't think that's will help on building the consensus. To specifically answer your question, I don't see why this proposition would be preferred to the "Drop all" or "Drop from the conflict" options. And here comes the needs to share the analysis on the requirements and the pro & con. -- Bruno Les _________________________________________________________________________________________________________________________ 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
