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

[Peter Psenak <[e-mail]>]

Hi Les,

I'm fine with the latest proposal.

thanks,
Peter


On 1/14/16 21:52 , Les Ginsberg (ginsberg) wrote:
> 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:*[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] <mailto:[e-mail]>; Henderickx, Wim (Wim)
> *Subject:* RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB
> INCONSISTENCY
>
> Bruno -
>
> *From:*[e-mail] <mailto:[e-mail]>
> [mailto:[e-mail]]
> *Sent:* Wednesday, January 13, 2016 1:13 AM
> *To:* Les Ginsberg (ginsberg)
> *Cc:* [e-mail] <mailto:[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] <mailto:[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/nAoOL8tCF4qXHYK7c2dIu3Xd47AIn
> 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:*[e-mail] <mailto:[e-mail]>
> [mailto:[e-mail]]
> *Sent:* Tuesday, January 12, 2016 9:50 AM
> *To:* Les Ginsberg (ginsberg)
> *Cc:* [e-mail] <mailto:[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] <mailto:[e-mail]>; Henderickx, Wim (Wim)
> *Subject:* RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB
> INCONSISTENCY
>
> Bruno -
>
> *From:*[e-mail] <mailto:[e-mail]>
> [mailto:[e-mail]]
> *Sent:* Tuesday, January 12, 2016 3:51 AM
> *To:* Les Ginsberg (ginsberg)
> *Cc:* [e-mail] <mailto:[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]
> <mailto:[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] <mailto:[e-mail]>
> *Cc:* LITKOWSKI Stephane SCE/OINIS; Martin Horneffer; [e-mail]
> <mailto:[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]
> <mailto:[e-mail]>
> *Cc:* LITKOWSKI Stephane SCE/OINIS; Martin Horneffer; [e-mail]
> <mailto:[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]
> <mailto:[e-mail]>
> *Cc:* Les Ginsberg (ginsberg); Martin Horneffer; [e-mail]
> <mailto:[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] <mailto:[e-mail]>
> *Cc:* Les Ginsberg (ginsberg); Martin Horneffer; [e-mail]
> <mailto:[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]
> <mailto:[e-mail]>>
> *Date: *Monday 11 January 2016 at 17:53
> *To: *Wim Henderickx <[e-mail]
> <mailto:[e-mail]>>
> *Cc: *Martin Horneffer <[e-mail] <mailto:[e-mail]>>,
> "Les Ginsberg (ginsberg)" <[e-mail]
> <mailto:[e-mail]>>, "[e-mail] <mailto:[e-mail]>"
> <[e-mail] <mailto:[e-mail]>>, Stephane Litkowski
> <[e-mail] <mailto:[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:[e-mail]]
> *Sent:* Wednesday, January 06, 2016 8:19 PM
> *To:* DECRAENE Bruno IMT/OLN
> *Cc:* Martin Horneffer; Les Ginsberg (ginsberg); [e-mail]
> <mailto:[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]
> <mailto:[e-mail]>>
> *Date: *Wednesday 6 January 2016 at 19:03
> *To: *Wim Henderickx <[e-mail]
> <mailto:[e-mail]>>
> *Cc: *Martin Horneffer <[e-mail] <mailto:[e-mail]>>,
> "Les Ginsberg (ginsberg)" <[e-mail]
> <mailto:[e-mail]>>, "[e-mail] <mailto:[e-mail]>"
> <[e-mail] <mailto:[e-mail]>>, Stephane Litkowski
> <[e-mail] <mailto:[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]
> <mailto:[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]
> <mailto:[e-mail]>> on behalf of Martin Horneffer
> <[e-mail] <mailto:[e-mail]>>
> *Date: *Tuesday 5 January 2016 at 13:05
> *To: *"Les Ginsberg (ginsberg)" <[e-mail]
> <mailto:[e-mail]>>, "[e-mail] <mailto:[e-mail]>"
> <[e-mail] <mailto:[e-mail]>>, Stephane Litkowski
> <[e-mail] <mailto:[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
>     <https://www.ietf.org/proceedings/94/slides/slides-94-spring-2.pdf%20slide%20#3>).
>       It is also discussed in Bruno's post
>     (https://mailarchive.ietf.org/arch/attach/spring/txtk0n56G.txt - see
>     Section 2.2).
>
>     The basis of the alternative solution is that a correct
>     implementation should never allow inconsistent SRGB ranges to be
>     successfully configured (let alone advertised). So this is not a
>     case of a misconfiguration – it is a case of a defective
>     implementation. It  then seems appropriate to put the onus on the
>     originating router to only send valid SRGB advertisements rather
>     than forcing all the receivers to try to "correct" the invalid
>     information in some consistent way. This has a number of advantages:
>
>     1.It is by far the simplest to implement
>
>     2.It isolates the router which is untrustworthy
>
>     3.As the problem can only occur as a result of a defective
>     implementation the behavior of the originating router is
>     unpredictable – it is therefore safer not to use the information
>
>     It is worth noting that since the invalid advertisement is the
>     result of some sort of defect in the originating router’s
>     implementation, it is not safe to assume that the source will
>     actually be using the advertised SRGB in a manner consistent with
>     the selective choice made by the receiving routers.
>
>     I therefore propose that the above quoted text from
>     https://datatracker.ietf.org/doc/draft-ginsberg-spring-conflict-resolution/
>     be replaced with the following:
>
>     “The set of received ranges is examined . If there is overlap
>     between any two of the advertised ranges the entire SRGB set is
>     considered invalid and is ignored.
>
>     The originating router is considered to be incapable of supporting
>     the SR-MPLS forwarding plane. Routers which receive an SRGB
>     advertisement with overlapping ranges SHOULD report the occurrence.”
>
>     Comments?
>
>         Les
>
>     _______________________________________________
>
>     spring mailing list
>
>     [e-mail]  <mailto:[e-mail]>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.
>
>
>
> _______________________________________________
> spring mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spring
>