Re: [spring] draft-ginsberg-spring-conflict-resolution: SRGB INCONSISTENCY

["Les Ginsberg (ginsberg)" <[e-mail]>]

Stefano -

Thanx for the proposal - it makes sense to me. 

The handling of overlapping SRGB then reduces to following the procedures defined in the to be updated sr-mpls draft for the case where a SID cannot be mapped to the (set of) SRGB ranges advertised by the nexthop. This will make clear that the PHP case is unaffected by overlapping SRGB ranges.

Once a proposal for the revised sr-mpls draft is available I will propose new text for draft-ginsberg-spring-conflict-resolution. This should address the concerns raised by Bruno and Stephane.

   Les


> -----Original Message-----
> From: Stefano Previdi (sprevidi)
> Sent: Wednesday, January 20, 2016 5:52 AM
> To: Stephane Litkowski; Les Ginsberg (ginsberg)
> Cc: Uma Chunduri; [e-mail]; [e-mail];
> Henderickx, Wim (Wim)
> Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution: SRGB
> INCONSISTENCY
> 
> 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, [e-mail] 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:[e-mail]] On Behalf Of Les
> > Ginsberg (ginsberg)
> > Sent: Saturday, January 16, 2016 01:13
> > To: Uma Chunduri; DECRAENE Bruno IMT/OLN
> > Cc: [e-mail]; 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:[e-mail]]
> > Sent: Friday, January 15, 2016 3:56 PM
> > To: Les Ginsberg (ginsberg); [e-mail]
> > Cc: [e-mail]; Henderickx, Wim (Wim)
> > Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB
> > INCONSISTENCY
> >
> > Les,
> >
> > In-line [Uma]:
> >
> > --
> > Uma C.
> >
> > From: Les Ginsberg (ginsberg) [mailto:[e-mail]]
> > Sent: Friday, January 15, 2016 12:22 PM
> > To: Uma Chunduri; [e-mail]
> > Cc: [e-mail]; 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:[e-mail]]
> > Sent: Friday, January 15, 2016 10:13 AM
> > To: Les Ginsberg (ginsberg); [e-mail]
> > Cc: [e-mail]; 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:[e-mail]]
> > Sent: Thursday, January 14, 2016 5:28 PM
> > To: Uma Chunduri; [e-mail]
> > Cc: [e-mail]; Henderickx, Wim (Wim)
> > Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB
> > INCONSISTENCY
> >
> > Uma –
> >
> > Thanx for the response.
> > Inline.
> >
> > From: Uma Chunduri [mailto:[e-mail]]
> > Sent: Thursday, January 14, 2016 3:34 PM
> > To: Les Ginsberg (ginsberg); [e-mail]
> > Cc: [e-mail]; 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:[e-mail]] On Behalf Of Les
> > Ginsberg (ginsberg)
> > Sent: Thursday, January 14, 2016 12:53 PM
> > To: [e-mail]
> > Cc: [e-mail]; 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-routin
> > g-extensions/
> > https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-exten
> > sions/
> >
> > 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: [e-mail]
> [mailto:[e-mail]]
> > Sent: Thursday, January 14, 2016 12:30 AM
> > To: Les Ginsberg (ginsberg)
> > Cc: [e-mail]; Henderickx, Wim (Wim)
> > Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB
> > INCONSISTENCY
> >
> > Les,
> >
> > Please see inline [Bruno2]
> >
> > From: Les Ginsberg (ginsberg) [mailto:[e-mail]]
> > Sent: Thursday, January 14, 2016 12:49 AM
> > To: DECRAENE Bruno IMT/OLN
> > Cc: [e-mail]; Henderickx, Wim (Wim)
> > Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB
> > INCONSISTENCY
> >
> > Bruno -
> >
> > From: [e-mail]
> [mailto:[e-mail]]
> > Sent: Wednesday, January 13, 2016 1:13 AM
> > To: Les Ginsberg (ginsberg)
> > Cc: [e-mail]; 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:[e-mail]]
> > Sent: Tuesday, January 12, 2016 10:06 PM
> > To: DECRAENE Bruno IMT/OLN
> > Cc: [e-mail]; 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/nAoOL8tCF4qXHYK7c2dIu3Xd47
> A  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/FuMaSOnwO3WvtmMWT9SzV
> 8jbT
> > pE
> > - 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: [e-mail]
> [mailto:[e-mail]]
> > Sent: Tuesday, January 12, 2016 9:50 AM
> > To: Les Ginsberg (ginsberg)
> > Cc: [e-mail]; Henderickx, Wim (Wim)
> > Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB
> > INCONSISTENCY
> >
> > Les,
> >
> > Please see inline [Bruno2]
> >
> > From: Les Ginsberg (ginsberg) [mailto:[e-mail]]
> > Sent: Tuesday, January 12, 2016 4:38 PM
> > To: DECRAENE Bruno IMT/OLN
> > Cc: [e-mail]; Henderickx, Wim (Wim)
> > Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB
> > INCONSISTENCY
> >
> > Bruno -
> >
> > From: [e-mail]
> [mailto:[e-mail]]
> > Sent: Tuesday, January 12, 2016 3:51 AM
> > To: Les Ginsberg (ginsberg)
> > Cc: [e-mail]; 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:[e-mail]]
> > 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; [e-mail]
> > Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB
> > INCONSISTENCY
> >
> > Don -
> >
> > From: Fedyk, Don [mailto:[e-mail]]
> > Sent: Monday, January 11, 2016 3:06 PM
> > To: Les Ginsberg (ginsberg); HENDERICKX, Wim (Wim);
> > [e-mail]
> > Cc: LITKOWSKI Stephane SCE/OINIS; Martin Horneffer; [e-mail]
> > 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:[e-mail]] On Behalf Of Les
> > Ginsberg (ginsberg)
> > Sent: Monday, January 11, 2016 5:37 PM
> > To: Fedyk, Don; HENDERICKX, Wim (Wim); [e-mail]
> > Cc: LITKOWSKI Stephane SCE/OINIS; Martin Horneffer; [e-mail]
> > 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:[e-mail]]
> > Sent: Monday, January 11, 2016 1:41 PM
> > To: HENDERICKX, Wim (Wim); [e-mail]
> > Cc: Les Ginsberg (ginsberg); Martin Horneffer; [e-mail];
> > 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:[e-mail]] On Behalf Of HENDERICKX,
> > Wim (Wim)
> > Sent: Monday, January 11, 2016 3:07 PM
> > To: [e-mail]
> > Cc: Les Ginsberg (ginsberg); Martin Horneffer; [e-mail];
> > 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 <[e-mail]>
> > Date: Monday 11 January 2016 at 17:53
> > To: Wim Henderickx <[e-mail]>
> > Cc: Martin Horneffer <[e-mail]>, "Les Ginsberg (ginsberg)"
> > <[e-mail]>, "[e-mail]" <[e-mail]>, Stephane
> > Litkowski <[e-mail]>
> > 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.henderickx@alcatel-
> lucent.com]
> > Sent: Wednesday, January 06, 2016 8:19 PM
> > To: DECRAENE Bruno IMT/OLN
> > Cc: Martin Horneffer; Les Ginsberg (ginsberg); [e-mail];
> > 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 <[e-mail]>
> > Date: Wednesday 6 January 2016 at 19:03
> > To: Wim Henderickx <[e-mail]>
> > Cc: Martin Horneffer <[e-mail]>, "Les Ginsberg (ginsberg)"
> > <[e-mail]>, "[e-mail]" <[e-mail]>, Stephane
> > Litkowski <[e-mail]>
> > 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:[e-mail]] On Behalf Of Henderickx,
> > Wim (Wim)
> > Sent: Tuesday, January 05, 2016 7:41 PM
> > To: Martin Horneffer; Les Ginsberg (ginsberg); [e-mail];
> > 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 <[e-mail]> on behalf of Martin Horneffer
> > <[e-mail]>
> > Date: Tuesday 5 January 2016 at 13:05
> > To: "Les Ginsberg (ginsberg)" <[e-mail]>, "[e-mail]"
> > <[e-mail]>, Stephane Litkowski <[e-mail]>
> > 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
> > [e-mail]://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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/spring