Hi Stephane, I agree with you.
I also noticed that in draft-ietf-spring-segment-routing-mpls we should have (probably) a better description on how to use SRGB and indexes. I propose to update draft-ietf-spring-segment-routing-mpls so that the conflict-resolution draft can point to it when referring to SRGB/index procedures. s. > On Jan 19, 2016, at 9:46 AM, [email protected] wrote: > > Hi Les, > > IMO, “treat the sending node as NOT SR-MPLS capable for globally scoped SIDs” > may lead to confusion and let think that only Adj-SID can be used. > “NOT SR-MPLS capable” is really strong, and may prevent the PHP case Bruno > was describing. > May be we can add a sentence to precise what the statement means like : “This > means that the sending node is not able to process MPLS labels mapped to > globally scope SIDs.”. > > > Stephane > > > From: spring [mailto:[email protected]] On Behalf Of Les Ginsberg > (ginsberg) > Sent: Saturday, January 16, 2016 01:13 > To: Uma Chunduri; DECRAENE Bruno IMT/OLN > Cc: [email protected]; Henderickx, Wim (Wim) > Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution: SRGB > INCONSISTENCY > > Uma – > > It is true that the neighbor of the dysfunctional node cannot install > outgoing labels for paths via the dysfunctional node. That is precisely the > meaning of “treat the sending node as NOT SR-MPLS capable for globally scoped > SIDs”. > > This does not mean that “global SID advertisements should be ignored”. And I > do not see that it could in any way be interpreted to imply that. > > Please hit the “reset button” and try looking at this with a fresh > perspective. J > > Les > > > From: Uma Chunduri [mailto:[email protected]] > Sent: Friday, January 15, 2016 3:56 PM > To: Les Ginsberg (ginsberg); [email protected] > Cc: [email protected]; Henderickx, Wim (Wim) > Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB > INCONSISTENCY > > Les, > > In-line [Uma]: > > -- > Uma C. > > From: Les Ginsberg (ginsberg) [mailto:[email protected]] > Sent: Friday, January 15, 2016 12:22 PM > To: Uma Chunduri; [email protected] > Cc: [email protected]; Henderickx, Wim (Wim) > Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB > INCONSISTENCY > > Uma – > > I have no idea how you translate: > > Receivers of an invalid SRGB MUST ignore the SRGB and treat the sending node > as NOT SR-MPLS capable for globally scoped SIDs. > > into > > Should not consider any global SIDs, because the advertised global SIDs are > not trustworthy any more > > SRGB defines the node-local label space which has been reserved for use by SR > on that node. > [Uma]: …and also the upstream neighboring node to compute and install the > outgoing label J. > > Global SIDs define the index which is to be used into the node specific SRGBs > to map the index into the correct node-specific label. > [Uma]: ..of both advertising node’s own SRGB locally and the SRGB of computed > shortest path neighbor. > > While I will do my best to make the language in the draft clear and > unambiguous, > > [Uma]: thx! > > I am frankly at a loss to understand how you concluded that the SRGB related > statement says anything whatsoever about SID advertisements. > [Uma]: because of this > “sending node as NOT SR-MPLS capable for globally scoped SIDs” > hence the conclusion of not using the global SIDs!! > > > Les > > > From: Uma Chunduri [mailto:[email protected]] > Sent: Friday, January 15, 2016 10:13 AM > To: Les Ginsberg (ginsberg); [email protected] > Cc: [email protected]; Henderickx, Wim (Wim) > Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB > INCONSISTENCY > > Les, > > Thanks. My quick response below [Uma2]: > > -- > Uma C. > > From: Les Ginsberg (ginsberg) [mailto:[email protected]] > Sent: Thursday, January 14, 2016 5:28 PM > To: Uma Chunduri; [email protected] > Cc: [email protected]; Henderickx, Wim (Wim) > Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB > INCONSISTENCY > > Uma – > > Thanx for the response. > Inline. > > From: Uma Chunduri [mailto:[email protected]] > Sent: Thursday, January 14, 2016 3:34 PM > To: Les Ginsberg (ginsberg); [email protected] > Cc: [email protected]; Henderickx, Wim (Wim) > Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB > INCONSISTENCY > > Dear Les, Bruno, > > Thanks for a great discussion on this sticky issue. > > Couple of things: > > 1. Les, I support advertising explicit SR capability of the node; > meaning this doesn’t have to be tied to one or more SRGB range > advertisements. > Though for example, OSPF draft doesn’t say anything about ‘no srgb ranges’ in > SID/Label Range TLV, my vote is to be explicit about it. > I also agree to change IS-IS document to change and to align to the rest. > > [Les:] IN the case of OSPFv2 there is a separate TLV for advertising > algorithm support. This can be used to infer SR-MPLS support for local labels > for IPv4. There is no language in the OSPFv2 draft which requires SRGB to be > sent. > In the case of OSPFv3, SR Forwarding Capabilities are advertised in the OSPF > Router Informational Capabilities TLV. Again there is no requirement to > advertise SRGB – so the forwarding capabilities info can be used to infer > support for SR-MPLS local SID support. > > If you think the OSPF draft language is not explicit enough I suggest you > make comments to the OSPF-WG list. > > 2. Revised proposal below is good and I agree on - there is no > dependency of SRGB for locally scoped ADJ side it should not be effected > because of incorrect SRGB. > - I would say making this change to remove support for local ADJ > sids because of incorrect received SRGB for anode is a bigger change for us > (E///) at least. > > >2)Receivers of an invalid SRGB MUST ignore the SRGB and treat the sending > >node as NOT SR-MPLS capable for globally scoped SIDs. > > A-----B----C-----D > > Consider the above network – if you are node A and you are dealing with a > “conflicting range from node D” but valid ranges from node B – you are saying > drop all prefixes with global SIDs. > > [Les:] No – no such statement is made. The statement is “treat the sending > node as NOT SR-MPLS capable for globally scoped SIDs.”. The sending node in > your example is “D”. No changes are made as regards SR-MPLS support for A, B, > C. This in fact is not much different than what you MUST do today even with a > valid SRGB – because you have to check whether the given SID is within the > (set of) SRGB range(s) advertised by your nexthop. If your nexthop is D then > in this example no global SID will map to a valid label in D’s forwarding > plane – so C MUST NOT install an outgoing label when forwarding traffic via D. > > [Uma2]: Precisely and I initially expected only node C, which eventually uses > node D’s SRGB recognizes the conflicts in SRGB and consider D is ”NOT > SR-MPLS” capable. But the above statement doesn’t reflect this: > “Receivers of an invalid SRGB MUST ignore the SRGB” è here D’s SRGB is > received by all nodes and for this example at node A; per this statement it > would ignore these SRGB’s during decision process and w.r.t “sending node as > NOT SR-MPLS capable for globally scoped SIDs.” Should not consider any > global SIDs, because the advertised global SIDs are not trustworthy any more > based on the earlier discussions on this thread. > Perhaps as per your response above, you might want to say the “neighboring > upstream receivers should not use these invalid SRGB ranges MUST ignore the…”. > > Evidently, the difference here is to abandon the node which is sending > “corrupted SRGBs” (as now its mandatory to have sending side checks) as an > SR-MPLS node for global SIDs by entire network or only upstream neighbors > which could be installs the labels in the forwarding with these “corrupted > SRGBs”. I prefer modified language to reflect the intent correctly. > > Hope this helps. > > Les > > > But, I see you are asking this even though outgoing label is completely > governed by node B (which is advertising valid ranges) in this case. Though > this is a bigger change and ideally should be applicable to only C , it is > ok to me given the consensus on when senders MUST advertise (non-conflicting > ranges) and still conflicting range is seen. > > Most of the checks whatever possible for SRGBs, mapping server SID range > conflicts etc. must be prevented locally and this should be mandated > (individual protocol/architecture/conflict document) somewhere. However > mapping server SID ranges is a completely different beast and can be > discussed some other day on how a receiver should handle the conflicts there. > > -- > Uma C. > > > From: spring [mailto:[email protected]] On Behalf Of Les Ginsberg > (ginsberg) > Sent: Thursday, January 14, 2016 12:53 PM > To: [email protected] > Cc: [email protected]; Henderickx, Wim (Wim) > Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution: SRGB > INCONSISTENCY > > Bruno (and everyone) – > > The remaining point to be discussed seems to be whether – when an invalid > SRGB is detected by receivers – the offending node should be considered > SR-MPLS incapable for both local and global SIDs or whether we should only > consider the node MPLS-SR incapable for Global SIDs. The latter proposal has > some merit because SRGB is only used in support of global SIDs. However, in > order to do this we must insure that all the protocol drafts are consistent > with this concept i.e. that SR-MPLS support has two scopes and that the > conditions necessary for supporting each of the two scopes are not identical. > > For locally scoped SIDs it is sufficient that the node indicate that it > supports SR-MPLS for specific address families. > For Globally scoped SIDs the node also has to provide a valid SRGB. > > My reading of the existing protocol drafts in this regard is as follows: > > https://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv3-segment-routing-extensions/ > https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-extensions/ > > OSPF drafts are consistent with the above. > > https://www.ietf.org/id/draft-ietf-idr-bgp-prefix-sid-02.txt > > BGP only has defined support for globally scoped SIDs – so no issue here > either. > > https://www.ietf.org/id/draft-ietf-isis-segment-routing-extensions-06.txt > > Here there is an issue. Section 3.1 specifies the contents of the > SR-Capabilities Sub-TLV which includes advertisement of both the SR-MPLS > support per address-family AND the SRGB. The text states: > > “One or more SRGB Descriptor entries…” > > So currently it is not valid to send the sub-TLV with no SRGB Descriptors. > This text would have to be altered to indicate that the SRGB Descriptors MAY > be omitted. This could cause backwards compatibility issues with early > deployments as a strict interpretation of the draft would cause such a > sub-TLV to be rejected. However, given that local SR-MPLS support only is an > unlikely case, I think such a change could be acceptable as there should be > sufficient time for all existing implementations to be upgraded before such > an exceptional case would need to be deployed (if indeed that is ever > required). > > Assuming that the IS-IS draft authors and the WG are willing to make the > appropriate change in the IS-IS draft then I provide a revised definition of > how to handle an invalid SRGB below. I ask all the folks who have already > indicated their approval/disapproval of the previous proposal to review the > revised proposal and indicate their opinion. Of course I also want to > encourage folks who have not yet voiced their opinion to respond as well. J > > Thanx for all the good discussion – I think the proposal is better for it. > > Les > > Revised Proposal: > 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 for globally scoped SIDs. > > 3)Support for locally scoped SIDs is unaffected by the > presence/absence/validity of SRGB advertisements. > > > From: [email protected] [mailto:[email protected]] > Sent: Thursday, January 14, 2016 12:30 AM > To: Les Ginsberg (ginsberg) > Cc: [email protected]; Henderickx, Wim (Wim) > Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB > INCONSISTENCY > > Les, > > Please see inline [Bruno2] > > From: Les Ginsberg (ginsberg) [mailto:[email protected]] > Sent: Thursday, January 14, 2016 12:49 AM > To: DECRAENE Bruno IMT/OLN > Cc: [email protected]; Henderickx, Wim (Wim) > Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB > INCONSISTENCY > > Bruno - > > From: [email protected] [mailto:[email protected]] > Sent: Wednesday, January 13, 2016 1:13 AM > To: Les Ginsberg (ginsberg) > Cc: [email protected]; Henderickx, Wim (Wim) > Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB > INCONSISTENCY > > Les, > > Thanks for the summary of your position. > Mine inlined [Bruno] > > > From: Les Ginsberg (ginsberg) [mailto:[email protected]] > Sent: Tuesday, January 12, 2016 10:06 PM > To: DECRAENE Bruno IMT/OLN > Cc: [email protected]; 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. > [Bruno] Agreed. > > 2)Receivers of an invalid SRGB MUST ignore the SRGB and treat the sending > node as NOT SR-MPLS capable. > [Bruno] “Drop all” (SRGB range) is equally safe. I don’t recall that you > provided any argument against it. > > [Les:] In an earlier reply to Stephane I stated: > > <snip> > 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. > > <end snip> > [Bruno2] 3 points : > a) Safety/validity: I’m still reading no argument saying that « Drop All” is > less safe than “SR Incapable”. Can we agree on this? > b) Use cases: Local Segments and in particular Adjacency Segments certainly > have use cases. Are you arguing this? If not, “Drop All” has the benefit of > not dropping the traffic crossing that node using Local/Adjacency segments. > More on this next few lines. > c) Implementation complexity: 1) this is difficult to measure hence agree on. > If your implementation were open source, we could probably discuss it more > easily. 2)This may be implementation specific. 3) We have already discussed > this https://mailarchive.ietf.org/arch/msg/spring/nAoOL8tCF4qXHYK7c2dIu3Xd47A > In short, before using a global SID, existing implementations must also > check that this global SID falls within the SRGB. Hence dropping all the SRGB > ranges would already be identified by implementation with no changes. > > In subsequent comments no one has indicated that there is such a use case. In > the interest of simplicity I am therefore in favor of the “NOT SR-MPLS > capable” approach. > [Bruno2] > - I did indicated use case in existing implementations: > https://mailarchive.ietf.org/arch/msg/spring/FuMaSOnwO3WvtmMWT9SzV8jbTpE > - In the context of this discussion, one router implementation/controller > would still be able to cross/use the node advertising conflicting SRGB ranges > by using a local adjacency segment. You may not want to implement this use > case, but I don’t see a reason to forbid this. > - And again, local/adjacency are already defined and implemented, because > there were use cases. > > 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. > [Bruno] This part is about trade-off and opinions. I agree that the > consequences of misrouting are more adverse than the one of dropping traffic. > In theory, relative probability of occurrence would also need to be taken > into account. > I had the impression that we could agree on Drop all, based on a shared > analysis. > > 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”. > [Bruno] We agree that there is no valid reason and that this is a case of > error. But bug do happens. If we need a consistent behavior across the > network, we need to specify the reaction to errors. I personally think that > this choice would be better if based on a shared analysis. It bothers me a > bit that the editor of the candidate document has no interest in investing > analysis time. > > [Les:] I don’t know if I can make you feel more comfortable, but let me > reemphasize why I do not see analysis in this case as worthwhile. > All options which involve using a portion of the invalid advertisement > require us to make assumptions about what we think the node which advertised > the invalid range is actually doing when installing labels in its forwarding > plane. Nothing about the invalid advertisement can be reliably used to know > what the advertising node is doing – nor to predict what behavior is more > likely. It is therefore not possible to do a tradeoff analysis which is other > than pure guesswork. I don’t actually need to do the analysis to know this. > > Les > > 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. > [Bruno] “There is simply no justification” is an overstatement. Looking > outside of SR, discussion on error handling in BGP could be found in > draft-ietf-grow-ops-reqs-for-bgp-error-handling and RFC 7606. > -- Bruno > > Les > > > From: [email protected] [mailto:[email protected]] > Sent: Tuesday, January 12, 2016 9:50 AM > To: Les Ginsberg (ginsberg) > Cc: [email protected]; Henderickx, Wim (Wim) > Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB > INCONSISTENCY > > Les, > > Please see inline [Bruno2] > > From: Les Ginsberg (ginsberg) [mailto:[email protected]] > Sent: Tuesday, January 12, 2016 4:38 PM > To: DECRAENE Bruno IMT/OLN > Cc: [email protected]; Henderickx, Wim (Wim) > Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB > INCONSISTENCY > > Bruno - > > From: [email protected] [mailto:[email protected]] > Sent: Tuesday, January 12, 2016 3:51 AM > To: Les Ginsberg (ginsberg) > Cc: [email protected]; 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:[email protected]] > 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; [email protected] > Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB > INCONSISTENCY > > Don - > > From: Fedyk, Don [mailto:[email protected]] > Sent: Monday, January 11, 2016 3:06 PM > To: Les Ginsberg (ginsberg); HENDERICKX, Wim (Wim); [email protected] > Cc: LITKOWSKI Stephane SCE/OINIS; Martin Horneffer; [email protected] > 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:[email protected]] On Behalf Of Les Ginsberg > (ginsberg) > Sent: Monday, January 11, 2016 5:37 PM > To: Fedyk, Don; HENDERICKX, Wim (Wim); [email protected] > Cc: LITKOWSKI Stephane SCE/OINIS; Martin Horneffer; [email protected] > 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:[email protected]] > Sent: Monday, January 11, 2016 1:41 PM > To: HENDERICKX, Wim (Wim); [email protected] > Cc: Les Ginsberg (ginsberg); Martin Horneffer; [email protected]; 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:[email protected]] On Behalf Of HENDERICKX, Wim > (Wim) > Sent: Monday, January 11, 2016 3:07 PM > To: [email protected] > Cc: Les Ginsberg (ginsberg); Martin Horneffer; [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]> > Date: Monday 11 January 2016 at 17:53 > To: Wim Henderickx <[email protected]> > Cc: Martin Horneffer <[email protected]>, "Les Ginsberg (ginsberg)" > <[email protected]>, "[email protected]" <[email protected]>, Stephane Litkowski > <[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]; 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]> > Date: Wednesday 6 January 2016 at 19:03 > To: Wim Henderickx <[email protected]> > Cc: Martin Horneffer <[email protected]>, "Les Ginsberg (ginsberg)" > <[email protected]>, "[email protected]" <[email protected]>, Stephane Litkowski > <[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]; 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]> on behalf of Martin Horneffer > <[email protected]> > Date: Tuesday 5 January 2016 at 13:05 > To: "Les Ginsberg (ginsberg)" <[email protected]>, "[email protected]" > <[email protected]>, Stephane Litkowski <[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). > 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]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. > _________________________________________________________________________________________________________________________ > > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
