Hi Les, Pls find more inline.
From: Les Ginsberg (ginsberg) [mailto:[email protected]] Sent: Tuesday, January 05, 2016 00:34 To: LITKOWSKI Stephane SCE/OINIS; DECRAENE Bruno IMT/OLN; [email protected] Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB INCONSISTENCY Stephane - From: [email protected]<mailto:[email protected]> [mailto:[email protected]] Sent: Monday, January 04, 2016 12:55 AM To: Les Ginsberg (ginsberg); DECRAENE Bruno IMT/OLN; [email protected]<mailto:[email protected]> Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB INCONSISTENCY Hi Les, Happy new year. [Les:] And to you... I agree with your proposal. The text must state that there must be a local configuration mechanism that avoids sender to originate overlapping SRGB. [Les:] Hmmm...IS-IS draft (for example) already states (Section 3.1): <snip> The originating router MUST NOT advertise overlapping ranges. When a router receives multiple overlapping ranges, it MUST conform to the procedures defined in [I-D.ginsberg-spring-conflict-resolution]. <end snip> Isn't this sufficient? [SLI] I missed this, thanks. Anyway from a readability point of view, it would be good to recall that the protocol documents address the sender side. Do we have the same for BGP ? The issue with putting this text in the protocol doc, is that you need to ensure that all protocols will always have this restriction. It's not really a protocol thing, more a configuration management one ... In this case, as you mention, if a router receives overlapping SRGB, this is a bad behavior and we cannot guess if the forwarding plane is correctly programmed or not on the originator, so it is better to avoid it. Now regarding the sentence :" The originating router is considered to be incapable of supporting the SR-MPLS forwarding plane". Do we have something in the architecture document saying that advertising a SRGB is mandatory to use SR ? Pure theorical example : what if someone wants only to use Adj-SIDs in SR network ? there is no need to advertise a SRGB. Stating that the node must be considered as non SR capable is strong, it will also prevent the usage of Adj-SID which will work well without SRGB. If we consider that having a SRGB is mandatory, we need to have this requirement in the architecture document. [Les:] An interesting point. What I am after here is recognition that without a valid SRGB the indication from a node that it is capable of "processing SR MPLS encapsulated IPv4/IPv6 packets on all interfaces" does not apply. You are suggesting that a node which is not capable of supporting SR-MPLS dataplane for prefix-SIDs should still be allowed to support ADJ-SIDs - although it would have to be restricted to local SIDs (ADJ-SIDs can be assigned from the global SID space - just not the most common usage). While you may be right in that such a practice is not explicitly forbidden by any of the specifications, I am struggling to find a real world use case. Doing so certainly complicates implementations. Implementations today verify whether a node supports SR-MPLS before using SR-MPLS advertisements (prefix-SIDs, ADJ-SIDs). You are proposing that this logic be enhanced to treat the case where the node has sent an invalid SRGB as if the node is still SR-MPLS capable but for local SIDs only. I don't deny this could be done - I just don't understand why. Please help me understand why worrying about this case is useful??? [SLI] I'm was not suggesting to use only Adj-SID ... as I also do not see a real use case for that. I'm just saying that the specification does not prevent it. So may be let's prevent it ...so we can update the architecture document saying that advertising a valid SRGB is a must. There is something wrong to me here, because we will state that a node with invalid SRGB will be treated as non SR capable while the architecture does not forbid to not have a SRGB and does not say anything on how the architecture works with no SRGB (we can only guess that only Adj-SID can be used). Les Best regards, Stephane From: spring [mailto:[email protected]] On Behalf Of Les Ginsberg (ginsberg) Sent: Monday, January 04, 2016 06:55 To: DECRAENE Bruno IMT/OLN; [email protected]<mailto:[email protected]> Subject: [spring] 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). 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 _________________________________________________________________________________________________________________________ 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
