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:*bruno.decra...@orange.com [mailto:bruno.decra...@orange.com]
*Sent:* Thursday, January 14, 2016 12:30 AM
*To:* Les Ginsberg (ginsberg)
*Cc:* spring@ietf.org; Henderickx, Wim (Wim)
*Subject:* RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB
INCONSISTENCY
Les,
Please see inline [Bruno2]
*From:*Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
*Sent:* Thursday, January 14, 2016 12:49 AM
*To:* DECRAENE Bruno IMT/OLN
*Cc:* spring@ietf.org <mailto:spring@ietf.org>; Henderickx, Wim (Wim)
*Subject:* RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB
INCONSISTENCY
Bruno -
*From:*bruno.decra...@orange.com <mailto:bruno.decra...@orange.com>
[mailto:bruno.decra...@orange.com]
*Sent:* Wednesday, January 13, 2016 1:13 AM
*To:* Les Ginsberg (ginsberg)
*Cc:* spring@ietf.org <mailto:spring@ietf.org>; 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:ginsb...@cisco.com]
*Sent:* Tuesday, January 12, 2016 10:06 PM
*To:* DECRAENE Bruno IMT/OLN
*Cc:* spring@ietf.org <mailto:spring@ietf.org>; 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:*bruno.decra...@orange.com <mailto:bruno.decra...@orange.com>
[mailto:bruno.decra...@orange.com]
*Sent:* Tuesday, January 12, 2016 9:50 AM
*To:* Les Ginsberg (ginsberg)
*Cc:* spring@ietf.org <mailto:spring@ietf.org>; Henderickx, Wim (Wim)
*Subject:* RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB
INCONSISTENCY
Les,
Please see inline [Bruno2]
*From:*Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
*Sent:* Tuesday, January 12, 2016 4:38 PM
*To:* DECRAENE Bruno IMT/OLN
*Cc:* spring@ietf.org <mailto:spring@ietf.org>; Henderickx, Wim (Wim)
*Subject:* RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB
INCONSISTENCY
Bruno -
*From:*bruno.decra...@orange.com <mailto:bruno.decra...@orange.com>
[mailto:bruno.decra...@orange.com]
*Sent:* Tuesday, January 12, 2016 3:51 AM
*To:* Les Ginsberg (ginsberg)
*Cc:* spring@ietf.org <mailto:spring@ietf.org>; 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:ginsb...@cisco.com]
*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; spring@ietf.org
<mailto:spring@ietf.org>
*Subject:* RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB
INCONSISTENCY
Don -
*From:*Fedyk, Don [mailto:don.fe...@hpe.com]
*Sent:* Monday, January 11, 2016 3:06 PM
*To:* Les Ginsberg (ginsberg); HENDERICKX, Wim (Wim);
bruno.decra...@orange.com <mailto:bruno.decra...@orange.com>
*Cc:* LITKOWSKI Stephane SCE/OINIS; Martin Horneffer; spring@ietf.org
<mailto:spring@ietf.org>
*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:spring-boun...@ietf.org] *On Behalf Of *Les
Ginsberg (ginsberg)
*Sent:* Monday, January 11, 2016 5:37 PM
*To:* Fedyk, Don; HENDERICKX, Wim (Wim); bruno.decra...@orange.com
<mailto:bruno.decra...@orange.com>
*Cc:* LITKOWSKI Stephane SCE/OINIS; Martin Horneffer; spring@ietf.org
<mailto:spring@ietf.org>
*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:don.fe...@hpe.com]
*Sent:* Monday, January 11, 2016 1:41 PM
*To:* HENDERICKX, Wim (Wim); bruno.decra...@orange.com
<mailto:bruno.decra...@orange.com>
*Cc:* Les Ginsberg (ginsberg); Martin Horneffer; spring@ietf.org
<mailto:spring@ietf.org>; 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:spring-boun...@ietf.org] *On Behalf Of
*HENDERICKX, Wim (Wim)
*Sent:* Monday, January 11, 2016 3:07 PM
*To:* bruno.decra...@orange.com <mailto:bruno.decra...@orange.com>
*Cc:* Les Ginsberg (ginsberg); Martin Horneffer; spring@ietf.org
<mailto:spring@ietf.org>; 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 <bruno.decra...@orange.com
<mailto:bruno.decra...@orange.com>>
*Date: *Monday 11 January 2016 at 17:53
*To: *Wim Henderickx <wim.henderi...@alcatel-lucent.com
<mailto:wim.henderi...@alcatel-lucent.com>>
*Cc: *Martin Horneffer <m...@nic.dtag.de <mailto:m...@nic.dtag.de>>,
"Les Ginsberg (ginsberg)" <ginsb...@cisco.com
<mailto:ginsb...@cisco.com>>, "spring@ietf.org <mailto:spring@ietf.org>"
<spring@ietf.org <mailto:spring@ietf.org>>, Stephane Litkowski
<stephane.litkow...@orange.com <mailto:stephane.litkow...@orange.com>>
*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.henderi...@alcatel-lucent.com]
*Sent:* Wednesday, January 06, 2016 8:19 PM
*To:* DECRAENE Bruno IMT/OLN
*Cc:* Martin Horneffer; Les Ginsberg (ginsberg); spring@ietf.org
<mailto:spring@ietf.org>; 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 <bruno.decra...@orange.com
<mailto:bruno.decra...@orange.com>>
*Date: *Wednesday 6 January 2016 at 19:03
*To: *Wim Henderickx <wim.henderi...@alcatel-lucent.com
<mailto:wim.henderi...@alcatel-lucent.com>>
*Cc: *Martin Horneffer <m...@nic.dtag.de <mailto:m...@nic.dtag.de>>,
"Les Ginsberg (ginsberg)" <ginsb...@cisco.com
<mailto:ginsb...@cisco.com>>, "spring@ietf.org <mailto:spring@ietf.org>"
<spring@ietf.org <mailto:spring@ietf.org>>, Stephane Litkowski
<stephane.litkow...@orange.com <mailto:stephane.litkow...@orange.com>>
*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:spring-boun...@ietf.org] *On Behalf Of
*Henderickx, Wim (Wim)
*Sent:* Tuesday, January 05, 2016 7:41 PM
*To:* Martin Horneffer; Les Ginsberg (ginsberg); spring@ietf.org
<mailto:spring@ietf.org>; 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 <spring-boun...@ietf.org
<mailto:spring-boun...@ietf.org>> on behalf of Martin Horneffer
<m...@nic.dtag.de <mailto:m...@nic.dtag.de>>
*Date: *Tuesday 5 January 2016 at 13:05
*To: *"Les Ginsberg (ginsberg)" <ginsb...@cisco.com
<mailto:ginsb...@cisco.com>>, "spring@ietf.org <mailto:spring@ietf.org>"
<spring@ietf.org <mailto:spring@ietf.org>>, Stephane Litkowski
<stephane.litkow...@orange.com <mailto:stephane.litkow...@orange.com>>
*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
spring@ietf.org
<mailto:spring@ietf.org>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
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
