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

[Stefano Previdi (sprevidi)]

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, stephane.litkow...@orange.com 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:spring-boun...@ietf.org] On Behalf Of Les Ginsberg 
> (ginsberg)
> Sent: Saturday, January 16, 2016 01:13
> To: Uma Chunduri; DECRAENE Bruno IMT/OLN
> Cc: spring@ietf.org; 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:uma.chund...@ericsson.com] 
> Sent: Friday, January 15, 2016 3:56 PM
> To: Les Ginsberg (ginsberg); bruno.decra...@orange.com
> Cc: spring@ietf.org; Henderickx, Wim (Wim)
> Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB 
> INCONSISTENCY
>  
> Les,
>  
> In-line [Uma]:
>  
> --
> Uma C.
>  
> From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] 
> Sent: Friday, January 15, 2016 12:22 PM
> To: Uma Chunduri; bruno.decra...@orange.com
> Cc: spring@ietf.org; 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:uma.chund...@ericsson.com] 
> Sent: Friday, January 15, 2016 10:13 AM
> To: Les Ginsberg (ginsberg); bruno.decra...@orange.com
> Cc: spring@ietf.org; 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:ginsb...@cisco.com] 
> Sent: Thursday, January 14, 2016 5:28 PM
> To: Uma Chunduri; bruno.decra...@orange.com
> Cc: spring@ietf.org; Henderickx, Wim (Wim)
> Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB 
> INCONSISTENCY
>  
> Uma –
>  
> Thanx for the response.
> Inline.
>  
> From: Uma Chunduri [mailto:uma.chund...@ericsson.com] 
> Sent: Thursday, January 14, 2016 3:34 PM
> To: Les Ginsberg (ginsberg); bruno.decra...@orange.com
> Cc: spring@ietf.org; Henderickx, Wim (Wim)
> Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB 
> INCONSISTENCY
>  
> Dear Les, Bruno, 
>  
> Thanks for a great discussion on this st

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

[Mach Chen]

It’s a very clear statement and reasonable. I support this.

Best regards,
Mach

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Les Ginsberg 
(ginsberg)
Sent: Wednesday, January 13, 2016 5:06 AM
To: bruno.decra...@orange.com
Cc: 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.

2)Receivers of an invalid SRGB MUST ignore the SRGB and treat the sending node 
as NOT SR-MPLS capable.

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.

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”.

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.

   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, 209

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

[Les Ginsberg (ginsberg)]

Bruno -

From: 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; 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:


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.



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.

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: [spri

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

[Stefano Previdi (sprevidi)]

Les,


it seems I missed most of the party… bad luck ;-)

I fully agree with your approach and it looks we getting very close to “rough 
consensus” here.

s.


> On Jan 12, 2016, at 10:06 PM, Les Ginsberg (ginsberg) <ginsb...@cisco.com> 
> wrote:
> 
> 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.
>  
> 2)Receivers of an invalid SRGB MUST ignore the SRGB and treat the sending 
> node as NOT SR-MPLS capable.
>  
> 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.
>  
> 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”.
>  
> 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.
>  
>Les
>  
>  
> From: 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; 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; Henderickx, Wim (Wim)
> Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB 
> INCONSISTENCY
>  
> Bruno -
>  
> From: 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; 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
> 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
> Cc: LITKOWSKI Stephane SCE/OINIS; Martin Horneffer; 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 – t

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

[HENDERICKX, Wim (Wim)]

Les, in your scenario you assume 2 issues on the node. 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)" <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>
Date: Tuesday 12 January 2016 at 06:28
To: Wim Henderickx 
<wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>>, 
"Fedyk, Don" <don.fe...@hpe.com<mailto:don.fe...@hpe.com>>, Bruno Decraene 
<bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>>
Cc: Martin Horneffer <m...@nic.dtag.de<mailto:m...@nic.dtag.de>>, 
"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

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:wim.henderi...@alcatel-lucent.com]
Sent: Monday, January 11, 2016 8:18 PM
To: Fedyk, Don; 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

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] => ov

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

[bruno.decraene]

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
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.
Drop the conflicting one, Merge, Merge and re-order _do_ require a new behavior 
on the advertising node, consistent with all others nodes.

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 i

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

[Jeff Tantsura]

Pragmatic and working approach, I support it.

Cheers,
Jeff

From: spring <spring-boun...@ietf.org<mailto:spring-boun...@ietf.org>> on 
behalf of "Les Ginsberg (ginsberg)" 
<ginsb...@cisco.com<mailto:ginsb...@cisco.com>>
Date: Tuesday, January 12, 2016 at 13:06
To: "bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>" 
<bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>>
Cc: "spring@ietf.org<mailto:spring@ietf.org>" 
<spring@ietf.org<mailto:spring@ietf.org>>, Wim Henderickx 
<wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>>
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.

2)Receivers of an invalid SRGB MUST ignore the SRGB and treat the sending node 
as NOT SR-MPLS capable.

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.

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”.

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.

   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 

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

[Les Ginsberg (ginsberg)]

Wim -

From: HENDERICKX, Wim (Wim) [mailto:wim.henderi...@alcatel-lucent.com]
Sent: Tuesday, January 12, 2016 10:14 AM
To: Les Ginsberg (ginsberg); Fedyk, Don; bruno.decra...@orange.com
Cc: Martin Horneffer; spring@ietf.org; 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)" <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>
Date: Tuesday 12 January 2016 at 16:22
To: Wim Henderickx 
<wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>>, 
"Fedyk, Don" <don.fe...@hpe.com<mailto:don.fe...@hpe.com>>, Bruno Decraene 
<bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>>
Cc: Martin Horneffer <m...@nic.dtag.de<mailto:m...@nic.dtag.de>>, 
"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

Wim -

From: HENDERICKX, Wim (Wim) [mailto:wim.henderi...@alcatel-lucent.com]
Sent: Tuesday, January 12, 2016 1:02 AM
To: Les Ginsberg (ginsberg); Fedyk, Don; 
bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>
Cc: Martin Horneffer; spring@ietf.org<mailto:spring@ietf.org>; 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)" <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>
Date: Tuesday 12 January 2016 at 06:28
To: Wim Henderickx 
<wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>>, 
"Fedyk, Don" <don.fe...@hpe.com<mailto:don.fe...@hpe.com>>, Bruno Decraene 
<bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>>
Cc: Martin Horneffer <m...@nic.dtag.de<mailto:m...@nic.dtag.de>>, 
"spring@ietf.org<mailto:spring@ietf.org>" 
<spring@ietf.org<mailto:spring@ietf.org>>, Stephane Litkowski 
<stephane.litkow...@orange.com<mailto:stephane.litko

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

[Les Ginsberg (ginsberg)]

Wim -

From: HENDERICKX, Wim (Wim) [mailto:wim.henderi...@alcatel-lucent.com]
Sent: Tuesday, January 12, 2016 1:02 AM
To: Les Ginsberg (ginsberg); Fedyk, Don; bruno.decra...@orange.com
Cc: Martin Horneffer; spring@ietf.org; 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)" <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>
Date: Tuesday 12 January 2016 at 06:28
To: Wim Henderickx 
<wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>>, 
"Fedyk, Don" <don.fe...@hpe.com<mailto:don.fe...@hpe.com>>, Bruno Decraene 
<bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>>
Cc: Martin Horneffer <m...@nic.dtag.de<mailto:m...@nic.dtag.de>>, 
"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

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:wim.henderi...@alcatel-lucent.com]
Sent: Monday, January 11, 2016 8:18 PM
To: Fedyk, Don; bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>
Cc: Les Ginsberg (ginsberg); Martin Horneffer; 
spring@ietf.org<mailto:spring@

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

[Les Ginsberg (ginsberg)]

Bruno -

From: 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; 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.

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 mi

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

[Les Ginsberg (ginsberg)]

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
Cc: Les Ginsberg (ginsberg); Martin Horneffer; 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 ☺ ).

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: B

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

[Les Ginsberg (ginsberg)]

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:wim.henderi...@alcatel-lucent.com]
Sent: Monday, January 11, 2016 8:18 PM
To: Fedyk, Don; bruno.decra...@orange.com
Cc: Les Ginsberg (ginsberg); Martin Horneffer; spring@ietf.org; 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" <don.fe...@hpe.com<mailto:don.fe...@hpe.com>>
Date: Monday 11 January 2016 at 22:41
To: Wim Henderickx 
<wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>>, 
Bruno Decraene <bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>>
Cc: "Les Ginsberg (ginsberg)" <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>, 
Martin Horneffer <m...@nic.dtag.de<mailto:m...@nic.dtag.de>>, 
"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

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 configura

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

[HENDERICKX, Wim (Wim)]

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 give

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

[bruno.decraene]

Les,



[SLI] I'm was not suggesting to use only Adj-SID ... as I also do not see a 
real use case for that. I'm just saying that the specification does not prevent 
it. So may be let's prevent it ...so we can update the architecture document 
saying that advertising a valid SRGB is a must. There is something wrong to me 
here, because we will state that a node with invalid SRGB will be treated as 
non SR capable while the architecture does not forbid to not have a SRGB and 
does not say anything on how the architecture works with no SRGB (we can only 
guess that only Adj-SID can be used).


[Les2:] OK good - I think we agree on this point also. What is needed is to 
ensure that there is appropriate language in the SR architecture draft and/or 
the protocol drafts to specify how receiving an invalid SRGB affects the 
interpretation of "SR-MPLS capability".

As of today, the SR architecture has passed WG Last Call and his pending 
shepherd write up. Are you saying that there is a need to introduce technical 
change in the SR architecture?
[Les2:] I will take an action item to follow up on that with the various draft 
authors.

Before introducing such technical change in the document, draft authors would 
need to discuss them in the WG. Thanks.


-- Bruno


From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Tuesday, January 05, 2016 9:30 PM
To: LITKOWSKI Stephane SCE/OINIS; DECRAENE Bruno IMT/OLN; spring@ietf.org
Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB 
INCONSISTENCY

Stephane -

From: stephane.litkow...@orange.com<mailto:stephane.litkow...@orange.com> 
[mailto:stephane.litkow...@orange.com]
Sent: Tuesday, January 05, 2016 12:45 AM
To: Les Ginsberg (ginsberg); DECRAENE Bruno IMT/OLN; 
spring@ietf.org<mailto:spring@ietf.org>
Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB 
INCONSISTENCY

Hi Les,

Pls find more inline.


From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Tuesday, January 05, 2016 00:34
To: LITKOWSKI Stephane SCE/OINIS; DECRAENE Bruno IMT/OLN; 
spring@ietf.org<mailto:spring@ietf.org>
Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB 
INCONSISTENCY

Stephane -

From: stephane.litkow...@orange.com<mailto:stephane.litkow...@orange.com> 
[mailto:stephane.litkow...@orange.com]
Sent: Monday, January 04, 2016 12:55 AM
To: Les Ginsberg (ginsberg); DECRAENE Bruno IMT/OLN; 
spring@ietf.org<mailto:spring@ietf.org>
Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB 
INCONSISTENCY

Hi Les,

Happy new year.
[Les:] And to you...

I agree with your proposal.
The text must state that  there must be a local configuration mechanism that 
avoids sender to originate overlapping SRGB.

[Les:] Hmmm...IS-IS draft (for example) already states (Section 3.1):


The originating router MUST NOT advertise overlapping ranges.

   When a router receives multiple overlapping ranges, it MUST conform
   to the procedures defined in   [I-D.ginsberg-spring-conflict-resolution].


Isn't this sufficient?

[SLI] I missed this, thanks. Anyway from a readability point of view, it would 
be good to recall that the protocol documents address the sender side. Do we 
have the same for BGP ?
The issue with putting this text in the protocol doc, is that you need to 
ensure that all protocols will always have this restriction. It's not really a 
protocol thing, more a configuration management one ...

[Les2:] If your concern is to make sure that all the protocol documents provide 
equivalent language - I agree this should be done and we will do the diligence 
necessary to make sure that text is included in all the places needed. My 
comment was that adding such a statement in this specification is really out of 
place. The right place to state the requirement is in the sender specification. 
I think we agree on this.

In this case, as you mention, if a router receives overlapping SRGB, this is a 
bad behavior and we cannot guess if the forwarding plane is correctly 
programmed or not on the originator, so it is better to avoid it.

Now regarding the sentence :" The originating router is considered to be 
incapable of supporting the SR-MPLS forwarding plane". Do we have something in 
the architecture document saying that advertising a SRGB is mandatory to use SR 
? Pure theorical example : what if someone wants only to use Adj-SIDs in SR 
network ? there is no need to advertise a SRGB. Stating that the node must be 
considered as non SR capable is strong, it will also prevent the usage of 
Adj-SID which will work well without SRGB. If we consider that having a SRGB is 
mandatory, we need to have this requirement in the architecture document.

[Les:] An interesting point. What I am after here is recognition that without a 
valid SRGB the indication from a node that it is capable of "processing SR MPLS 
encapsulated IPv4/IPv6 packets on all interfaces" does no

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

[bruno.decraene]

Hi Les,

Thanks for initiating the thread on SRGB inconsistency.
Please see some comments inlined [Bruno]

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Monday, January 04, 2016 6:55 AM
To: DECRAENE Bruno IMT/OLN; spring@ietf.org
Subject: draft-ginsberg-spring-conflict-resolution: SRGB INCONSISTENCY


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).



[Bruno] This seems like a valid option. I would not seem many difference 
compared to the "Drop All" options which drops all the SRGB ranges. The main 
difference would probably be the consequences on the local segments (e.g. 
adjacency segments) which would be dropped with this proposal and kept with the 
"Drop all option"



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.

[Bruno] Agreed.

However bug happens, hence we need to consider this case and define the 
behavior. Hence the discussion on what is the behavior we are looking for.



It  then seems appropriate to put the onus on the originating router

[Bruno] We can clearly blame the originating router, and as a network operator, 
I will certainly. But that does not change the fact that an incorrect 
advertisement has been send.

to only send valid SRGB advertisements rather than forcing all the receivers to 
try to "correct" the invalid information in some consistent way.

[Bruno] The wrong advertisement has been sent and we need receivers to detect 
the error and react on it in a consistent manner.

We are mostly not trying to "correct" anything. We are discussion what to be 
dropped and what to be kept, and the limit is not so easy to make.





This has a number of advantages:



1.   It is by far the simplest to implement

[Bruno] It's not clear to me why this option would be significantly simpler to 
implement than the "Drop all" or "Drop from the conflict" option. Since this 
seems obvious for you ("by far"), could you please help me/us understand why 
and how much simpler.

2.   It isolates the router which is untrustworthy

[Bruno] So does "Drop all", so does dropping all its IGP adjacency given that 
this router is "untrustworthy", since this would really isolate the router.

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

[Bruno] That would be an argument to drop all IGP adjacency rather than just 
considering that SR does not work.

What I'm trying to say, is that we'll probably all agree on dropping the 
conflicting/wrong advertisements. If you want to go beyond and drop valid 
advertisements, it's difficult to draw the limit between valid advertisement 
that you/one would considered potentially untrustworthy and valid  
advertisement that you/one would considered trustworthy. If we had that we are 
not "one" but many, this may explain why this gets difficult to find an 
agreement.



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.

[Bruno] Agreed for the invalid info. For 

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

[bruno.decraene]

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; 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 ther

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

[Les Ginsberg (ginsberg)]

Bruno (AKA Mr. co-chair :)) -

Please do not worry. IETF process will be followed whatever the changes may be.

At the moment I have not decided whether to recommend changes to the 
architecture doc - or the protocol docs - or both. I will likely consult w the 
authors of those drafts first to see what seems to make sense. Then the 
proposed changes will - as always - be presented to the WG.

   Les


From: bruno.decra...@orange.com [mailto:bruno.decra...@orange.com]
Sent: Wednesday, January 06, 2016 10:05 AM
To: Les Ginsberg (ginsberg); LITKOWSKI Stephane SCE/OINIS
Cc: spring@ietf.org
Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB 
INCONSISTENCY

Les,



[SLI] I'm was not suggesting to use only Adj-SID ... as I also do not see a 
real use case for that. I'm just saying that the specification does not prevent 
it. So may be let's prevent it ...so we can update the architecture document 
saying that advertising a valid SRGB is a must. There is something wrong to me 
here, because we will state that a node with invalid SRGB will be treated as 
non SR capable while the architecture does not forbid to not have a SRGB and 
does not say anything on how the architecture works with no SRGB (we can only 
guess that only Adj-SID can be used).


[Les2:] OK good - I think we agree on this point also. What is needed is to 
ensure that there is appropriate language in the SR architecture draft and/or 
the protocol drafts to specify how receiving an invalid SRGB affects the 
interpretation of "SR-MPLS capability".

As of today, the SR architecture has passed WG Last Call and his pending 
shepherd write up. Are you saying that there is a need to introduce technical 
change in the SR architecture?

[Les2:] I will take an action item to follow up on that with the various draft 
authors.

Before introducing such technical change in the document, draft authors would 
need to discuss them in the WG. Thanks.



-- Bruno


From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Tuesday, January 05, 2016 9:30 PM
To: LITKOWSKI Stephane SCE/OINIS; DECRAENE Bruno IMT/OLN; 
spring@ietf.org<mailto:spring@ietf.org>
Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB 
INCONSISTENCY

Stephane -

From: stephane.litkow...@orange.com<mailto:stephane.litkow...@orange.com> 
[mailto:stephane.litkow...@orange.com]
Sent: Tuesday, January 05, 2016 12:45 AM
To: Les Ginsberg (ginsberg); DECRAENE Bruno IMT/OLN; 
spring@ietf.org<mailto:spring@ietf.org>
Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB 
INCONSISTENCY

Hi Les,

Pls find more inline.


From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Tuesday, January 05, 2016 00:34
To: LITKOWSKI Stephane SCE/OINIS; DECRAENE Bruno IMT/OLN; 
spring@ietf.org<mailto:spring@ietf.org>
Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB 
INCONSISTENCY

Stephane -

From: stephane.litkow...@orange.com<mailto:stephane.litkow...@orange.com> 
[mailto:stephane.litkow...@orange.com]
Sent: Monday, January 04, 2016 12:55 AM
To: Les Ginsberg (ginsberg); DECRAENE Bruno IMT/OLN; 
spring@ietf.org<mailto:spring@ietf.org>
Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB 
INCONSISTENCY

Hi Les,

Happy new year.
[Les:] And to you...

I agree with your proposal.
The text must state that  there must be a local configuration mechanism that 
avoids sender to originate overlapping SRGB.

[Les:] Hmmm...IS-IS draft (for example) already states (Section 3.1):


The originating router MUST NOT advertise overlapping ranges.

   When a router receives multiple overlapping ranges, it MUST conform
   to the procedures defined in   [I-D.ginsberg-spring-conflict-resolution].


Isn't this sufficient?

[SLI] I missed this, thanks. Anyway from a readability point of view, it would 
be good to recall that the protocol documents address the sender side. Do we 
have the same for BGP ?
The issue with putting this text in the protocol doc, is that you need to 
ensure that all protocols will always have this restriction. It's not really a 
protocol thing, more a configuration management one ...

[Les2:] If your concern is to make sure that all the protocol documents provide 
equivalent language - I agree this should be done and we will do the diligence 
necessary to make sure that text is included in all the places needed. My 
comment was that adding such a statement in this specification is really out of 
place. The right place to state the requirement is in the sender specification. 
I think we agree on this.

In this case, as you mention, if a router receives overlapping SRGB, this is a 
bad behavior and we cannot guess if the forwarding plane is correctly 
programmed or not on the originator, so it is better to avoid it.

Now regarding the sentence :" The originating router is considered to be 
incapable of supporting the SR-MPLS forwarding plane". Do we have somethi

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

[Les Ginsberg (ginsberg)]

Bruno –

I know I have not yet responded to all the points in your multiple posts on 
this thread – but I am starting to reply to this email because I am hoping 
(perhaps foolishly ☺) that there is a way forward that allows us not to get 
immersed in many side discussions.

There is an overall principle that I am hoping we can apply. For a node to 
advertise that it is SR-MPLS(IPv4 and/or IPv6) capable it must:

1)Indicate that it support SR-MPLS for one or both address-families
2)It must send a valid SRGB set

The text I have proposed states that if the node does not do the above two 
things then it has not met the criteria and is therefore considered to be NOT 
SR-MPLS capable. While it is very diligent of you to list all of the possible 
ways in which we could try to make use of information which does not meet the 
above criteria (Drop all, Drop from conflict, Drop the conflicting one, Merge, 
Merge and reorder) I prefer to simplify the solution by specifying that 
receivers MUST consider the node to be SR incapable until it provides valid SR 
capability information. What benefits accrue from this simplified approach?

1)All receivers have consistent behavior
2)We NEVER risk forwarding a packet with a label which will be misinterpreted
3)We do not require protocol vendors and operators to invest development/test 
time in making use of invalid information in a manner which is interoperable 
with other vendors

The last point – I think – is part of what Wim is trying to emphasize. If you 
try to be “smart” and make use of invalid information by trying to select some 
portion of it and possibly transform it into something which is usable you have 
to consider what portion of the advertised information is “correct/usable” and 
what portion is not. All such strategies (and you have done a great job of 
listing what the possibilities are) have to make assumptions because there is 
no way to know with certainty what was intended. In doing so you introduce 
uncertainty into the network behavior because all of your proposed “use some of 
the information strategies” (everything but “Drop all”) are based on the 
premise that the node which originated the invalid information will behave in a 
manner consistent with how the receivers transform the information. But this 
assumes that the node which sent the invalid information realizes that it sent 
invalid information. Given that this occurs because of a bug in the 
implementation – expecting the node to recognize its failure is unrealistic. If 
the node realized that it is sending invalid information then it also then has 
the opportunity to correct the information before it is sent.

As regards the distinction between “SR incapable” and “Drop-all”…at least some 
implementations ( I can only speak about the ones I know about of course) today 
check whether a node is SR-capable before making use of that node – whether it 
is in choosing an outgoing label or electing to use that node as part of a 
TI-LFA. SR capability state is determined when new SR Capability information is 
received. This state is then cached and referenced in the appropriate places in 
the code. “Drop-all” – which presumably allows the use of “Local-SIDs” such as 
ADJ-SIDs – would require SR Capability state to support multiple variants e.g. 
(“Full SR Capability”, “Local SR Capability only”). I don’t deny this could be 
done – but I only want to pursue that if there is consensus that we have a 
practical use case that justifies this. So far, the consensus seems to be that 
there is not such a case.

Les


From: Henderickx, Wim (Wim) [mailto:wim.henderi...@alcatel-lucent.com]
Sent: Wednesday, January 06, 2016 11:19 AM
To: bruno.decra...@orange.com
Cc: Martin Horneffer; Les Ginsberg (ginsberg); 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>" 
<s

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

[Martin Horneffer]

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
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring


___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[stephane.litkowski]

Hi Les,

Happy new year.

I agree with your proposal.
The text must state that  there must be a local configuration mechanism that 
avoids sender to originate overlapping SRGB.
In this case, as you mention, if a router receives overlapping SRGB, this is a 
bad behavior and we cannot guess if the forwarding plane is correctly 
programmed or not on the originator, so it is better to avoid it.

Now regarding the sentence :" The originating router is considered to be 
incapable of supporting the SR-MPLS forwarding plane". Do we have something in 
the architecture document saying that advertising a SRGB is mandatory to use SR 
? Pure theorical example : what if someone wants only to use Adj-SIDs in SR 
network ? there is no need to advertise a SRGB. Stating that the node must be 
considered as non SR capable is strong, it will also prevent the usage of 
Adj-SID which will work well without SRGB. If we consider that having a SRGB is 
mandatory, we need to have this requirement in the architecture document.


Best regards,

Stephane


From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Les Ginsberg 
(ginsberg)
Sent: Monday, January 04, 2016 06:55
To: DECRAENE Bruno IMT/OLN; spring@ietf.org
Subject: [spring] draft-ginsberg-spring-conflict-resolution: SRGB INCONSISTENCY


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



_

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 pie

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

[Les Ginsberg (ginsberg)]

Stephane -

From: stephane.litkow...@orange.com [mailto:stephane.litkow...@orange.com]
Sent: Monday, January 04, 2016 12:55 AM
To: Les Ginsberg (ginsberg); DECRAENE Bruno IMT/OLN; spring@ietf.org
Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB 
INCONSISTENCY

Hi Les,

Happy new year.
[Les:] And to you...

I agree with your proposal.
The text must state that  there must be a local configuration mechanism that 
avoids sender to originate overlapping SRGB.

[Les:] Hmmm...IS-IS draft (for example) already states (Section 3.1):


The originating router MUST NOT advertise overlapping ranges.

   When a router receives multiple overlapping ranges, it MUST conform
   to the procedures defined in   [I-D.ginsberg-spring-conflict-resolution].


Isn't this sufficient?

In this case, as you mention, if a router receives overlapping SRGB, this is a 
bad behavior and we cannot guess if the forwarding plane is correctly 
programmed or not on the originator, so it is better to avoid it.

Now regarding the sentence :" The originating router is considered to be 
incapable of supporting the SR-MPLS forwarding plane". Do we have something in 
the architecture document saying that advertising a SRGB is mandatory to use SR 
? Pure theorical example : what if someone wants only to use Adj-SIDs in SR 
network ? there is no need to advertise a SRGB. Stating that the node must be 
considered as non SR capable is strong, it will also prevent the usage of 
Adj-SID which will work well without SRGB. If we consider that having a SRGB is 
mandatory, we need to have this requirement in the architecture document.

[Les:] An interesting point. What I am after here is recognition that without a 
valid SRGB the indication from a node that it is capable of "processing SR MPLS 
encapsulated IPv4/IPv6 packets on all interfaces" does not apply.
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.

Please help me understand why worrying about this case is useful???

   Les


Best regards,

Stephane


From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Les Ginsberg 
(ginsberg)
Sent: Monday, January 04, 2016 06:55
To: DECRAENE Bruno IMT/OLN; spring@ietf.org<mailto:spring@ietf.org>
Subject: [spring] draft-ginsberg-spring-conflict-resolution: SRGB INCONSISTENCY


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 t

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

[Acee Lindem (acee)]

Since the ranges are all advertised by a single SR capable router and can 
easily be validated locally, I support this change.
Thanks,
Acee

From: spring <spring-boun...@ietf.org<mailto:spring-boun...@ietf.org>> on 
behalf of "Les Ginsberg (ginsberg)" 
<ginsb...@cisco.com<mailto:ginsb...@cisco.com>>
Date: Monday, January 4, 2016 at 12:55 AM
To: Bruno Decraene 
<bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>>, 
"spring@ietf.org<mailto:spring@ietf.org>" 
<spring@ietf.org<mailto:spring@ietf.org>>
Subject: [spring] draft-ginsberg-spring-conflict-resolution: SRGB INCONSISTENCY


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
https://www.ietf.org/mailman/listinfo/spring