Wim –
You are confused. ☺
SRGB is a local configuration for a box. There is no relationship between the
SRGB range(s) used on one node and those used on another node. This is why the
SIDs advertised in prefix reachability advertisements (or SRMS) are used as an
“index”. For example, consider the simple example below:
B
/ \
A D
\ /
C
Suppose Node D advertises reachability to 1.1.1.1/32 with SID = 1000.
On B SRGB is (20000, 21999)
On C SRGB is (21000, 22999)
On Node A:
when forwarding via B A will PUSH label 21000 (20000 + 1000)
when forwarding via C A will PUSH label 22000 (21000 + 1000)
The fact that there is overlap between the SRGBs of B and C is not an issue
because we push labels on a hop-by-hop basis based on the SID and the
advertised SRGB of our neighbor.
The issue we are discussing is what happens if a single Node advertises
overlapping ranges – for example:
B advertises: (20000, 21999) and (21000, 22999)
This forms an ordered set of ranges such that SIDs 0 – 1999 map to labels 20000
– 221999 and SIDs 2000 – 3999 map to labels 21000 – 22999. (See
https://www.ietf.org/id/draft-ietf-isis-segment-routing-extensions-06.txt
Section 3.1 for a more detailed example)
Now when forwarding to B a SID of 1000 maps to label 21000 – but a SID of 2000
also maps to label 21000. WE cannot map two different prefixes to the same
label in the forwarding plane so the behavior on Node B is unpredictable.
Hope this helps.
Les
From: HENDERICKX, Wim (Wim) [mailto:[email protected]]
Sent: Wednesday, January 13, 2016 9:26 PM
To: Les Ginsberg (ginsberg); Fedyk, Don; [email protected]
Cc: Martin Horneffer; [email protected]; LITKOWSKI Stephane SCE/OINIS
Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution: SRGB
INCONSISTENCY
Les, I agree you can check some errors when you configure something, but what
will you do if I have network A with SRGB-A and network B with SRGB B and you
connect them. If we can ensure that network A remain active with SRGB A and
SRGB remains active with SRGB B, than I can agree with the proposal since this
minimises the impact. Meaning the routers in network A should ignore all
advertisements from network B and vice versa, such that the services remain in
operation in each network.
From: "Les Ginsberg (ginsberg)" <[email protected]<mailto:[email protected]>>
Date: Tuesday 12 January 2016 at 21:42
To: Wim Henderickx
<[email protected]<mailto:[email protected]>>,
"Fedyk, Don" <[email protected]<mailto:[email protected]>>, Bruno Decraene
<[email protected]<mailto:[email protected]>>
Cc: Martin Horneffer <[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>, Stephane Litkowski
<[email protected]<mailto:[email protected]>>
Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB
INCONSISTENCY
Wim -
From: HENDERICKX, Wim (Wim) [mailto:[email protected]]
Sent: Tuesday, January 12, 2016 10:14 AM
To: Les Ginsberg (ginsberg); Fedyk, Don;
[email protected]<mailto:[email protected]>
Cc: Martin Horneffer; [email protected]<mailto:[email protected]>; LITKOWSKI
Stephane SCE/OINIS
Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution: SRGB
INCONSISTENCY
Les, typically errors in SRGB conflict come from both bugs and human errors. We
should look at all of this to get the best solution. This is why I want to put
these things on the table to discuss all potential scenario’s to agree on the
best solution.
[Les:] As regards SRLG config human error does not enter the equation (unless
you consider programmers who introduce bugs in the implementation as humans. ☺
).
The stated requirement is that overlapping ranges MUST NOT be advertised. This
is easy to check when the local configuration is entered and any overlapping
config is rejected. Until the human configures a valid set of SRGB ranges the
SRGB is NOT advertised and the local node does not declare itself SR-MPLS
capable. There is never a valid reason for a node to advertise overlapping SRGB
ranges as validation of the config is a local matter unaffected by what other
nodes may have done.
Les
From: "Les Ginsberg (ginsberg)" <[email protected]<mailto:[email protected]>>
Date: Tuesday 12 January 2016 at 16:22
To: Wim Henderickx
<[email protected]<mailto:[email protected]>>,
"Fedyk, Don" <[email protected]<mailto:[email protected]>>, Bruno Decraene
<[email protected]<mailto:[email protected]>>
Cc: Martin Horneffer <[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>, Stephane Litkowski
<[email protected]<mailto:[email protected]>>
Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB
INCONSISTENCY
Wim -
From: HENDERICKX, Wim (Wim) [mailto:[email protected]]
Sent: Tuesday, January 12, 2016 1:02 AM
To: Les Ginsberg (ginsberg); Fedyk, Don;
[email protected]<mailto:[email protected]>
Cc: Martin Horneffer; [email protected]<mailto:[email protected]>; LITKOWSKI
Stephane SCE/OINIS
Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution: SRGB
INCONSISTENCY
Les, in your scenario you assume 2 issues on the node.
[Les:] Actually I am trying not to make any assumptions. What we know is that
the router has advertised an invalid SRGB. This can only be because of a bug.
At this point I am saying I do not know what the nature of the bug is and I
cannot predict with any reliability what other impacts it will have.
Any of the options you consider below depend upon an assumption that the node
which has advertised an invalid SRGB will behave in a certain way – which is
something you cannot know. And any of the choices you make could actually make
the problem worse by introducing loops or forwarding traffic to the wrong
destination. The network is compromised because you have a faulty node. Let’s
not risk making it worse by trying to be clairvoyant.
Les
First it advertises an inconsistent SRGB and 2nd it behaves wrong in the
data-plane. My view is that the reason for agreeing on a consistent behaviour
ensures constructing a SRGB out of the info received to minimise traffic impact.
If the control plane and data-plane is faulty on a node, there is little to do,
other than fixing the faulty SW.
We need to think in which circumstances this will happen and what the result
would be: I am trying to list different option to determine what the best
strategy is for achieving this by thinking what can happen:
* Adding a new node which got wrongly configured or a startup scenario:
option 1 and option 2 can work to minimise network impact
* Merging networks which were both in operation: I believe option 2 is
better for minimising network impact, since you try to make something work
* Faulty SW: neither option is helping
* Other?
I am not biased on one option vs another, trying to analyse the different
behaviours/strategies.
From: "Les Ginsberg (ginsberg)" <[email protected]<mailto:[email protected]>>
Date: Tuesday 12 January 2016 at 06:28
To: Wim Henderickx
<[email protected]<mailto:[email protected]>>,
"Fedyk, Don" <[email protected]<mailto:[email protected]>>, Bruno Decraene
<[email protected]<mailto:[email protected]>>
Cc: Martin Horneffer <[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>, Stephane Litkowski
<[email protected]<mailto:[email protected]>>
Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB
INCONSISTENCY
Wim –
Please explain to me how the receivers – who you are proposing to make one of
the choices below – know what the node which advertised the overlapping ranges
is actually doing when it installs local labels in its forwarding plane?
For example, suppose in the example below the receivers choose to ignore the
second label range [1099, 2099].
So the neighbor of the faulty node pushes label 5000 for the prefix which has
SID 100. What happens when the packet arrives at the problematic node?
A)If “faulty node” is using the overlapping range, then label 5000 will be
associated with the prefix with SID 1100 – and the packet will be forwarded out
some interface using the label that “faulty node’s neighbor” has associated
with SID 1100.
B)If “faulty node” is NOT using anything but the first range, then label 5000
isn’t an SR assigned label. The packet might get dropped – or it might get
forwarded using an LDP label (for example) if LDP happens to be using label
5000.
C)Maybe “faulty node” has an inconsistency between what it advertised and what
it is actually using. It meant to advertise:
[1000, 1099]
[2000, 2099]
[5000, 6099]
but the second entry got corrupted during formatting.
Now label 5000 is associated with the prefix having SID 200 – and we have
similar behavior to “A” above.
The list of possibilities goes on and on – and yes – one of the possibilities
is that you “get lucky” and faulty node happens to be doing what you hoped it
might and forwarding “works”. But there is no way for you to know what faulty
node is actually doing. So all this speculation about which choice might result
in the “best behavior” is like playing the lottery.
Why would we want to do this? I certainly do not.
Les
From: HENDERICKX, Wim (Wim) [mailto:[email protected]]
Sent: Monday, January 11, 2016 8:18 PM
To: Fedyk, Don; [email protected]<mailto:[email protected]>
Cc: Les Ginsberg (ginsberg); Martin Horneffer;
[email protected]<mailto:[email protected]>; LITKOWSKI Stephane SCE/OINIS
Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution: SRGB
INCONSISTENCY
Don, I get that but the key question is if the looser that is picked is the one
who creates the biggest network impact or not. This is what I mean with right
or wrong.
I just want to have a discussion on both options and agree on the best strategy
to minimise the impact in a network when this would happen.
Option 2 is basically something along this line and was suggested before afaik.
A)
[1000, 1099] => overlap with second
[1099, 2099] => overlap with first
[5000, 6099]
ð Ignore label range [1099, 2099],
sid index 100 will be translated to label 5000.
sid index > 200 will not be translated + information logged
B)
[1000, 1099] => overlap with second
[1099, 2099] => overlap with first & last
[2099, 3099] => overlap with second
ð Ignore label range [1099, 2099] & [2099, 3099],
sid index 0 will be translated to label 1000.
sid index > 100 can not be translated + information logged
C)
[1000, 1099] => overlap with last
[2000, 2099]
[900, 1000] => overlap with first
ð Ignore label range [900, 1000]
sid index 0 will be translated to label 1000.
sid index > 200 can not be translated + information logged
From: "Fedyk, Don" <[email protected]<mailto:[email protected]>>
Date: Monday 11 January 2016 at 22:41
To: Wim Henderickx
<[email protected]<mailto:[email protected]>>,
Bruno Decraene <[email protected]<mailto:[email protected]>>
Cc: "Les Ginsberg (ginsberg)" <[email protected]<mailto:[email protected]>>,
Martin Horneffer <[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>, Stephane Litkowski
<[email protected]<mailto:[email protected]>>
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 ☺ ).
Cheers,
Don
From: spring [mailto:[email protected]] On Behalf Of HENDERICKX, Wim (Wim)
Sent: Monday, January 11, 2016 3:07 PM
To: [email protected]<mailto:[email protected]>
Cc: Les Ginsberg (ginsberg); Martin Horneffer;
[email protected]<mailto:[email protected]>; LITKOWSKI Stephane SCE/OINIS
Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution: SRGB
INCONSISTENCY
I believe we agree to minimise the network impact when SRGB data is
inconsistent.
Option 1 is we ignore a advertisements of some nodes. The main issue I see with
this is determining who is right/wrong. Implementation is rather easy, but you
will impact traffic from certain nodes in some case as outlined below.
Option 2 is you try to disseminate something out of the information and try to
determine a consistent behaviour across all node. Implementation is more
difficult, but I believe there is more coverage/chances to meet the overall
objective.
My 2 cents.
From: Bruno Decraene
<[email protected]<mailto:[email protected]>>
Date: Monday 11 January 2016 at 17:53
To: Wim Henderickx
<[email protected]<mailto:[email protected]>>
Cc: Martin Horneffer <[email protected]<mailto:[email protected]>>, "Les Ginsberg
(ginsberg)" <[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>, Stephane Litkowski
<[email protected]<mailto:[email protected]>>
Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB
INCONSISTENCY
Hi Wim,
I read that you are pointing out the difficulty to identify the inconsistency.
If so, this point is common to all options being discussed.
I may be missing some of your points. This thread is about inconsistency in the
SRGB ranges advertised by _one_ node. I’m not sure to see your “startup
scenario” nor the “merge network scenario”. Could you please elaborate?
Thanks,
Bruno
From: Henderickx, Wim (Wim) [mailto:[email protected]]
Sent: Wednesday, January 06, 2016 8:19 PM
To: DECRAENE Bruno IMT/OLN
Cc: Martin Horneffer; Les Ginsberg (ginsberg);
[email protected]<mailto:[email protected]>; LITKOWSKI Stephane SCE/OINIS
Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution: SRGB
INCONSISTENCY
If you avoid an inconsistency in an SRGB announcement there is multiple
scenario’s in which you determine who is right/wrong:
* Assume you are in a startup scenario, it is very hard to determine who is
consistent and who is not
* If you are in a running network and you add a new node or have a
different config on 1 node, you can determine it
* If you merge a network and the config is wrong in one part but not in the
other part of the network.
I see this strategy work in some case but in others I see challenges to
determine what is right and what is wrong, hence my question
From: Bruno Decraene
<[email protected]<mailto:[email protected]>>
Date: Wednesday 6 January 2016 at 19:03
To: Wim Henderickx
<[email protected]<mailto:[email protected]>>
Cc: Martin Horneffer <[email protected]<mailto:[email protected]>>, "Les Ginsberg
(ginsberg)" <[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>, Stephane Litkowski
<[email protected]<mailto:[email protected]>>
Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB
INCONSISTENCY
Hi Wim,
Many thanks for taking part in the discussion.
Could you please elaborate? e.g. what do you mean by ”who” and “wrong” on what?
I could see multiple interpretations, but it would probably be faster if you
elaborate by yourself.
Thanks
-- Bruno
From:spring [mailto:[email protected]] On Behalf Of Henderickx, Wim (Wim)
Sent: Tuesday, January 05, 2016 7:41 PM
To: Martin Horneffer; Les Ginsberg (ginsberg);
[email protected]<mailto:[email protected]>; LITKOWSKI Stephane SCE/OINIS
Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution: SRGB
INCONSISTENCY
My main question on the proposal is how do we tell who is right and who is
wrong?
From: spring <[email protected]<mailto:[email protected]>> on
behalf of Martin Horneffer <[email protected]<mailto:[email protected]>>
Date: Tuesday 5 January 2016 at 13:05
To: "Les Ginsberg (ginsberg)" <[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>, Stephane Litkowski
<[email protected]<mailto:[email protected]>>
Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution: SRGB
INCONSISTENCY
Hello Les, Acee, Stephane, everyone,
happy new year!
From an operator's (carrier's) point of view I clearly and strongly support
this alternative solution: Treat an inconsistent set of SRGB announcements as
broken and ignore it.
- It is the simplest solution.
- It only affects traffic of the badly configured and implemented router.
- It gives a clear indication to the operator where they have to repair
something.
With respect to Stephane's comments:
- I would also support a repetition or clarification that an inconsistent set
of SRGB annoucements is broken.
- No strong opinion from my side as how to define the offending node as
non-SR-capable as I don't see any use case for nodes with only adjacency SIDs.
Best regards,
Martin
Am 04.01.16 um 06:55 schrieb Les Ginsberg (ginsberg):
One of the topics discussed in
https://datatracker.ietf.org/doc/draft-ginsberg-spring-conflict-resolution/ is
how to handle inconsistent SRGB advertisements from a given node.
The draft defines one possible solution -from Section 2:
" Each range is examined in the order it was advertised. If it does
not overlap with any advertised range which preceded it the
advertised range is used. If the range overlaps with any preceding
range it MUST NOT be used and all ranges advertised after the first
encountered overlapping range also MUST NOT be used."
This is one instance of a class of solutions which attempt to make use of part
of the advertisements even when there is some inconsistency (overlap) in the
set of SRGB ranges received. A more complete discussion of this class of
solutions can be seen in
https://mailarchive.ietf.org/arch/attach/spring/txtk0n56G.txt - many thanx to
Bruno for writing this.
However, there is an alternative solution which was suggested (notably by Acee
Lindem) after the draft was written. This alternative is to ignore the entire
set of SRGB advertisements and treat the problematic router as if it were not
SR MPLS capable. This alternative was discussed during the presentation in
SPRING WG at IETF94 (see
https://www.ietf.org/proceedings/94/slides/slides-94-spring-2.pdf slide
#3<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
[email protected]<mailto:[email protected]>https://www.ietf.org/mailman/listinfo/spring
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
