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

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 4 Jan 2016 05:55:28 +0000

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

---

From: <[email-masked]>
Date: Mon, 4 Jan 2016 08:55:14 +0000

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:[email-masked]] On Behalf Of Les Ginsberg (ginsberg)
Sent: Monday, January 04, 2016 06:55
To: DECRAENE Bruno IMT/OLN; [email-masked]
Subject: [spring] draft-ginsberg-spring-conflict-resolution: SRGB INCONSISTENCY

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 pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 4 Jan 2016 13:40:29 +0000

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 <[email-masked]<mailto:[email-masked]>> on behalf of "Les Ginsberg (ginsberg)" <[email-masked]<mailto:[email-masked]>>
Date: Monday, January 4, 2016 at 12:55 AM
To: Bruno Decraene <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [spring] draft-ginsberg-spring-conflict-resolution: SRGB INCONSISTENCY

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:

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.

“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

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 4 Jan 2016 23:34:13 +0000

Stephane -

From: [email-masked] [mailto:[email-masked]]
Sent: Monday, January 04, 2016 12:55 AM
To: Les Ginsberg (ginsberg); DECRAENE Bruno IMT/OLN; [email-masked]
Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB INCONSISTENCY

Hi Les,

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

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

<snip>
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].
<end snip>

Isn't this sufficient?

[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:[email-masked]] On Behalf Of Les Ginsberg (ginsberg)
Sent: Monday, January 04, 2016 06:55
To: DECRAENE Bruno IMT/OLN; [email-masked]<mailto:[email-masked]>
Subject: [spring] draft-ginsberg-spring-conflict-resolution: SRGB INCONSISTENCY

Comments?

   Les

Thank you.

---

From: <[email-masked]>
Date: Tue, 5 Jan 2016 08:44:36 +0000

Hi Les,

Pls find more inline.

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Tuesday, January 05, 2016 00:34
To: LITKOWSKI Stephane SCE/OINIS; DECRAENE Bruno IMT/OLN; [email-masked]
Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB INCONSISTENCY

Stephane -

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Monday, January 04, 2016 12:55 AM
To: Les Ginsberg (ginsberg); DECRAENE Bruno IMT/OLN; [email-masked]<mailto:[email-masked]>
Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB INCONSISTENCY

Hi Les,

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

<snip>

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

Please help me understand why worrying about this case is useful???
[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).

   Les

Best regards,

Stephane

Comments?

   Les

Thank you.

---

From: Martin Horneffer <[email-masked]>
Date: Tue, 5 Jan 2016 13:05:11 +0100

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.
>
> This is one instance of a class of solutions which attempt to make use 
> of part of the advertisements even when there is some inconsistency 
> (overlap) in the set of SRGB ranges received. A more complete 
> discussion of this class of solutions can be seen in 
> https://mailarchive.ietf.org/arch/attach/spring/txtk0n56G.txt - many 
> thanx to Bruno for writing this.
>
> However, there is an alternative solution which was suggested (notably 
> by Acee Lindem) after the draft was written. This alternative is to 
> ignore the entire set of SRGB advertisements and treat the problematic 
> router as if it were not SR MPLS capable. This alternative was 
> discussed during the presentation in SPRING WG at IETF94 (see 
> https://www.ietf.org/proceedings/94/slides/slides-94-spring-2.pdf 
> slide #3 
> <https://www.ietf.org/proceedings/94/slides/slides-94-spring-2.pdf%20slide%20#3>). 
>  It is also discussed in Bruno's post 
> (https://mailarchive.ietf.org/arch/attach/spring/txtk0n56G.txt - see 
> Section 2.2).
>
> The basis of the alternative solution is that a correct implementation 
> should never allow inconsistent SRGB ranges to be successfully 
> configured (let alone advertised). So this is not a case of a 
> misconfiguration – it is a case of a defective implementation. It 
>  then seems appropriate to put the onus on the originating router to 
> only send valid SRGB advertisements rather than forcing all the 
> receivers to try to "correct" the invalid information in some 
> consistent way. This has a number of advantages:
>
> 1.It is by far the simplest to implement
>
> 2.It isolates the router which is untrustworthy
>
> 3.As the problem can only occur as a result of a defective 
> implementation the behavior of the originating router is unpredictable 
> – it is therefore safer not to use the information
>
> It is worth noting that since the invalid advertisement is the result 
> of some sort of defect in the originating router’s implementation, it 
> is not safe to assume that the source will actually be using the 
> advertised SRGB in a manner consistent with the selective choice made 
> by the receiving routers.
>
> I therefore propose that the above quoted text from 
> https://datatracker.ietf.org/doc/draft-ginsberg-spring-conflict-resolution/ 
> be replaced with the following:
>
> “The set of received ranges is examined . If there is overlap between 
> any two of the advertised ranges the entire SRGB set is considered 
> invalid and is ignored.
>
> The originating router is considered to be incapable of supporting the 
> SR-MPLS forwarding plane. Routers which receive an SRGB advertisement 
> with overlapping ranges SHOULD report the occurrence.”
>
> Comments?
>
>    Les
>
>
>
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Tue, 5 Jan 2016 18:41:25 +0000

My main question on the proposal is how do we tell who is right and who is wrong?

From: spring <[email-masked]<mailto:[email-masked]>> on behalf of Martin Horneffer <[email-masked]<mailto:[email-masked]>>
Date: Tuesday 5 January 2016 at 13:05
To: "Les Ginsberg (ginsberg)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Stephane Litkowski <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution: SRGB INCONSISTENCY

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

One of the topics discussed in <https://datatracker.ietf.org/doc/draft-ginsberg-spring-conflict-resolution/> https://datatracker.ietf.org/doc/draft-ginsberg-spring-conflict-resolution/ is how to handle inconsistent SRGB advertisements from a given node.

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>https://mailarchive.ietf.org/arch/attach/spring/txtk0n56G.txt - see Section 2.2).

I therefore propose that the above quoted text from  <https://datatracker.ietf.org/doc/draft-ginsberg-spring-conflict-resolution/> https://datatracker.ietf.org/doc/draft-ginsberg-spring-conflict-resolution/ be replaced with the following:

Comments?

   Les

_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/spring

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 5 Jan 2016 20:30:20 +0000

Stephane -

From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, January 05, 2016 12:45 AM
To: Les Ginsberg (ginsberg); DECRAENE Bruno IMT/OLN; [email-masked]
Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB INCONSISTENCY

Hi Les,

Pls find more inline.

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

Stephane -

Hi Les,

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

<snip>

Isn't this sufficient?

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

[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". I will take an action item to follow up on that with the various draft authors.

    Les

   Les

Best regards,

Stephane

Comments?

   Les

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Wed, 6 Jan 2016 18:03:59 +0000

Hi Wim,

Many thanks for taking part in the discussion.
Could you please elaborate? e.g. what do you mean by ”who” and “wrong” on what?
I could see multiple interpretations, but it would probably be faster if you elaborate by yourself.

Thanks
-- Bruno

From: spring [mailto:[email-masked]] On Behalf Of Henderickx, Wim (Wim)
Sent: Tuesday, January 05, 2016 7:41 PM
To: Martin Horneffer; Les Ginsberg (ginsberg); [email-masked]; LITKOWSKI Stephane SCE/OINIS
Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution: SRGB INCONSISTENCY

happy new year!

Best regards,
Martin

Comments?

   Les

spring mailing list

---

From: <[email-masked]>
Date: Wed, 6 Jan 2016 18:04:05 +0000

Hi Les,

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

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Monday, January 04, 2016 6:55 AM
To: DECRAENE Bruno IMT/OLN; [email-masked]
Subject: draft-ginsberg-spring-conflict-resolution: SRGB INCONSISTENCY

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

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

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

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

[Bruno] Agreed for the invalid info. For valid info, this is very debatable and difficult to draw the limit.

We could say that such buggy implementation should be removed whole all networks worldwide for at least N years if you really want to put the bar very high. Works for me.

Comments?

[Bruno] This sounds like you are not considering the proposition to describe an evaluate all/main options. As already expressed, I don't think that's will help on building the consensus.

To specifically answer your question, I don't see why this proposition would be preferred to the "Drop all" or "Drop from the conflict" options. And here comes the needs to share the analysis on the requirements and the pro & con.

-- Bruno

   Les

---

From: <[email-masked]>
Date: Wed, 6 Jan 2016 18:04:10 +0000

Hi Les,

Please see points inline [Bruno]

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Tuesday, January 05, 2016 12:34 AM
To: LITKOWSKI Stephane SCE/OINIS; DECRAENE Bruno IMT/OLN; [email-masked]
Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB INCONSISTENCY

Stephane -

Hi Les,

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

<snip>

Isn't this sufficient?

[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.
[Bruno] And what if N global SIDs are advertised while a node advertise a SRGB range of M with M<N?

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.
[Bruno]
- why would we want to make the error/consequences bigger than it is?
- as a use case, a clever ingress implementation would be able to still cross/use this node, it's network capacity if it's a core node and it's attached customer if it's an edge node.

Doing so certainly complicates implementations.
[Bruno] Doing _anything_ complicates the implementation. One could argue that adding SR complicates implementations, in particular if LDP and RSVP-TE code is not removed. The questions are "how much" and "for what benefit'".

Implementations today verify whether a node supports SR-MPLS before using SR-MPLS advertisements (prefix-SIDs, ADJ-SIDs).
[Bruno] Is this the only check performed? One could argue that one implementation should equally check that the SRGB is large enough for a given SID. Such check to automatically handle the consequences of all options, in particular "Drop all"

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.

   Les

Best regards,

Stephane

Comments?

   Les

Thank you.

---

From: <[email-masked]>
Date: Wed, 6 Jan 2016 18:05:21 +0000

Les,

<chair hat>

[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.
</chair hat>

-- Bruno

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

Stephane -

Hi Les,

Pls find more inline.

Stephane -

Hi Les,

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

<snip>

Isn't this sufficient?

    Les

   Les

Best regards,

Stephane

Comments?

   Les

Thank you.

Thank you.

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Wed, 6 Jan 2016 19:19:10 +0000

If you avoid an inconsistency in an SRGB announcement there is multiple scenario’s in which you determine who is right/wrong:

  *   Assume you are in a startup scenario, it is very hard to determine who is consistent and who is not
  *   If you are in a running network and you add a new node or have a different config on 1 node, you can determine it
  *   If you merge a network and the config is wrong in one part but not in the other part of the network.

I see this strategy work in some case but in others I see challenges to determine what is right and what is wrong, hence my question

From: Bruno Decraene <[email-masked]<mailto:[email-masked]>>
Date: Wednesday 6 January 2016 at 19:03
To: Wim Henderickx <[email-masked]<mailto:[email-masked]>>
Cc: Martin Horneffer <[email-masked]<mailto:[email-masked]>>, "Les Ginsberg (ginsberg)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Stephane Litkowski <[email-masked]<mailto:[email-masked]>>
Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB INCONSISTENCY

Hi Wim,

Thanks
-- Bruno

From:spring [mailto:[email-masked]] On Behalf Of Henderickx, Wim (Wim)
Sent: Tuesday, January 05, 2016 7:41 PM
To: Martin Horneffer; Les Ginsberg (ginsberg); [email-masked]<mailto:[email-masked]>; LITKOWSKI Stephane SCE/OINIS
Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution: SRGB INCONSISTENCY

happy new year!

Best regards,
Martin

Comments?

   Les

spring mailing list

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 7 Jan 2016 01:17:45 +0000

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:[email-masked]]
Sent: Wednesday, January 06, 2016 11:19 AM
To: [email-masked]
Cc: Martin Horneffer; Les Ginsberg (ginsberg); [email-masked]; LITKOWSKI Stephane SCE/OINIS
Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution: SRGB INCONSISTENCY

Hi Wim,

Thanks
-- Bruno

happy new year!

Best regards,
Martin

Comments?

   Les

spring mailing list

Thank you.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 7 Jan 2016 05:21:55 +0000

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: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, January 06, 2016 10:05 AM
To: Les Ginsberg (ginsberg); LITKOWSKI Stephane SCE/OINIS
Cc: [email-masked]
Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB INCONSISTENCY

Les,

<chair hat>

</chair hat>

-- Bruno

Stephane -

Hi Les,

Pls find more inline.

Stephane -

Hi Les,

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

<snip>

Isn't this sufficient?

    Les

   Les

Best regards,

Stephane

Comments?

   Les

Thank you.

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Mon, 11 Jan 2016 16:53:05 +0000

Les,

Please see inline [Bruno]

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Thursday, January 07, 2016 2:18 AM
To: Henderickx, Wim (Wim); DECRAENE Bruno IMT/OLN
Cc: Martin Horneffer; [email-masked]; LITKOWSKI Stephane SCE/OINIS
Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB INCONSISTENCY

Bruno –

[Bruno] This is a matter of definition. We can define or redefine whatever we want, but as of today, I don’t recall this definition either in the ISIS or SR architecture document. Could you please point to me the draft/text where this comes from?
And regarding 2) what do you mean by a valid SRGB set? Enough to handle all global SIDs? or 80%? Or 10%?

1)All receivers have consistent behavior
[Bruno] This assumes that the error is on the sender side. In which case, this is true for all options being considered, no?
When the error is on the receiver side, this has the benefit or not risking mis-forwarding to a wrong destination. But this is not specific to this option.
Please review, comment/correct my latest proposed text, so that we agree on the pro & con on all options.

2)We NEVER risk forwarding a packet with a label which will be misinterpreted
[Bruno] As you said “No matter what policy is chosen we cannot guarantee all traffic will be delivered correctly”. e.g. The sender may send incorrect information even in the absence of visible conflict. Alternatively the error may be on the receiver side, in which case different receiver will make difference decision.
I agree that misrouting is an important factor to consider. Please read and comment my text in section “Discussion” so that your point be included if it’s not.
I fail to see why “Drop all” has a bigger risk. “Drop all from conflict” may have a bigger risk, but this is debatable as the argument I have in mind is close to FUD.

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
[Bruno] We all agree to drop invalid information.
Then between all valid information, we are trying to draw the line between the one we believe we can trust and the one we believe we can’t, given the knowledge that the sender sent incorrect SRGB ranges.

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.
[Bruno] Although I’m not a coder, I would tend to comments that point. I would assume that the lines of code responsible for sending the info in IS-IS (or checking configuration validity) are different and independent from the lines of code using the info from the IS-IS LSDB. Hence having a bug in the first code, should not change the probability to have a bug in the second code.

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.
[Bruno] Thanks for sharing the data. IMHO this is useful to build consensus.
From a specification standpoint, we could distinguish 2 points:
a) LSR / transit (CONTINUE/SWP operation.
b) LER ingress (PUSH operation):

Regarding a/transit, we agree that it’s important that all nodes transiting a global segment agree on this global segment. Hence the need for a standardized conflict resolution. In particular, we need to avoid that an ingress/PUSH node consider that the SID is valid, while a downstream node believe the SID is invalid and hence silently drop the traffic for this SID.
Regarding b/PUSH, the choice to use/consider a specific segment as valid, is a local behavior on the ingress. We don’t need to standardize/constraint this point. “Drop all” do not constraint this choice and hence give the ability for an implementation to not trust any local SID from this node (which seem to be your preference). And let another implementation have the freedom to use the local SID if it wants. I can see 2 benefits:
- this allows for (future) use case using local segments.
- we don’t have to all agree on this point hence this avoid the discussion.

IOW:
- we all agree that (some) global SIDs must not be transited across this node
- we are discussing whether we can PUSH local SID from that node or not. But this seems like a local choice where we don’t necessary need to agree/specify.

Not involving the local SIDs in the text makes your existing implementation fine, while not forcing others to follow your specific choice.

Regarding the use case to allow for local SID:
- some existing implementations use a list of adjacency segments to enforce explicitly routed path, as this is easier to compute than compressing the SID with Node SIDs. This is perfectly valid as the tradeoff between label stack depth and CPU computation is local, hence a platform may find easier to use more labels. (although load balancing hashing capabilities is a less local issue)
- if on a node, the SRGB is either missing or too small of a global SID (regardless of conflict or not) , a clever implementation may use adjacency SID to cross that specific node. This is a local feature which seems to me in-line with SR benefit where any node can locally build forwarding behaviors based on local intelligence.

-- Bruno

    Les

From: Henderickx, Wim (Wim) [mailto:[email-masked]]
Sent: Wednesday, January 06, 2016 11:19 AM
To: [email-masked]<mailto:[email-masked]>
Cc: Martin Horneffer; Les Ginsberg (ginsberg); [email-masked]<mailto:[email-masked]>; LITKOWSKI Stephane SCE/OINIS
Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution: SRGB INCONSISTENCY

Hi Wim,

Thanks
-- Bruno

happy new year!

Best regards,
Martin

Comments?

   Les

spring mailing list

Thank you.

---

From: <[email-masked]>
Date: Mon, 11 Jan 2016 16:53:08 +0000

Les,

Regarding my second point, thank you for agreeing to involve the WG.
Regarding my first point, following your statement that you may want to change the spring architecture document, I assume that we should not send the document to the IESG before you've figured out whether additional work is needed in the WG.

-- Bruno

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Thursday, January 07, 2016 6:22 AM
To: DECRAENE Bruno IMT/OLN; LITKOWSKI Stephane SCE/OINIS
Cc: [email-masked]
Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB INCONSISTENCY

   Les

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Wednesday, January 06, 2016 10:05 AM
To: Les Ginsberg (ginsberg); LITKOWSKI Stephane SCE/OINIS
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB INCONSISTENCY

Les,

<chair hat>

</chair hat>

-- Bruno

Stephane -

Hi Les,

Pls find more inline.

Stephane -

Hi Les,

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

<snip>

Isn't this sufficient?

    Les

   Les

Best regards,

Stephane

Comments?

   Les

Thank you.

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Mon, 11 Jan 2016 16:53:12 +0000

Hi Wim,

I read that you are pointing out the difficulty to identify the inconsistency.
If so, this point is common to all options being discussed.

I may be missing some of your points. This thread is about inconsistency in the SRGB ranges advertised by _one_ node. I’m not sure to see your “startup scenario” nor the “merge network scenario”. Could you please elaborate?

Thanks,
Bruno

From: Henderickx, Wim (Wim) [mailto:[email-masked]]
Sent: Wednesday, January 06, 2016 8:19 PM
To: DECRAENE Bruno IMT/OLN
Cc: Martin Horneffer; Les Ginsberg (ginsberg); [email-masked]; LITKOWSKI Stephane SCE/OINIS
Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution: SRGB INCONSISTENCY

Hi Wim,

Thanks
-- Bruno

happy new year!

Best regards,
Martin

Comments?

   Les

spring mailing list

Thank you.

---

From: "HENDERICKX, Wim (Wim)" <[email-masked]>
Date: Mon, 11 Jan 2016 20:07:00 +0000

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.

Date: Monday 11 January 2016 at 17:53

Hi Wim,

Thanks,
Bruno

Hi Wim,

Thanks
-- Bruno

happy new year!

Best regards,
Martin

Comments?

   Les

spring mailing list

Thank you.

---

From: "Fedyk, Don" <[email-masked]>
Date: Mon, 11 Jan 2016 21:41:11 +0000

Hi Wim

If I understand your Option 1) it can occur, for example, if two nodes that have a conflicting SRGB but they are not directly connected and as such there can be a race condition where they advertise SRGB conflict at roughly the same time.  So nodes in the middle have to decide who wins.   (If that is the case, that is the same issue we had in SPB for certain conflicts and the solution was to use NodeID as a tie breaker to decide which node wins.)  In the SRGB case the loosing Node would also receive the winning nodes SRGB and would “know” there is a conflict and it lost. It is true that the looser could have had the SRGB established for a long time and suddenly become Segment Routing incapable because of a higher priority node’s conflicting config.  However I think that is the nature of this situation SRGB information it must be consistent.  The thing to make sure of is that any SRGB configuration can be relatively easily migrated to a non-conflicting range and a configuration model that does not make it easy to accidentally create SRGB conflicts into an existing network.

Not sure I follow your option 2 but option 1 can be easy to determine winners and losers (not right and wrong ☺ ).

Cheers,
Don

From: spring [mailto:[email-masked]] On Behalf Of HENDERICKX, Wim (Wim)
Sent: Monday, January 11, 2016 3:07 PM
To: [email-masked]
Cc: Les Ginsberg (ginsberg); Martin Horneffer; [email-masked]; LITKOWSKI Stephane SCE/OINIS
Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution: SRGB INCONSISTENCY

My 2 cents.

Hi Wim,

Thanks,
Bruno

Hi Wim,

Thanks
-- Bruno

happy new year!

Best regards,
Martin

Comments?

   Les

spring mailing list

Thank you.

Thank you.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 11 Jan 2016 22:36:57 +0000

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:[email-masked]]
Sent: Monday, January 11, 2016 1:41 PM
To: HENDERICKX, Wim (Wim); [email-masked]
Cc: Les Ginsberg (ginsberg); Martin Horneffer; [email-masked]; LITKOWSKI Stephane SCE/OINIS
Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB INCONSISTENCY

Hi Wim

Cheers,
Don

Cc: Les Ginsberg (ginsberg); Martin Horneffer; [email-masked]<mailto:[email-masked]>; LITKOWSKI Stephane SCE/OINIS

My 2 cents.

Hi Wim,

Thanks,
Bruno

Hi Wim,

Thanks
-- Bruno

happy new year!

Best regards,
Martin

Comments?

   Les

spring mailing list

Thank you.

Thank you.

---

From: "Fedyk, Don" <[email-masked]>
Date: Mon, 11 Jan 2016 23:05:50 +0000

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?

Don

From: spring [mailto:[email-masked]] On Behalf Of Les Ginsberg (ginsberg)
Sent: Monday, January 11, 2016 5:37 PM
To: Fedyk, Don; HENDERICKX, Wim (Wim); [email-masked]
Cc: LITKOWSKI Stephane SCE/OINIS; Martin Horneffer; [email-masked]
Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution: SRGB INCONSISTENCY

Folks –

   Les

To: HENDERICKX, Wim (Wim); [email-masked]<mailto:[email-masked]>

Hi Wim

Cheers,
Don

My 2 cents.

Hi Wim,

Thanks,
Bruno

Hi Wim,

Thanks
-- Bruno

happy new year!

Best regards,
Martin

Comments?

   Les

spring mailing list

Thank you.

Thank you.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 11 Jan 2016 23:41:00 +0000

Don -

From: Fedyk, Don [mailto:[email-masked]]
Sent: Monday, January 11, 2016 3:06 PM
To: Les Ginsberg (ginsberg); HENDERICKX, Wim (Wim); [email-masked]
Cc: LITKOWSKI Stephane SCE/OINIS; Martin Horneffer; [email-masked]
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. 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:[email-masked]] On Behalf Of Les Ginsberg (ginsberg)
Sent: Monday, January 11, 2016 5:37 PM
To: Fedyk, Don; HENDERICKX, Wim (Wim); [email-masked]<mailto:[email-masked]>
Cc: LITKOWSKI Stephane SCE/OINIS; Martin Horneffer; [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution: SRGB INCONSISTENCY

Folks –

   Les

Hi Wim

Cheers,
Don

My 2 cents.

Hi Wim,

Thanks,
Bruno

Hi Wim,

Thanks
-- Bruno

happy new year!

Best regards,
Martin

Comments?

   Les

spring mailing list

Thank you.

Thank you.

---

From: "AISSAOUI, Mustapha (Mustapha)" <[email-masked]>
Date: Mon, 11 Jan 2016 23:42:31 +0000

Hi Martin,
the proposal to ignore the entire SRGB set advertised by a router does impact both traffic destined to prefixes of that router and traffic destined to prefixes downstream of that router (prefixes reachable via that router).

As long as event logs/traps are generated when the condition is detected, then the user will be able to pinpoint the offending router.

Regards,
Mustapha.

From: spring [mailto:[email-masked]] On Behalf Of Martin Horneffer
Sent: Tuesday, January 05, 2016 7:05 AM
To: Les Ginsberg (ginsberg); [email-masked]; [email-masked]
Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution: SRGB INCONSISTENCY

happy new year!

Best regards,
Martin

Comments?

   Les

spring mailing list

[email-masked]<mailto:[email-masked]>

---

From: "HENDERICKX, Wim (Wim)" <[email-masked]>
Date: Tue, 12 Jan 2016 04:17:52 +0000

Don, I get that but the key question is if the looser that is picked is the one who creates the biggest network impact or not. This is what I mean with right or wrong.

I just want to have a discussion on both options and agree on the best strategy to minimise the impact in a network when this would happen.

Option 2 is basically something along this line and was suggested before afaik.
A)
[1000, 1099]  => overlap with second
[1099, 2099]  => overlap with first
[5000, 6099]

ð  Ignore label range [1099, 2099],
sid index 100 will be translated to label 5000.
sid index > 200 will not be translated + information logged

B)
[1000, 1099] => overlap with second
[1099, 2099] => overlap with first & last
[2099, 3099] => overlap with second

ð  Ignore label range [1099, 2099] & [2099, 3099],
sid index 0 will be translated to label 1000.
sid index > 100 can not be translated + information logged
C)
[1000, 1099] => overlap with last
[2000, 2099]
[900, 1000]  => overlap with first

ð  Ignore label range [900, 1000]
sid index 0 will be translated to label 1000.
sid index > 200 can not be translated + information logged

From: "Fedyk, Don" <[email-masked]<mailto:[email-masked]>>
Date: Monday 11 January 2016 at 22:41
To: Wim Henderickx <[email-masked]<mailto:[email-masked]>>, Bruno Decraene <[email-masked]<mailto:[email-masked]>>
Cc: "Les Ginsberg (ginsberg)" <[email-masked]<mailto:[email-masked]>>, Martin Horneffer <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Stephane Litkowski <[email-masked]<mailto:[email-masked]>>
Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB INCONSISTENCY

Hi Wim

Cheers,
Don

My 2 cents.

Hi Wim,

Thanks,
Bruno

Hi Wim,

Thanks
-- Bruno

happy new year!

Best regards,
Martin

Comments?

   Les

spring mailing list

Thank you.

Thank you.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 12 Jan 2016 05:28:31 +0000

Wim –

Please  explain to me how the receivers – who you are proposing to make one of the choices below – know what the node which advertised the overlapping ranges is actually doing when it installs local labels in its forwarding plane?

For example, suppose in the example below the receivers choose to ignore the second label range [1099, 2099].

So the neighbor of the faulty node pushes label 5000 for the prefix which has SID 100. What happens when the packet arrives at the problematic node?

A)If “faulty node” is using the overlapping range, then label 5000 will  be associated with the prefix with SID 1100 – and the packet will be forwarded out some interface using the label that “faulty node’s neighbor” has associated with SID 1100.

B)If “faulty node” is NOT using anything but the first range, then label 5000 isn’t an SR assigned label. The packet might get dropped – or it might get forwarded using an LDP label (for example) if LDP happens to be using label 5000.

C)Maybe “faulty node” has an inconsistency between what it advertised and what it is actually using. It meant to advertise:
   [1000, 1099]
  [2000, 2099]
  [5000, 6099]

but the second entry got corrupted during formatting.
Now label 5000 is associated with the prefix having SID 200 – and we have similar behavior to “A” above.

The list of possibilities goes on and on – and yes – one of the possibilities is that you “get lucky” and faulty node happens to be doing what you hoped it might and forwarding “works”.  But there is no way for you to know what faulty node is actually doing. So all this speculation about which choice might result in the “best behavior” is like playing the lottery.

Why would we want to do this? I certainly do not.

   Les

From: HENDERICKX, Wim (Wim) [mailto:[email-masked]]
Sent: Monday, January 11, 2016 8:18 PM
To: Fedyk, Don; [email-masked]
Cc: Les Ginsberg (ginsberg); Martin Horneffer; [email-masked]; LITKOWSKI Stephane SCE/OINIS
Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution: SRGB INCONSISTENCY

B)

Hi Wim

Cheers,
Don

My 2 cents.

Hi Wim,

Thanks,
Bruno

Hi Wim,

Thanks
-- Bruno

happy new year!

Best regards,
Martin

Comments?

   Les

spring mailing list

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Tue, 12 Jan 2016 08:57:15 +0000

Hi,

Fully agree with Les statement, as long as a sender MUST NOT sent overlapping SRGB for a particular protocol, if a node receives overlapping SRGBs in a LSP, it cannot really predict the behavior of the sender when it will receive a packet using those SRGB. The only thing the receiver knows is that the sender is buggy or something changed “smartly” on the wire. So not sure we can trust any of the information received from a SR point of view.

Brgds,

Stephane

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Tuesday, January 12, 2016 06:29
To: HENDERICKX, Wim (Wim); Fedyk, Don; DECRAENE Bruno IMT/OLN
Cc: Martin Horneffer; [email-masked]; LITKOWSKI Stephane SCE/OINIS
Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB INCONSISTENCY

Wim –

   Les

To: Fedyk, Don; [email-masked]<mailto:[email-masked]>

B)

Hi Wim

Cheers,
Don

My 2 cents.

Hi Wim,

Thanks,
Bruno

Hi Wim,

Thanks
-- Bruno

happy new year!

Best regards,
Martin

Comments?

   Les

spring mailing list

Thank you.

Thank you.

---

From: "HENDERICKX, Wim (Wim)" <[email-masked]>
Date: Tue, 12 Jan 2016 09:01:50 +0000

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)" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday 12 January 2016 at 06:28
To: Wim Henderickx <[email-masked]<mailto:[email-masked]>>, "Fedyk, Don" <[email-masked]<mailto:[email-masked]>>, Bruno Decraene <[email-masked]<mailto:[email-masked]>>
Cc: Martin Horneffer <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Stephane Litkowski <[email-masked]<mailto:[email-masked]>>
Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB INCONSISTENCY

Wim –

   Les

B)

Hi Wim

Cheers,
Don

My 2 cents.

Hi Wim,

Thanks,
Bruno

Hi Wim,

Thanks
-- Bruno

happy new year!

Best regards,
Martin

Comments?

   Les

spring mailing list

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Tue, 12 Jan 2016 11:50:40 +0000

Les,

Please see inline 1 point below [Bruno]

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
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; [email-masked]
Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB INCONSISTENCY

Don -

To: Les Ginsberg (ginsberg); HENDERICKX, Wim (Wim); [email-masked]<mailto:[email-masked]>

Hi  Les

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

Folks –

   Les

Hi Wim

Cheers,
Don

My 2 cents.

Hi Wim,

Thanks,
Bruno

Hi Wim,

Thanks
-- Bruno

happy new year!

Best regards,
Martin

Comments?

   Les

spring mailing list

Thank you.

Thank you.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 12 Jan 2016 15:22:40 +0000

Wim -

From: HENDERICKX, Wim (Wim) [mailto:[email-masked]]
Sent: Tuesday, January 12, 2016 1:02 AM
To: Les Ginsberg (ginsberg); Fedyk, Don; [email-masked]
Cc: Martin Horneffer; [email-masked]; 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.

Wim –

   Les

B)

Hi Wim

Cheers,
Don

My 2 cents.

Hi Wim,

Thanks,
Bruno

Hi Wim,

Thanks
-- Bruno

happy new year!

Best regards,
Martin

Comments?

   Les

spring mailing list

Thank you.

Thank you.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 12 Jan 2016 15:38:29 +0000

Bruno -

From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, January 12, 2016 3:51 AM
To: Les Ginsberg (ginsberg)
Cc: [email-masked]; Henderickx, Wim (Wim)
Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB INCONSISTENCY

Les,

Don -

Hi  Les

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

[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

   Les

Don

Folks –

   Les

Hi Wim

Cheers,
Don

My 2 cents.

Hi Wim,

Thanks,
Bruno

Hi Wim,

Thanks
-- Bruno

happy new year!

Best regards,
Martin

Comments?

   Les

spring mailing list

Thank you.

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Tue, 12 Jan 2016 17:50:19 +0000

Les,

Please see inline [Bruno2]

Sent: Tuesday, January 12, 2016 4:38 PM

Bruno -

Cc: [email-masked]<mailto:[email-masked]>; Henderickx, Wim (Wim)

Les,

Don -

Hi  Les

[1000, 1099]
[2000, 2099]

[1000, 2099]
[2000, 2099]

[Bruno2] Yes, and I have updated the text in my document to include your point.. But I don’t think it’s about « reasonable” or “likely”. In my view, it’s about trusting (or not) a received data which is correct from both a syntax and semantic perspective.
We could define an option which would be dropping before the conflict. Would that make a difference for you?
Because, I can equally build an example where your proposition would be erroneous. e.g.
the intended set of ranges is:
[1000, 1099]
[2000, 2099]

But something gets mangled when using formatting the sub-TLV and what is advertised turns out to be:
[1000, 1199]
      [2000, 2099]

You believe you can use SID 110 based on the assumption that the ranges which are advertised are correct, but in fact you don’t know that.

And if we don’t believe in data which looks like correct from both a syntax and semantic perspective, we should stop using protocols.

That being said, I think we now have identified the key point of the discussions. If so, now it would be about making a trade-off between Traffic dropping or mis-routing. (as personally I see “implementation complexity” being a significant point, compared these 2.)

--

[Les:] Agreed.

   Les

   Les

Don

Folks –

   Les

Hi Wim

Cheers,
Don

My 2 cents.

Hi Wim,

Thanks,
Bruno

Hi Wim,

Thanks
-- Bruno

happy new year!

Best regards,
Martin

Comments?

   Les

spring mailing list

Thank you.

Thank you.

Thank you.

---

From: "HENDERICKX, Wim (Wim)" <[email-masked]>
Date: Tue, 12 Jan 2016 18:13:53 +0000

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.

Date: Tuesday 12 January 2016 at 16:22

Wim -

From: HENDERICKX, Wim (Wim) [mailto:[email-masked]]
Sent: Tuesday, January 12, 2016 1:02 AM
To: Les Ginsberg (ginsberg); Fedyk, Don; [email-masked]<mailto:[email-masked]>
Cc: Martin Horneffer; [email-masked]<mailto:[email-masked]>; LITKOWSKI Stephane SCE/OINIS
Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution: SRGB INCONSISTENCY

   Les

Wim –

   Les

B)

Hi Wim

Cheers,
Don

My 2 cents.

Hi Wim,

Thanks,
Bruno

Hi Wim,

Thanks
-- Bruno

happy new year!

Best regards,
Martin

Comments?

   Les

spring mailing list

Thank you.

Thank you.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 12 Jan 2016 20:42:24 +0000

Wim -

Sent: Tuesday, January 12, 2016 10:14 AM

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

Wim -

   Les

Wim –

   Les

B)

Hi Wim

Cheers,
Don

My 2 cents.

Hi Wim,

Thanks,
Bruno

Hi Wim,

Thanks
-- Bruno

happy new year!

Best regards,
Martin

Comments?

   Les

spring mailing list

Thank you.

Thank you.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 12 Jan 2016 21:06:16 +0000

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

Sent: Tuesday, January 12, 2016 9:50 AM

Les,

Bruno -

Les,

Don -

Hi  Les

[1000, 1099]
[2000, 2099]

[1000, 2099]
[2000, 2099]

--

[Les:] Agreed.

   Les

   Les

Don

Folks –

   Les

Hi Wim

Cheers,
Don

My 2 cents.

Hi Wim,

Thanks,
Bruno

Hi Wim,

Thanks
-- Bruno

happy new year!

Best regards,
Martin

Comments?

   Les

spring mailing list

Thank you.

Thank you.

Thank you.

Thank you.

---

From: John E Drake <[email-masked]>
Date: Tue, 12 Jan 2016 21:31:48 +0000

Les,

Upon reflection this sounds imminently reasonable.

Yours Irrespectively,

John

Sent: Tuesday, January 12, 2016 4:06 PM

Bruno –

   Les

Les,

Bruno -

Les,

Don -

Hi  Les

[1000, 1099]
[2000, 2099]

[1000, 2099]
[2000, 2099]

--

[Les:] Agreed.

   Les

   Les

Don

Folks –

   Les

Hi Wim

Cheers,
Don

My 2 cents.

Hi Wim,

Thanks,
Bruno

Hi Wim,

Thanks
-- Bruno

happy new year!

Best regards,
Martin

Comments?

   Les

spring mailing list

Thank you.

Thank you.

Thank you.

Thank you.

---

From: Jeff Tantsura <[email-masked]>
Date: Tue, 12 Jan 2016 22:13:25 +0000

Pragmatic and working approach, I support it.

Cheers,
Jeff

From: spring <[email-masked]<mailto:[email-masked]>> on behalf of "Les Ginsberg (ginsberg)" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, January 12, 2016 at 13:06
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Wim Henderickx <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution: SRGB INCONSISTENCY

Bruno –

   Les

Les,

Bruno -

From:[email-masked]<mailto:[email-masked]> [mailto:[email-masked]]

Les,

Don -

Hi  Les

[1000, 1099]
[2000, 2099]

[1000, 2099]
[2000, 2099]

--

[Les:] Agreed.

   Les

   Les

Don

Folks –

   Les

Hi Wim

Cheers,
Don

My 2 cents.

Hi Wim,

Thanks,
Bruno

Hi Wim,

Thanks
-- Bruno

happy new year!

Best regards,
Martin

Comments?

   Les

spring mailing list

Thank you.

Thank you.

Thank you.

Thank you.

---

From: Mach Chen <[email-masked]>
Date: Wed, 13 Jan 2016 08:10:22 +0000

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

Best regards,
Mach

Sent: Wednesday, January 13, 2016 5:06 AM

Bruno –

   Les

Les,

Bruno -

Les,

Don -

Hi  Les

[1000, 1099]
[2000, 2099]

[1000, 2099]
[2000, 2099]

--

[Les:] Agreed.

   Les

   Les

Don

Folks –

   Les

Hi Wim

Cheers,
Don

My 2 cents.

Hi Wim,

Thanks,
Bruno

Hi Wim,

Thanks
-- Bruno

happy new year!

Best regards,
Martin

Comments?

   Les

spring mailing list

Thank you.

Thank you.

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Wed, 13 Jan 2016 09:13:24 +0000

Les,

Thanks for the summary of your position.
Mine inlined [Bruno]

Sent: Tuesday, January 12, 2016 10:06 PM

Bruno –

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.

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.

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

Les,

Bruno -

Les,

Don -

Hi  Les

[1000, 1099]
[2000, 2099]

[1000, 2099]
[2000, 2099]

--

[Les:] Agreed.

   Les

   Les

Don

Folks –

   Les

Hi Wim

Cheers,
Don

My 2 cents.

Hi Wim,

Thanks,
Bruno

Hi Wim,

Thanks
-- Bruno

happy new year!

Best regards,
Martin

Comments?

   Les

spring mailing list

Thank you.

Thank you.

Thank you.

Thank you.

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Wed, 13 Jan 2016 16:22:42 +0000

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) <[email-masked]> wrote:
> 
> Bruno –
>  
> Not sure I follow your option 2 but option 1 can be easy to determine winners and losers (not right and wrong J ).
>  
> Cheers, 
> Don 
>  
> From: Bruno Decraene <[email-masked]>
> To: Wim Henderickx <[email-masked]>
> Cc: Martin Horneffer <[email-masked]>, "Les Ginsberg (ginsberg)" <[email-masked]>, "[email-masked]" <[email-masked]>, Stephane Litkowski <[email-masked]>
> 	• 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.
>  
> From: Bruno Decraene <[email-masked]>
> To: Wim Henderickx <[email-masked]>
> Cc: Martin Horneffer <[email-masked]>, "Les Ginsberg (ginsberg)" <[email-masked]>, "[email-masked]" <[email-masked]>, Stephane Litkowski <[email-masked]>
> From: spring <[email-masked]> on behalf of Martin Horneffer <[email-masked]>
> To: "Les Ginsberg (ginsberg)" <[email-masked]>, "[email-masked]" <[email-masked]>, Stephane Litkowski <[email-masked]>
> 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).
>  
> [email-masked]://www.ietf.org/mailman/listinfo/spring
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 13 Jan 2016 23:49:05 +0000

Bruno -

Sent: Wednesday, January 13, 2016 1:13 AM

Les,

Bruno –

[Les:] In an earlier reply to Stephane I stated:

<snip>
You are suggesting that a node which is not capable of supporting SR-MPLS dataplane for prefix-SIDs should still be allowed to support ADJ-SIDs – although it would have to be restricted to local SIDs  (ADJ-SIDs can be assigned from the global SID space - just not the most common usage). While you may be right in that such a practice is not explicitly forbidden by any of the specifications, I am struggling to find a real world use case.

Doing so certainly complicates implementations. Implementations today verify whether a node supports SR-MPLS before using SR-MPLS advertisements (prefix-SIDs, ADJ-SIDs). You are proposing that this logic be enhanced to treat the case where the node has sent an invalid SRGB as if the node is still SR-MPLS capable but for local SIDs only. I don’t deny this could be done – I just don’t understand why.

<end snip>

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.

[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

   Les

Les,

Bruno -

Les,

Don -

Hi  Les

[1000, 1099]
[2000, 2099]

[1000, 2099]
[2000, 2099]

--

[Les:] Agreed.

   Les

   Les

Don

Folks –

   Les

Hi Wim

Cheers,
Don

My 2 cents.

Hi Wim,

Thanks,
Bruno

Hi Wim,

Thanks
-- Bruno

happy new year!

Best regards,
Martin

Comments?

   Les

spring mailing list

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 14 Jan 2016 07:58:00 +0000

Wim –

You are confused. ☺

SRGB is a local configuration for a box. There is no relationship between the SRGB range(s) used on one node and those used on another node. This is why the SIDs advertised in prefix reachability advertisements (or SRMS) are used as an “index”. For example, consider the simple example below:

      B
   /      \
A            D
  \       /
    C

Suppose Node D advertises reachability to 1.1.1.1/32 with SID = 1000.

On B SRGB is (20000, 21999)
On C SRGB is (21000, 22999)

On Node A:
   when forwarding via B  A will PUSH label 21000 (20000 + 1000)
   when forwarding via C  A will PUSH label 22000 (21000 + 1000)

The fact that there is overlap between the SRGBs of B and C is not an issue because we push labels on a hop-by-hop basis based on the SID and the advertised SRGB of our neighbor.

The issue we are discussing is what happens if a single Node advertises overlapping ranges – for example:

B advertises: (20000, 21999) and (21000, 22999)
This forms an ordered set of ranges such that SIDs 0 – 1999 map to labels 20000 – 221999 and SIDs 2000 – 3999 map to labels 21000 – 22999. (See https://www.ietf.org/id/draft-ietf-isis-segment-routing-extensions-06.txt  Section 3.1 for a more detailed example)

Now when forwarding to B a SID of 1000 maps to label 21000 – but a SID of 2000 also maps to label 21000. WE cannot map two different prefixes to the same label in the forwarding plane so the behavior on Node B is unpredictable.

Hope this helps.

   Les

From: HENDERICKX, Wim (Wim) [mailto:[email-masked]]
Sent: Wednesday, January 13, 2016 9:26 PM
To: Les Ginsberg (ginsberg); Fedyk, Don; [email-masked]
Cc: Martin Horneffer; [email-masked]; LITKOWSKI Stephane SCE/OINIS
Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution: SRGB INCONSISTENCY

Les, I agree you can check some errors when you configure something, but what will you do if I have network A with SRGB-A and network B with SRGB B and you connect them. If we can ensure that network A remain active with SRGB A and SRGB remains active with SRGB B, than I can agree with the proposal since this minimises the impact. Meaning the routers in network A should ignore all advertisements from network B and vice versa, such that the services remain in operation in each network.

Date: Tuesday 12 January 2016 at 21:42

Wim -

   Les

Wim -

   Les

Wim –

   Les

B)

Hi Wim

Cheers,
Don

My 2 cents.

Hi Wim,

Thanks,
Bruno

Hi Wim,

Thanks
-- Bruno

happy new year!

Best regards,
Martin

Comments?

   Les

spring mailing list

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Thu, 14 Jan 2016 08:30:23 +0000

Les,

Sent: Thursday, January 14, 2016 12:49 AM

Bruno -

Les,

Bruno –

<snip>

<end snip>
[Bruno2] 3 points :
a) Safety/validity: I’m still reading no argument saying that « Drop All” is less safe than “SR Incapable”. Can we agree on this?
b) Use cases: Local Segments and in particular Adjacency Segments certainly have use cases. Are you arguing this? If not, “Drop All” has the benefit of not dropping the traffic crossing that node using Local/Adjacency segments.  More on this next few lines.
c) Implementation complexity: 1) this is difficult to measure hence agree on. If your implementation were open source, we could probably discuss it more easily. 2)This may be implementation specific. 3) We have already discussed this https://mailarchive.ietf.org/arch/msg/spring/nAoOL8tCF4qXHYK7c2dIu3Xd47A  In short, before using a global SID, existing implementations must also check that this global SID falls within the SRGB. Hence dropping all the SRGB ranges would already be identified by implementation with no changes.

In subsequent comments no one has indicated that there is such a use case. In the interest of simplicity I am therefore in favor of the “NOT SR-MPLS capable” approach.
[Bruno2]
- I did indicated use case in existing implementations: https://mailarchive.ietf.org/arch/msg/spring/FuMaSOnwO3WvtmMWT9SzV8jbTpE
- In the context of this discussion, one router implementation/controller would still be able to cross/use the node advertising conflicting SRGB ranges by using a local adjacency segment. You may not want to implement this use case, but I don’t see a reason to forbid this.
- And again, local/adjacency are already defined and implemented, because there were use cases.

   Les

   Les

Les,

Bruno -

Les,

Don -

Hi  Les

[1000, 1099]
[2000, 2099]

[1000, 2099]
[2000, 2099]

--

[Les:] Agreed.

   Les

   Les

Don

Folks –

   Les

Hi Wim

Cheers,
Don

My 2 cents.

Hi Wim,

Thanks,
Bruno

Hi Wim,

Thanks
-- Bruno

happy new year!

Best regards,
Martin

Comments?

   Les

spring mailing list

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 14 Jan 2016 20:52:56 +0000

Bruno (and everyone) –

The remaining point to be discussed seems to be whether – when an invalid SRGB is detected by receivers – the offending node should be considered SR-MPLS incapable for both local and global SIDs or whether we should only consider the node MPLS-SR incapable for Global SIDs. The latter proposal has some merit because SRGB is only used in support of global SIDs. However, in order to do this we must insure that all the protocol drafts are consistent with this concept i.e. that SR-MPLS support has two scopes and that the conditions necessary for supporting each of the two scopes are not identical.

For locally scoped SIDs it is sufficient that the node indicate that it supports SR-MPLS for specific address families.
For Globally scoped SIDs the node also has to provide a valid SRGB.

My reading of the existing protocol drafts in this regard is as follows:

https://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv3-segment-routing-extensions/
https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-extensions/

OSPF drafts are consistent with the above.

https://www.ietf.org/id/draft-ietf-idr-bgp-prefix-sid-02.txt

BGP only has defined support for globally scoped SIDs – so no issue here either.

https://www.ietf.org/id/draft-ietf-isis-segment-routing-extensions-06.txt

Here there is an issue. Section 3.1 specifies the contents of the SR-Capabilities Sub-TLV which includes advertisement of both the SR-MPLS support per address-family AND the SRGB. The text states:

“One or more SRGB Descriptor entries…”

So currently it is not valid to send the sub-TLV with no SRGB Descriptors. This text would have to be altered to indicate that the SRGB Descriptors MAY be omitted. This could cause backwards compatibility issues with early deployments as a strict interpretation of the draft would cause such a sub-TLV to be rejected. However, given that local SR-MPLS support only is an unlikely case, I think such a change could be acceptable as there should be sufficient time for all existing implementations to be upgraded before such an exceptional case would need to be deployed (if indeed that is ever required).

Assuming that the IS-IS draft authors and the WG are willing to make the appropriate change in the IS-IS draft then I provide a revised definition of how to handle an invalid SRGB below. I ask all the folks who have already indicated their approval/disapproval of the previous proposal to review the revised proposal and indicate their opinion. Of course I also want to encourage folks who have not yet voiced their opinion to respond as well. ☺

Thanx for all the good discussion – I think the proposal is better for it.

   Les

Revised Proposal:

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

3)Support for locally scoped SIDs is unaffected by the presence/absence/validity of SRGB advertisements.

Sent: Thursday, January 14, 2016 12:30 AM

Les,

Bruno -

Les,

Bruno –

<snip>

<end snip>
[Bruno2] 3 points :

   Les

   Les

Les,

Bruno -

Les,

Don -

Hi  Les

[1000, 1099]
[2000, 2099]

[1000, 2099]
[2000, 2099]

--

[Les:] Agreed.

   Les

   Les

Don

Folks –

   Les

Hi Wim

Cheers,
Don

My 2 cents.

Hi Wim,

Thanks,
Bruno

Hi Wim,

Thanks
-- Bruno

happy new year!

Best regards,
Martin

Comments?

   Les

spring mailing list

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

---

From: Uma Chunduri <[email-masked]>
Date: Thu, 14 Jan 2016 23:34:26 +0000

Dear Les, Bruno,

Thanks for a great discussion on this sticky issue.

Couple of things:

1.       Les, I support advertising explicit SR capability of the node; meaning this doesn’t have  to be tied to one or more SRGB range advertisements.
Though for example, OSPF draft doesn’t say anything about ‘no srgb ranges’ in SID/Label Range TLV, my vote is to be explicit about it.
I also agree to change IS-IS document to change and to align to the rest.

2.       Revised proposal below is good and I agree on -  there is no dependency of SRGB for locally scoped ADJ side it should not be effected because of incorrect SRGB.

-          I would say making this change to remove support for local ADJ sids because of incorrect received SRGB for anode is a bigger change for us (E///) at least.

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

A-----B----C-----D

Consider the above network – if you are node A and you are dealing with a “conflicting range from node D” but valid ranges from node B – you are saying drop  all prefixes with global SIDs. But, I see you are asking this even though outgoing label is completely governed by node B (which is advertising valid ranges) in this case.  Though this  is a bigger change  and ideally should be applicable to only C , it  is  ok to me given the consensus on when senders MUST advertise (non-conflicting ranges) and  still conflicting range is seen.

Most of the checks whatever possible for SRGBs, mapping server SID range conflicts etc. must be prevented locally and this should be  mandated (individual protocol/architecture/conflict document) somewhere. However mapping server SID ranges is a completely different beast and can be discussed some other day on how a receiver should handle the conflicts there.

--
Uma C.

Sent: Thursday, January 14, 2016 12:53 PM

Bruno (and everyone) –

   Les

Revised Proposal:

Les,

Bruno -

Les,

Bruno –

<snip>

<end snip>
[Bruno2] 3 points :

   Les

   Les

Les,

Bruno -

Les,

Don -

Hi  Les

[1000, 1099]
[2000, 2099]

[1000, 2099]
[2000, 2099]

--

[Les:] Agreed.

   Les

   Les

Don

Folks –

   Les

Hi Wim

Cheers,
Don

My 2 cents.

Hi Wim,

Thanks,
Bruno

Hi Wim,

Thanks
-- Bruno

happy new year!

Best regards,
Martin

Comments?

   Les

spring mailing list

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 15 Jan 2016 01:27:32 +0000

Uma –

Thanx for the response.
Inline.

From: Uma Chunduri [mailto:[email-masked]]
Sent: Thursday, January 14, 2016 3:34 PM
To: Les Ginsberg (ginsberg); [email-masked]
Cc: [email-masked]; Henderickx, Wim (Wim)
Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB INCONSISTENCY

Dear Les, Bruno,

Couple of things:

[Les:] IN the case of OSPFv2 there is a separate TLV for advertising algorithm support. This can be used to infer SR-MPLS support for local labels for IPv4. There is no language in the OSPFv2 draft which requires SRGB to be sent.
In the case of OSPFv3, SR Forwarding Capabilities are advertised in the OSPF Router Informational Capabilities TLV. Again there is no requirement to advertise SRGB – so the forwarding capabilities info can be used to infer support for SR-MPLS local SID support.

If you think the OSPF draft language is not explicit enough I suggest you make comments to the OSPF-WG list.

A-----B----C-----D

Consider the above network – if you are node A and you are dealing with a “conflicting range from node D” but valid ranges from node B – you are saying drop  all prefixes with global SIDs.

[Les:] No – no such statement is made. The statement is “treat the sending node as NOT SR-MPLS capable for globally scoped SIDs.”. The sending node in your example is “D”. No changes are made as regards SR-MPLS support for A, B, C. This in fact is not much different than what you MUST do today even with a valid SRGB – because you have to check whether the given SID is within the (set of) SRGB range(s) advertised by your nexthop. If your nexthop is D then in this example no global SID will map to a valid label in D’s forwarding plane – so C MUST NOT install an outgoing label when forwarding traffic via D.

Hope this helps.

   Les

But, I see you are asking this even though outgoing label is completely governed by node B (which is advertising valid ranges) in this case.  Though this  is a bigger change  and ideally should be applicable to only C , it  is  ok to me given the consensus on when senders MUST advertise (non-conflicting ranges) and  still conflicting range is seen.

--
Uma C.

Bruno (and everyone) –

   Les

Revised Proposal:

Les,

Bruno -

Les,

Bruno –

<snip>

<end snip>
[Bruno2] 3 points :

   Les

   Les

Les,

Bruno -

Les,

Don -

Hi  Les

[1000, 1099]
[2000, 2099]

[1000, 2099]
[2000, 2099]

--

[Les:] Agreed.

   Les

   Les

Don

Folks –

   Les

Hi Wim

Cheers,
Don

My 2 cents.

Hi Wim,

Thanks,
Bruno

Hi Wim,

Thanks
-- Bruno

happy new year!

Best regards,
Martin

Comments?

   Les

spring mailing list

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Fri, 15 Jan 2016 08:16:24 +0000

Hi Les,

I’m fine with the proposal.
In any case, the ISIS text must be changed because saying “One or more SRGB Descriptors …” is not really a normative statement, we need to have something more clear using appropriate IETF wording to prevent ambiguity.

Best Regards,

Stephane

Sent: Thursday, January 14, 2016 21:53

Bruno (and everyone) –

   Les

Revised Proposal:

Les,

Bruno -

Les,

Bruno –

<snip>

<end snip>
[Bruno2] 3 points :

   Les

   Les

Les,

Bruno -

Les,

Don -

Hi  Les

[1000, 1099]
[2000, 2099]

[1000, 2099]
[2000, 2099]

--

[Les:] Agreed.

   Les

   Les

Don

Folks –

   Les

Hi Wim

Cheers,
Don

My 2 cents.

Hi Wim,

Thanks,
Bruno

Hi Wim,

Thanks
-- Bruno

happy new year!

Best regards,
Martin

Comments?

   Les

spring mailing list

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

---

From: Peter Psenak <[email-masked]>
Date: Fri, 15 Jan 2016 09:34:18 +0100

Hi Les,

I'm fine with the latest proposal.

thanks,
Peter

On 1/14/16 21:52 , Les Ginsberg (ginsberg) wrote:
> Bruno (and everyone) –
>
> The remaining point to be discussed seems to be whether – when an
> invalid SRGB is detected by receivers – the offending node should be
> considered SR-MPLS incapable for both local and global SIDs or whether
> we should only consider the node MPLS-SR incapable for Global SIDs. The
> latter proposal has some merit because SRGB is only used in support of
> global SIDs. However, in order to do this we must insure that all the
> protocol drafts are consistent with this concept i.e. that SR-MPLS
> support has two scopes and that the conditions necessary for supporting
> each of the two scopes are not identical.
>
> For locally scoped SIDs it is sufficient that the node indicate that it
> supports SR-MPLS for specific address families.
>
> Here there is an issue. Section 3.1 specifies the contents of the
> SR-Capabilities Sub-TLV which includes advertisement of both the SR-MPLS
> support per address-family AND the SRGB. The text states:
>
> /“One or more SRGB Descriptor entries…”/
>
> So currently it is not valid to send the sub-TLV with no SRGB
> Descriptors. This text would have to be altered to indicate that the
> SRGB Descriptors MAY be omitted. This could cause backwards
> compatibility issues with early deployments as a strict interpretation
> of the draft would cause such a sub-TLV to be rejected. However, given
> that local SR-MPLS support only is an unlikely case, I think such a
> change could be acceptable as there should be sufficient time for all
> existing implementations to be upgraded before such an exceptional case
> would need to be deployed (if indeed that is ever required).
>
> Assuming that the IS-IS draft authors and the WG are willing to make the
> appropriate change in the IS-IS draft then I provide a revised
> definition of how to handle an invalid SRGB below. I ask all the folks
> who have already indicated their approval/disapproval of the previous
> proposal to review the revised proposal and indicate their opinion. Of
> course I also want to encourage folks who have not yet voiced their
> opinion to respond as well. J
>
> */Revised Proposal:/*
> */1)SRGB configuration is a local matter. Conforming to the
> specification requirement of NOT advertising overlapping SRGB ranges is
> totally within the control of the local node. Misconfigurations can and
> MUST be detected BEFORE they are advertised./*
>
> *//*
>
> */2)Receivers of an invalid SRGB MUST ignore the SRGB and treat the
> sending node as NOT SR-MPLS capable for globally scoped SIDs./*
>
> *//*
>
> */3)Support for locally scoped SIDs is unaffected by the
> presence/absence/validity of SRGB advertisements./*
>
> *//*
>
> *From:[email-masked] [mailto:[email-masked]]
> *Sent:* Thursday, January 14, 2016 12:30 AM
> *To:* Les Ginsberg (ginsberg)
> *Cc:* [email-masked]; Henderickx, Wim (Wim)
> *Subject:* RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB
> INCONSISTENCY
>
> Les,
>
> *From:*Les Ginsberg (ginsberg) [mailto:[email-masked]]
> *Sent:* Thursday, January 14, 2016 12:49 AM
> *To:* DECRAENE Bruno IMT/OLN
> *Cc:* [email-masked] <mailto:[email-masked]>; Henderickx, Wim (Wim)
> *Subject:* RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB
> INCONSISTENCY
>
> Bruno -
>
> *From:[email-masked] <mailto:[email-masked]>
> [mailto:[email-masked]]
> *Sent:* Wednesday, January 13, 2016 1:13 AM
> *To:* Les Ginsberg (ginsberg)
> *Cc:* [email-masked] <mailto:[email-masked]>; Henderickx, Wim (Wim)
> *Subject:* RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB
> INCONSISTENCY
>
> Les,
>
> *From:*Les Ginsberg (ginsberg) [mailto:[email-masked]]
> *Sent:* Tuesday, January 12, 2016 10:06 PM
> *To:* DECRAENE Bruno IMT/OLN
> *Cc:* [email-masked] <mailto:[email-masked]>; Henderickx, Wim (Wim)
> *Subject:* RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB
> INCONSISTENCY
>
> Bruno –
>
> 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.
>
> */[Les:] In an earlier reply to Stephane I stated:/*
>
> *//*
>
> <snip>
>
> */You are suggesting that a node which is not capable of supporting
> SR-MPLS dataplane for prefix-SIDs should still be allowed to support
> ADJ-SIDs – although it would have to be restricted to local SIDs
> (ADJ-SIDs can be assigned from the global SID space - just not the most
> common usage). While you may be right in that such a practice is not
> explicitly forbidden by any of the specifications, I am struggling to
> find a real world use case./*
>
> *//*
>
> */Doing so certainly complicates implementations. Implementations today
> verify whether a node supports SR-MPLS before using SR-MPLS
> advertisements (prefix-SIDs, ADJ-SIDs). You are proposing that this
> logic be enhanced to treat the case where the node has sent an invalid
> SRGB as if the node is still SR-MPLS capable but for local SIDs only. I
> don’t deny this could be done – I just don’t understand why./*
>
> *//*
>
> <end snip>
>
> [Bruno2] 3 points :
>
> a) Safety/validity: I’m still reading no argument saying that « Drop
> All” is less safe than “SR Incapable”. Can we agree on this?
>
> b) Use cases: Local Segments and in particular Adjacency Segments
> certainly have use cases. Are you arguing this? If not, “Drop All” has
> the benefit of not dropping the traffic crossing that node using
> Local/Adjacency segments.  More on this next few lines.
>
> c) Implementation complexity: 1) this is difficult to measure hence
> agree on. If your implementation were open source, we could probably
> discuss it more easily. 2)This may be implementation specific. 3) We
> have already discussed this
> https://mailarchive.ietf.org/arch/msg/spring/nAoOL8tCF4qXHYK7c2dIu3Xd47AIn
> short, before using a global SID, existing implementations must also
> check that this global SID falls within the SRGB. Hence dropping all the
> SRGB ranges would already be identified by implementation with no changes.
>
> */In subsequent comments no one has indicated that there is such a use
> case. In the interest of simplicity I am therefore in favor of the “NOT
> SR-MPLS capable” approach./*
>
> [Bruno2]
>
> - I did indicated use case in existing implementations:
> */https://mailarchive.ietf.org/arch/msg/spring/FuMaSOnwO3WvtmMWT9SzV8jbTpE/*
>
> - In the context of this discussion, one router
> implementation/controller would still be able to cross/use the node
> advertising conflicting SRGB ranges by using a local adjacency segment.
> You may not want to implement this use case, but I don’t see a reason to
> forbid this.
>
> - And again, local/adjacency are already defined and implemented,
> because there were use cases.*//*
>
> *//*
>
> 3)All proposals to use part of the invalid advertisement run the risk of
> making the problem worse and are based upon assumptions which cannot be
> verified.
>
> [Bruno] This part is about trade-off and opinions. I agree that the
> consequences of misrouting are more adverse than the one of dropping
> traffic. In theory, relative probability of occurrence would also need
> to be taken into account.
>
> 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:[email-masked] <mailto:[email-masked]>
> [mailto:[email-masked]]
> *Sent:* Tuesday, January 12, 2016 9:50 AM
> *To:* Les Ginsberg (ginsberg)
> *Cc:* [email-masked] <mailto:[email-masked]>; Henderickx, Wim (Wim)
> *Subject:* RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB
> INCONSISTENCY
>
> Les,
>
> *From:*Les Ginsberg (ginsberg) [mailto:[email-masked]]
> *Sent:* Tuesday, January 12, 2016 4:38 PM
> *To:* DECRAENE Bruno IMT/OLN
> *Cc:* [email-masked] <mailto:[email-masked]>; Henderickx, Wim (Wim)
> *Subject:* RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB
> INCONSISTENCY
>
> Bruno -
>
> *From:[email-masked] <mailto:[email-masked]>
> [mailto:[email-masked]]
> *Sent:* Tuesday, January 12, 2016 3:51 AM
> *To:* Les Ginsberg (ginsberg)
> *Cc:* [email-masked] <mailto:[email-masked]>; Henderickx, Wim (Wim)
> *Subject:* RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB
> INCONSISTENCY
>
> Les,
>
> *From:*Les Ginsberg (ginsberg) [mailto:[email-masked]]
> *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; [email-masked]
> <mailto:[email-masked]>
> *Subject:* RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB
> INCONSISTENCY
>
> Don -
>
> *From:*Fedyk, Don [mailto:[email-masked]]
> *Sent:* Monday, January 11, 2016 3:06 PM
> *To:* Les Ginsberg (ginsberg); HENDERICKX, Wim (Wim);
> [email-masked] <mailto:[email-masked]>
> *Cc:* LITKOWSKI Stephane SCE/OINIS; Martin Horneffer; [email-masked]
> <mailto:[email-masked]>
> *Subject:* RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB
> INCONSISTENCY
>
> Hi  Les
>
> So you are saying a node that generates inconsistent SRGB (overlapping
> ranges) all by itself should be treated Segment routing incapable and
> this should be easy to detect by any correctly performing neighbor?
>
> */[Les:] Yes. Detection is easy – you simply check for overlapping
> ranges in the advertisement from an individual node./*
>
> */What is generating all the discussion is whether we should treat that
> node as SR-MPLS incapable (a couple of variants there) or try to massage
> the received information into a partially usable form./*
>
> *//*
>
> */This is probably as good a time as any for me to reply to the latter
> proposal./*
>
> *//*
>
> */All of the “use some of the information” variants (detailed at length
> in Bruno’s posts) depend upon the node which sent the inconsistent SRGB
> information itself performing the same transformation as the receivers./*
>
> [Bruno] This is a good technical point to identify. Thanks. I’ll add it
> in the text. IINM, among the options being discussed:
>
> Drop all, Drop from conflict, SR incapable do _/not/_ require any action
> on the advertising node. not to mention consistent action with all
> others nodes.
>
> *//*
>
> */[Les2:] Drop from conflict makes an assumption that the faulty node is
> using the ranges in the order advertised and that the reason the
> conflict exists is because the later ranges were configured incorrectly.
> But we don’t know this for certain. For example – the intended set of
> ranges is:/*
>
> *//*
>
> */[1000, 1099]/*
>
> */[2000, 2099]/*
>
> *//*
>
> */But something gets mangled when formatting the sub-TLV and what is
> advertised turns out to be:/*
>
> *//*
>
> */[1000, 2099]/*
>
> */[2000, 2099]/*
>
> *//*
>
> */Using drop from conflict assumes you can use SIDs 0 – 1099 safely, but
> in fact SIDs greater than 99 will use a label that the faulty node
> (which is using the first set of ranges above) is NOT using for SR./*
>
> *//*
>
> */This looks less egregious than other options only because the
> assumption that the first range which is advertised is correct seems
> “reasonable” or “likely” – but in fact we don’t know that./*
>
> [Bruno2] Yes, and I have updated the text in my document to include your
> point.. But I don’t think it’s about « reasonable” or “likely”. In my
> view, it’s about trusting (or not) a received data which is correct from
> both a syntax and semantic perspective.
>
> You believe you can use SID 110 based on the assumption that the ranges
> which are advertised are correct, but in fact you don’t know that.
>
> And if we don’t believe in data which looks like correct from both a
> syntax and semantic perspective, we should stop using protocols.
>
> That being said, I think we now have identified the key point of the
> discussions. If so, now it would be about making a trade-off between
> Traffic dropping or mis-routing. (as personally I see “implementation
> complexity” being a significant point, compared these 2.)
>
> --
>
> Drop the conflicting one, Merge, Merge and re-order _/do/_ require a new
> behavior on the advertising node, consistent with all others nodes.
>
> */[Les:] Agreed./*
>
> *//*
>
> */But there is a higher order issue here for me – which is that all
> options other than “Drop all” variants have to make an assumption about
> the faulty node behavior which cannot be verified – which means the
> attempt to minimize the damage may actually do further harm. This is not
> acceptable to me./*
>
> *//*
>
> */   Les/*
>
> *//*
> */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:[email-masked]] *On Behalf Of *Les
> Ginsberg (ginsberg)
> *Sent:* Monday, January 11, 2016 5:37 PM
> *To:* Fedyk, Don; HENDERICKX, Wim (Wim); [email-masked]
> <mailto:[email-masked]>
> *Cc:* LITKOWSKI Stephane SCE/OINIS; Martin Horneffer; [email-masked]
> <mailto:[email-masked]>
> *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.
>
> *From:*Fedyk, Don [mailto:[email-masked]]
> *Sent:* Monday, January 11, 2016 1:41 PM
> *To:* HENDERICKX, Wim (Wim); [email-masked]
> <mailto:[email-masked]>
> *Cc:* Les Ginsberg (ginsberg); Martin Horneffer; [email-masked]
> <mailto:[email-masked]>; LITKOWSKI Stephane SCE/OINIS
> *Subject:* RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB
> INCONSISTENCY
>
> Hi Wim
>
> If I understand your Option 1) it can occur, for example, if two nodes
> that have a conflicting SRGB but they are not directly connected and as
> such there can be a race condition where they advertise SRGB conflict at
> roughly the same time.  So nodes in the middle have to decide who
> wins.   (If that is the case, that is the same issue we had in SPB for
> certain conflicts and the solution was to use NodeID as a tie breaker to
> decide which node wins.)  In the SRGB case the loosing Node would also
> receive the winning nodes SRGB and would “know” there is a conflict and
> it lost. It is true that the looser could have had the SRGB established
> for a long time and suddenly become Segment Routing incapable because of
> a higher priority node’s conflicting config.  However I think that is
> the nature of this situation SRGB information it must be consistent.
>   The thing to make sure of is that any SRGB configuration can be
> relatively easily migrated to a non-conflicting range and a
> configuration model that does not make it easy to accidentally create
> SRGB conflicts into an existing network.
>
> Not sure I follow your option 2 but option 1 can be easy to determine
> winners and losers (not right and wrong J).
>
> Cheers,
>
> Don
>
> *From:* spring [mailto:[email-masked]] *On Behalf Of
> *HENDERICKX, Wim (Wim)
> *Sent:* Monday, January 11, 2016 3:07 PM
> *To:* [email-masked] <mailto:[email-masked]>
> *Cc:* Les Ginsberg (ginsberg); Martin Horneffer; [email-masked]
> <mailto:[email-masked]>; LITKOWSKI Stephane SCE/OINIS
> *Subject:* Re: [spring] draft-ginsberg-spring-conflict-resolution: SRGB
> INCONSISTENCY
>
> Option 1 is we ignore a advertisements of some nodes. The main issue I
> see with this is determining who is right/wrong. Implementation is
> rather easy, but you will impact traffic from certain nodes in some case
> as outlined below.
>
> Option 2 is you try to disseminate something out of the information and
> try to determine a consistent behaviour across all node. Implementation
> is more difficult, but I believe there is more coverage/chances to meet
> the overall objective.
>
> My 2 cents.
>
> *From: *Bruno Decraene <[email-masked]
> <mailto:[email-masked]>>
> *Date: *Monday 11 January 2016 at 17:53
> *To: *Wim Henderickx <[email-masked]
> <mailto:[email-masked]>>
> *Cc: *Martin Horneffer <[email-masked] <mailto:[email-masked]>>,
> "Les Ginsberg (ginsberg)" <[email-masked]
> <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>"
> <[email-masked] <mailto:[email-masked]>>, Stephane Litkowski
> <[email-masked] <mailto:[email-masked]>>
> *Subject: *RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB
> INCONSISTENCY
>
> Hi Wim,
>
> I may be missing some of your points. This thread is about inconsistency
> in the SRGB ranges advertised by _/one/_ node. I’m not sure to see your
> “startup scenario” nor the “merge network scenario”. Could you please
> elaborate?
>
> Thanks,
>
> Bruno
>
> *From:*Henderickx, Wim (Wim) [mailto:[email-masked]]
> *Sent:* Wednesday, January 06, 2016 8:19 PM
> *To:* DECRAENE Bruno IMT/OLN
> *Cc:* Martin Horneffer; Les Ginsberg (ginsberg); [email-masked]
> <mailto:[email-masked]>; 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:
>
>   * 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
> I see this strategy work in some case but in others I see challenges to
> determine what is right and what is wrong, hence my question
>
> *From: *Bruno Decraene <[email-masked]
> <mailto:[email-masked]>>
> *Date: *Wednesday 6 January 2016 at 19:03
> *To: *Wim Henderickx <[email-masked]
> <mailto:[email-masked]>>
> *Cc: *Martin Horneffer <[email-masked] <mailto:[email-masked]>>,
> "Les Ginsberg (ginsberg)" <[email-masked]
> <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>"
> <[email-masked] <mailto:[email-masked]>>, Stephane Litkowski
> <[email-masked] <mailto:[email-masked]>>
> *Subject: *RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB
> INCONSISTENCY
>
> Hi Wim,
>
> *From:*spring [mailto:[email-masked]] *On Behalf Of
> *Henderickx, Wim (Wim)
> *Sent:* Tuesday, January 05, 2016 7:41 PM
> *To:* Martin Horneffer; Les Ginsberg (ginsberg); [email-masked]
> <mailto:[email-masked]>; LITKOWSKI Stephane SCE/OINIS
> *Subject:* Re: [spring] draft-ginsberg-spring-conflict-resolution: SRGB
> INCONSISTENCY
>
> *From: *spring <[email-masked]
> <mailto:[email-masked]>> on behalf of Martin Horneffer
> <[email-masked] <mailto:[email-masked]>>
> *Date: *Tuesday 5 January 2016 at 13:05
> *To: *"Les Ginsberg (ginsberg)" <[email-masked]
> <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>"
> <[email-masked] <mailto:[email-masked]>>, Stephane Litkowski
> <[email-masked] <mailto:[email-masked]>>
> *Subject: *Re: [spring] draft-ginsberg-spring-conflict-resolution: SRGB
> INCONSISTENCY
>
>     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
>     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
>     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:
>
>     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.
>
>     “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
>
>     [email-masked]  <mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/spring
>

---

From: <[email-masked]>
Date: Fri, 15 Jan 2016 08:42:46 +0000

Hi Les,

Looks good to me. Thanks.
And thanks for the discussion.

1 minor point inline below [Bruno3] but I leave this to you.

Bruno

Sent: Thursday, January 14, 2016 9:53 PM

Bruno (and everyone) –

So currently it is not valid to send the sub-TLV with no SRGB Descriptors.

[Bruno3] Agreed. But technically, for SRGB conflict, we are not asking for the sender to _send_ zero SRGB descriptors. We are asking for the receiver to accept _receiving_ zero _valid_ SRGB descriptor. So IMHO we are still no violating the ISIS specification.
That being said, you are raising the point of how the receiver should react when receiving zero SRGB descriptor, which, at least in theory, would also be a valid point to specify.

This text would have to be altered to indicate that the SRGB Descriptors MAY be omitted. This could cause backwards compatibility issues with early deployments as a strict interpretation of the draft would cause such a sub-TLV to be rejected. However, given that local SR-MPLS support only is an unlikely case, I think such a change could be acceptable as there should be sufficient time for all existing implementations to be upgraded before such an exceptional case would need to be deployed (if indeed that is ever required).

   Les

Revised Proposal:

Les,

Bruno -

Les,

Bruno –

<snip>

<end snip>
[Bruno2] 3 points :

   Les

   Les

Les,

Bruno -

Les,

Don -

Hi  Les

[1000, 1099]
[2000, 2099]

[1000, 2099]
[2000, 2099]

--

[Les:] Agreed.

   Les

   Les

Don

Folks –

   Les

Hi Wim

Cheers,
Don

My 2 cents.

Hi Wim,

Thanks,
Bruno

Hi Wim,

Thanks
-- Bruno

happy new year!

Best regards,
Martin

Comments?

   Les

spring mailing list

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Fri, 15 Jan 2016 09:19:33 +0000

Hi Dirk,

From: Dirk Goethals [mailto:[email-masked]]
Sent: Friday, January 15, 2016 10:03 AM

Hi Les, Bruno,

For the record, do we all agree that in case a node is NOT SR-MPLS capable,
for whatever reason, all the SIDs downstream of that node also become unreachable?
Even when there might be a less optimal path around the NOT SR-MPLS capable node.
That’s a very valid question.

If so, can this be stated explicitly in the draft.
My reading is that this is indicated in the architecture document: https://tools.ietf.org/html/draft-ietf-spring-segment-routing-07#section-3.2
   The ingress node of an SR domain validates that the path to a prefix,
   advertised with a given algorithm, includes nodes all supporting the
   advertised algorithm.  In other words, when computing paths for a
   given algorithm, the transit nodes MUST compute the algorithm X on
   the IGP topology, regardless of the support of the algorithm X by the
   nodes in that topology.  As a consequence, if a node on the path does
   not support algorithm X, the IGP-Prefix segment will be interrupted
   and will drop packet on that node.  It's the responsibility of the
   ingress node using a segment to check that all downstream nodes
   support the algorithm of the segment.

The above is related to the routing of SIDs.
This does not preclude a node, computing an explicitly routed path, to take into account SR capability of the nodes in the list of constraints used to compute the path. This point is a local behavior on the ingress.

Thx,
Dirk
Op 15/01/2016 om 2:27 schreef Les Ginsberg (ginsberg):
Uma –

Thanx for the response.
Inline.

To: Les Ginsberg (ginsberg); [email-masked]<mailto:[email-masked]>

Dear Les, Bruno,

Couple of things:

A-----B----C-----D

Hope this helps.

   Les

--
Uma C.

Bruno (and everyone) –

   Les

Revised Proposal:

Les,

Bruno -

Les,

Bruno –

<snip>

<end snip>
[Bruno2] 3 points :

   Les

   Les

Les,

Bruno -

Les,

Don -

Hi  Les

[1000, 1099]
[2000, 2099]

[1000, 2099]
[2000, 2099]

--

[Les:] Agreed.

   Les

   Les

Don

Folks –

   Les

Hi Wim

Cheers,
Don

My 2 cents.

Hi Wim,

Thanks,
Bruno

Hi Wim,

Thanks
-- Bruno

happy new year!

Best regards,
Martin

Comments?

   Les

spring mailing list

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

spring mailing list

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 15 Jan 2016 16:24:01 +0000

Bruno –

Happy to see we have an agreement.
Inline.

Sent: Friday, January 15, 2016 12:43 AM

Hi Les,

Bruno

Bruno (and everyone) –

[Les:] You are correct. But since we are allowing that it is valid to support local SIDs only, then it is necessary to modify the IS-IS draft so that NOT sending any SRGB ranges is permitted. That said, I expect that it will be unlikely that anyone will need to deploy SR in this way.

   Les

   Les

Revised Proposal:

Les,

Bruno -

Les,

Bruno –

<snip>

<end snip>
[Bruno2] 3 points :

   Les

   Les

Les,

Bruno -

Les,

Don -

Hi  Les

[1000, 1099]
[2000, 2099]

[1000, 2099]
[2000, 2099]

--

[Les:] Agreed.

   Les

   Les

Don

Folks –

   Les

Hi Wim

Cheers,
Don

My 2 cents.

Hi Wim,

Thanks,
Bruno

Hi Wim,

Thanks
-- Bruno

happy new year!

Best regards,
Martin

Comments?

   Les

spring mailing list

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

---

From: Uma Chunduri <[email-masked]>
Date: Fri, 15 Jan 2016 18:12:39 +0000

Les,

Thanks. My quick response below [Uma2]:

--
Uma C.

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Thursday, January 14, 2016 5:28 PM
To: Uma Chunduri; [email-masked]
Cc: [email-masked]; Henderickx, Wim (Wim)
Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB INCONSISTENCY

Uma –

Thanx for the response.
Inline.

Dear Les, Bruno,

Couple of things:

A-----B----C-----D

[Uma2]: Precisely and I initially expected only node C, which eventually uses   node D’s SRGB recognizes the conflicts in SRGB and consider D is ”NOT SR-MPLS” capable. But the above statement doesn’t reflect this:
“Receivers of an invalid SRGB MUST ignore the SRGB” ==> here D’s SRGB is received by all nodes and for this example at node A; per this statement it would ignore these SRGB’s during decision process and w.r.t “sending node as NOT SR-MPLS capable for globally scoped SIDs.”  Should not consider any global SIDs, because the advertised global SIDs are not trustworthy any more based on the earlier discussions on this thread.
Perhaps as per your response above, you might want to say the “neighboring upstream receivers should not use these invalid SRGB ranges MUST ignore the…”.

Evidently, the difference here is to abandon the node which is sending “corrupted SRGBs” (as now its mandatory to have sending side checks)  as an SR-MPLS node for global SIDs by entire  network or only upstream neighbors which could be installs the labels in the forwarding with these “corrupted SRGBs”. I prefer modified language to reflect the intent correctly.

Hope this helps.

   Les

--
Uma C.

Bruno (and everyone) –

   Les

Revised Proposal:

Les,

Bruno -

Les,

Bruno –

<snip>

<end snip>
[Bruno2] 3 points :

   Les

   Les

Les,

Bruno -

Les,

Don -

Hi  Les

[1000, 1099]
[2000, 2099]

[1000, 2099]
[2000, 2099]

--

[Les:] Agreed.

   Les

   Les

Don

Folks –

   Les

Hi Wim

Cheers,
Don

My 2 cents.

Hi Wim,

Thanks,
Bruno

Hi Wim,

Thanks
-- Bruno

happy new year!

Best regards,
Martin

Comments?

   Les

spring mailing list

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 15 Jan 2016 20:21:34 +0000

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.

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.

While I will do my best to make the language in the draft clear and unambiguous, I am frankly at a loss to understand how you concluded that the SRGB related statement says anything whatsoever about SID advertisements.

   Les

Sent: Friday, January 15, 2016 10:13 AM

Les,

--
Uma C.

To: Uma Chunduri; [email-masked]<mailto:[email-masked]>

Uma –

Thanx for the response.
Inline.

Dear Les, Bruno,

Couple of things:

A-----B----C-----D

Hope this helps.

   Les

--
Uma C.

Bruno (and everyone) –

   Les

Revised Proposal:

Les,

Bruno -

Les,

Bruno –

<snip>

<end snip>
[Bruno2] 3 points :

   Les

   Les

Les,

Bruno -

Les,

Don -

Hi  Les

[1000, 1099]
[2000, 2099]

[1000, 2099]
[2000, 2099]

--

[Les:] Agreed.

   Les

   Les

Don

Folks –

   Les

Hi Wim

Cheers,
Don

My 2 cents.

Hi Wim,

Thanks,
Bruno

Hi Wim,

Thanks
-- Bruno

happy new year!

Best regards,
Martin

Comments?

   Les

spring mailing list

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

---

From: Uma Chunduri <[email-masked]>
Date: Fri, 15 Jan 2016 23:56:15 +0000

Les,

In-line [Uma]:

--
Uma C.

Sent: Friday, January 15, 2016 12:22 PM

Uma –

into

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

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

Les,

--
Uma C.

Uma –

Thanx for the response.
Inline.

Dear Les, Bruno,

Couple of things:

A-----B----C-----D

Hope this helps.

   Les

--
Uma C.

Bruno (and everyone) –

   Les

Revised Proposal:

Les,

Bruno -

Les,

Bruno –

<snip>

<end snip>
[Bruno2] 3 points :

   Les

   Les

Les,

Bruno -

Les,

Don -

Hi  Les

[1000, 1099]
[2000, 2099]

[1000, 2099]
[2000, 2099]

--

[Les:] Agreed.

   Les

   Les

Don

Folks –

   Les

Hi Wim

Cheers,
Don

My 2 cents.

Hi Wim,

Thanks,
Bruno

Hi Wim,

Thanks
-- Bruno

happy new year!

Best regards,
Martin

Comments?

   Les

spring mailing list

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sat, 16 Jan 2016 00:13:06 +0000

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

   Les

Sent: Friday, January 15, 2016 3:56 PM

Les,

In-line [Uma]:

--
Uma C.

Uma –

into

[Uma]: thx!

   Les

Les,

--
Uma C.

Uma –

Thanx for the response.
Inline.

Dear Les, Bruno,

Couple of things:

A-----B----C-----D

Hope this helps.

   Les

--
Uma C.

Bruno (and everyone) –

   Les

Revised Proposal:

Les,

Bruno -

Les,

Bruno –

<snip>

<end snip>
[Bruno2] 3 points :

   Les

   Les

Les,

Bruno -

Les,

Don -

Hi  Les

[1000, 1099]
[2000, 2099]

[1000, 2099]
[2000, 2099]

--

[Les:] Agreed.

   Les

   Les

Don

Folks –

   Les

Hi Wim

Cheers,
Don

My 2 cents.

Hi Wim,

Thanks,
Bruno

Hi Wim,

Thanks
-- Bruno

happy new year!

Best regards,
Martin

Comments?

   Les

spring mailing list

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Mon, 18 Jan 2016 09:00:58 +0000

Hi Les, all,

As a side note, I’m wondering whether we want to spell out the behavior for a specific case: the global SID advertised (originated) by the node advertising the conflicting SIDs.

If this SID is advertised with the P-Flag cleared or the E-Flag set, then the neighbor MUST NOT use the SRGB but MUST either pop the prefix (PHP) or swap it with Explicit-Null.
I would not a priori assume that we are all in sync ;-) so mentioning this case might be useful, because the ingress pushing the SID needs to know.
Now, there is a priori 2 options:

a)      Valid

b)      Invalid

In theory, there is no reason to consider it invalid as the invalid SRGB is not used.
From an implementation standpoint, this may be very implementation specific. Some implementation may not look for the SRGB (has it’s not needed) and hence not detect that the SRGB is invalid/void. Some implementation may do the check.
For a usage perspective, keeping the SID (N) as the following benefit:
- BGP routes using this SID N as Next-Hop including VPNs are not be affected
- If an ingress want to use that node in transit to reach SID D, it needs to push fewer labels (“SID N, adj_label, SID D” versus “SID penultimate for N, adj_label toward N, ,adj_label, SID D”)

--Bruno

Sent: Friday, January 15, 2016 5:24 PM

Bruno –

Hi Les,

Bruno

Bruno (and everyone) –

   Les

   Les

Revised Proposal:

Les,

Bruno -

Les,

Bruno –

<snip>

<end snip>
[Bruno2] 3 points :

   Les

   Les

Les,

Bruno -

Les,

Don -

Hi  Les

[1000, 1099]
[2000, 2099]

[1000, 2099]
[2000, 2099]

--

[Les:] Agreed.

   Les

   Les

Don

Folks –

   Les

Hi Wim

Cheers,
Don

My 2 cents.

Hi Wim,

Thanks,
Bruno

Hi Wim,

Thanks
-- Bruno

happy new year!

Best regards,
Martin

Comments?

   Les

spring mailing list

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

---

From: Uma Chunduri <[email-masked]>
Date: Mon, 18 Jan 2016 21:04:19 +0000

Les,

Just want to make sure folks interpret the intent correctly and  don’t question as node is sending corrupted SRGB, and should be treated
as  “NOT SR-MPLS” capable - why should we use its global SIDs.
I have mixed response in my team for the proposed statement.  But I would leave it here and looking forward for the update in the draft.

Thx!
--
Uma C.

Sent: Friday, January 15, 2016 4:13 PM

Uma –

   Les

Les,

In-line [Uma]:

--
Uma C.

Uma –

into

[Uma]: thx!

   Les

Les,

--
Uma C.

Uma –

Thanx for the response.
Inline.

Dear Les, Bruno,

Couple of things:

A-----B----C-----D

Hope this helps.

   Les

--
Uma C.

Bruno (and everyone) –

   Les

Revised Proposal:

Les,

Bruno -

Les,

Bruno –

<snip>

<end snip>
[Bruno2] 3 points :

   Les

   Les

Les,

Bruno -

Les,

Don -

Hi  Les

[1000, 1099]
[2000, 2099]

[1000, 2099]
[2000, 2099]

--

[Les:] Agreed.

   Les

   Les

Don

Folks –

   Les

Hi Wim

Cheers,
Don

My 2 cents.

Hi Wim,

Thanks,
Bruno

Hi Wim,

Thanks
-- Bruno

happy new year!

Best regards,
Martin

Comments?

   Les

spring mailing list

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

---

From: Uma Chunduri <[email-masked]>
Date: Mon, 18 Jan 2016 21:09:05 +0000

Hi Bruno,

Yes, in this case (PHP/E-Flag) even the adjacent node need not use the corrupted SRGB and should install the  global SIDs (similar to remote nodes) as agreed by Les.

Perhaps, what we are seeking is not to use corrupted SRGB of the node in all cases but use node’s global SIDs.

--
Uma C.

From: spring [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, January 18, 2016 1:01 AM
To: Les Ginsberg (ginsberg); [email-masked]
Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution: SRGB INCONSISTENCY

Hi Les, all,

a)      Valid

b)      Invalid

--Bruno

Bruno –

Hi Les,

Bruno

Bruno (and everyone) –

   Les

   Les

Revised Proposal:

Les,

Bruno -

Les,

Bruno –

<snip>

<end snip>
[Bruno2] 3 points :

   Les

   Les

Les,

Bruno -

Les,

Don -

Hi  Les

[1000, 1099]
[2000, 2099]

[1000, 2099]
[2000, 2099]

--

[Les:] Agreed.

   Les

   Les

Don

Folks –

   Les

Hi Wim

Cheers,
Don

My 2 cents.

Hi Wim,

Thanks,
Bruno

Hi Wim,

Thanks
-- Bruno

happy new year!

Best regards,
Martin

Comments?

   Les

spring mailing list

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Tue, 19 Jan 2016 08:46:52 +0000

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:[email-masked]] On Behalf Of Les Ginsberg (ginsberg)
Sent: Saturday, January 16, 2016 01:13
To: Uma Chunduri; DECRAENE Bruno IMT/OLN
Cc: [email-masked]; Henderickx, Wim (Wim)
Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution: SRGB INCONSISTENCY

Uma –

   Les

Les,

In-line [Uma]:

--
Uma C.

Uma –

into

[Uma]: thx!

   Les

Les,

--
Uma C.

Uma –

Thanx for the response.
Inline.

Dear Les, Bruno,

Couple of things:

A-----B----C-----D

Hope this helps.

   Les

--
Uma C.

Bruno (and everyone) –

   Les

Revised Proposal:

Les,

Bruno -

Les,

Bruno –

<snip>

<end snip>
[Bruno2] 3 points :

   Les

   Les

Les,

Bruno -

Les,

Don -

Hi  Les

[1000, 1099]
[2000, 2099]

[1000, 2099]
[2000, 2099]

--

[Les:] Agreed.

   Les

   Les

Don

Folks –

   Les

Hi Wim

Cheers,
Don

My 2 cents.

Hi Wim,

Thanks,
Bruno

Hi Wim,

Thanks
-- Bruno

happy new year!

Best regards,
Martin

Comments?

   Les

spring mailing list

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Wed, 20 Jan 2016 13:52:07 +0000

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, [email-masked] wrote:
> 
> Hi Les,
>  
> Please hit the “reset button” and try looking at this with a fresh perspective. J
>  
>    Les
>  
>  
> [Uma]:  …and also the upstream neighboring node to compute and install the outgoing label J.
>  
> “Receivers of an invalid SRGB MUST ignore the SRGB” è here D’s SRGB is received by all nodes and for this example at node A; per this statement it would ignore these SRGB’s during decision process and w.r.t “sending node as NOT SR-MPLS capable for globally scoped SIDs.”  Should not consider any global SIDs, because the advertised global SIDs are not trustworthy any more based on the earlier discussions on this thread.
> Assuming that the IS-IS draft authors and the WG are willing to make the appropriate change in the IS-IS draft then I provide a revised definition of how to handle an invalid SRGB below. I ask all the folks who have already indicated their approval/disapproval of the previous proposal to review the revised proposal and indicate their opinion. Of course I also want to encourage folks who have not yet voiced their opinion to respond as well. J
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 20 Jan 2016 14:03:59 +0000

Stefano -

Thanx for the proposal - it makes sense to me. 

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

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

   Les

> -----Original Message-----
> From: Stefano Previdi (sprevidi)
> Sent: Wednesday, January 20, 2016 5:52 AM
> To: Stephane Litkowski; Les Ginsberg (ginsberg)
> Cc: Uma Chunduri; [email-masked]; [email-masked];
> Henderickx, Wim (Wim)
> 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.
> 
> 
> > 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.
> > 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
> >
> >
> > 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.
> >
> > Receivers of an invalid SRGB MUST ignore the SRGB and treat the sending
> node as NOT SR-MPLS capable for globally scoped SIDs.
> >
> > into
> >
> > 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.
> > 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
> > 1.       Les, I support advertising explicit SR capability of the node; meaning
> this doesn’t have  to be tied to one or more SRGB range advertisements.
> > Though for example, OSPF draft doesn’t say anything about ‘no srgb
> ranges’ in SID/Label Range TLV, my vote is to be explicit about it.
> > [Les:] IN the case of OSPFv2 there is a separate TLV for advertising
> algorithm support. This can be used to infer SR-MPLS support for local labels
> for IPv4. There is no language in the OSPFv2 draft which requires SRGB to be
> sent.
> > In the case of OSPFv3, SR Forwarding Capabilities are advertised in the
> OSPF Router Informational Capabilities TLV. Again there is no requirement to
> advertise SRGB – so the forwarding capabilities info can be used to infer
> support for SR-MPLS local SID support.
> >
> > 2.       Revised proposal below is good and I agree on -  there is no
> dependency of SRGB for locally scoped ADJ side it should not be effected
> because of incorrect SRGB.
> > -          I would say making this change to remove support for local ADJ sids
> because of incorrect received SRGB for anode is a bigger change for us (E///)
> at least.
> >
> > >2)Receivers of an invalid SRGB MUST ignore the SRGB and treat the
> sending node as NOT SR-MPLS capable for globally scoped SIDs.
> >
> > A-----B----C-----D
> >
> > Consider the above network – if you are node A and you are dealing with a
> “conflicting range from node D” but valid ranges from node B – you are
> saying drop  all prefixes with global SIDs.
> >
> > [Les:] No – no such statement is made. The statement is “treat the sending
> node as NOT SR-MPLS capable for globally scoped SIDs.”. The sending node
> in your example is “D”. No changes are made as regards SR-MPLS support for
> A, B, C. This in fact is not much different than what you MUST do today even
> with a valid SRGB – because you have to check whether the given SID is
> within the (set of) SRGB range(s) advertised by your nexthop. If your
> nexthop is D then in this example no global SID will map to a valid label in D’s
> forwarding plane – so C MUST NOT install an outgoing label when forwarding
> traffic via D.
> >
> > [Uma2]: Precisely and I initially expected only node C, which eventually
> uses   node D’s SRGB recognizes the conflicts in SRGB and consider D is ”NOT
> SR-MPLS” capable. But the above statement doesn’t reflect this:
> > “Receivers of an invalid SRGB MUST ignore the SRGB” è here D’s SRGB is
> received by all nodes and for this example at node A; per this statement it
> would ignore these SRGB’s during decision process and w.r.t “sending node
> as NOT SR-MPLS capable for globally scoped SIDs.”  Should not consider any
> global SIDs, because the advertised global SIDs are not trustworthy any more
> based on the earlier discussions on this thread.
> > Perhaps as per your response above, you might want to say the
> “neighboring upstream receivers should not use these invalid SRGB ranges
> MUST ignore the…”.
> >
> > Evidently, the difference here is to abandon the node which is sending
> “corrupted SRGBs” (as now its mandatory to have sending side checks)  as an
> SR-MPLS node for global SIDs by entire  network or only upstream neighbors
> which could be installs the labels in the forwarding with these “corrupted
> SRGBs”. I prefer modified language to reflect the intent correctly.
> >
> > Hope this helps.
> >
> >    Les
> >
> >
> > But, I see you are asking this even though outgoing label is completely
> governed by node B (which is advertising valid ranges) in this case.  Though
> this  is a bigger change  and ideally should be applicable to only C , it  is  ok to
> me given the consensus on when senders MUST advertise (non-conflicting
> ranges) and  still conflicting range is seen.
> >
> > Most of the checks whatever possible for SRGBs, mapping server SID range
> conflicts etc. must be prevented locally and this should be  mandated
> (individual protocol/architecture/conflict document) somewhere. However
> mapping server SID ranges is a completely different beast and can be
> discussed some other day on how a receiver should handle the conflicts
> there.
> >
> > --
> > Uma C.
> >
> >
> considered SR-MPLS incapable for both local and global SIDs or whether we
> should only consider the node MPLS-SR incapable for Global SIDs. The latter
> proposal has some merit because SRGB is only used in support of global SIDs.
> However, in order to do this we must insure that all the protocol drafts are
> consistent with this concept i.e. that SR-MPLS support has two scopes and
> that the conditions necessary for supporting each of the two scopes are not
> identical.
> >
> > Here there is an issue. Section 3.1 specifies the contents of the SR-
> Capabilities Sub-TLV which includes advertisement of both the SR-MPLS
> This text would have to be altered to indicate that the SRGB Descriptors MAY
> be omitted. This could cause backwards compatibility issues with early
> deployments as a strict interpretation of the draft would cause such a sub-
> TLV to be rejected. However, given that local SR-MPLS support only is an
> unlikely case, I think such a change could be acceptable as there should be
> sufficient time for all existing implementations to be upgraded before such
> an exceptional case would need to be deployed (if indeed that is ever
> required).
> >
> > Assuming that the IS-IS draft authors and the WG are willing to make
> > the appropriate change in the IS-IS draft then I provide a revised
> requirement of NOT advertising overlapping SRGB ranges is totally within the
> control of the local node. Misconfigurations can and MUST be detected
> BEFORE they are advertised.
> >
> > 2)Receivers of an invalid SRGB MUST ignore the SRGB and treat the sending
> node as NOT SR-MPLS capable for globally scoped SIDs.
> >
> > 3)Support for locally scoped SIDs is unaffected by the
> presence/absence/validity of SRGB advertisements.
> >
> >
> 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.
> >
> > 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
> advertisements (prefix-SIDs, ADJ-SIDs). You are proposing that this logic be
> enhanced to treat the case where the node has sent an invalid SRGB as if the
> node is still SR-MPLS capable but for local SIDs only. I don’t deny this could be
> done – I just don’t understand why.
> >
> > <end snip>
> > [Bruno2] 3 points :
> > a) Safety/validity: I’m still reading no argument saying that « Drop All” is less
> safe than “SR Incapable”. Can we agree on this?
> certainly have use cases. Are you arguing this? If not, “Drop All” has the
> benefit of not dropping the traffic crossing that node using Local/Adjacency
> segments.  More on this next few lines.
> > c) Implementation complexity: 1) this is difficult to measure hence agree
> on. If your implementation were open source, we could probably discuss it
> more easily. 2)This may be implementation specific. 3) We have already
> discussed this
> https://mailarchive.ietf.org/arch/msg/spring/nAoOL8tCF4qXHYK7c2dIu3Xd47
> A  In short, before using a global SID, existing implementations must also
> check that this global SID falls within the SRGB. Hence dropping all the SRGB
> ranges would already be identified by implementation with no changes.
> >
> > In subsequent comments no one has indicated that there is such a use
> case. In the interest of simplicity I am therefore in favor of the “NOT SR-MPLS
> capable” approach.
> > [Bruno2]
> https://mailarchive.ietf.org/arch/msg/spring/FuMaSOnwO3WvtmMWT9SzV
> 8jbT
> > pE
> > - In the context of this discussion, one router implementation/controller
> would still be able to cross/use the node advertising conflicting SRGB ranges
> by using a local adjacency segment. You may not want to implement this use
> case, but I don’t see a reason to forbid this.
> because there were use cases.
> >
> making the problem worse and are based upon assumptions which cannot
> be verified.
> traffic. In theory, relative probability of occurrence would also need to be
> taken into account.
> > 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
> 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
> >
> 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.
> 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
> >
> >
> 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.
> >
> > 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]
> >
> > 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.
> >
> point.. But I don’t think it’s about « reasonable” or “likely”. In my view, it’s
> about trusting (or not) a received data which is correct from both a syntax
> and semantic perspective.
> > And if we don’t believe in data which looks like correct from both a syntax
> and semantic perspective, we should stop using protocols.
> >
> > Drop the conflicting one, Merge, Merge and re-order _do_ require a new
> > 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
> >
> > 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
> >
> > 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.
> >
> > 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.
> >
> winners and losers (not right and wrong J ).
> >
> > Cheers,
> > Don
> >
> 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.
> >
> > Cc: Martin Horneffer <[email-masked]>, "Les Ginsberg (ginsberg)"
> > <[email-masked]>, "[email-masked]" <[email-masked]>, Stephane
> > Litkowski <[email-masked]>
> > 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
> > 	• If you are in a running network and you add a new node or have a
> > 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
> >
> > Cc: Martin Horneffer <[email-masked]>, "Les Ginsberg (ginsberg)"
> > <[email-masked]>, "[email-masked]" <[email-masked]>, Stephane
> > Litkowski <[email-masked]>
> > To: "Les Ginsberg (ginsberg)" <[email-masked]>, "[email-masked]"
> > <[email-masked]>, Stephane Litkowski <[email-masked]>
> > 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.
> >
> >  - 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
> >
> >
> > 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.
> >
> > 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://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:
> >
> > 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.
> >
> > “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
> pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> > This message and its attachments may contain confidential or
> > privileged information that may be protected by law; they should not be
> distributed, used or copied without authorisation.
> __________________________________________________________
> ____________
> > ___________________________________________________
> >
> > Ce message et ses pieces jointes peuvent contenir des informations
> > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
> > exploites ou copies sans autorisation. Si vous avez recu ce message
> > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les
> pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> > This message and its attachments may contain confidential or
> > privileged information that may be protected by law; they should not be
> distributed, used or copied without authorisation.
> __________________________________________________________
> ____________
> > ___________________________________________________
> >
> > Ce message et ses pieces jointes peuvent contenir des informations
> > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
> > exploites ou copies sans autorisation. Si vous avez recu ce message
> > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les
> pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> > This message and its attachments may contain confidential or
> > privileged information that may be protected by law; they should not be
> distributed, used or copied without authorisation.
> __________________________________________________________
> ____________
> > ___________________________________________________
> >
> > Ce message et ses pieces jointes peuvent contenir des informations
> > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
> > exploites ou copies sans autorisation. Si vous avez recu ce message
> > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les
> pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> > This message and its attachments may contain confidential or
> > privileged information that may be protected by law; they should not be
> distributed, used or copied without authorisation.
> __________________________________________________________
> ____________
> > ___________________________________________________
> >
> > Ce message et ses pieces jointes peuvent contenir des informations
> > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
> > exploites ou copies sans autorisation. Si vous avez recu ce message
> > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les
> pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> > This message and its attachments may contain confidential or
> > privileged information that may be protected by law; they should not be
> distributed, used or copied without authorisation.
> __________________________________________________________
> ____________
> > ___________________________________________________
> >
> > Ce message et ses pieces jointes peuvent contenir des informations
> > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
> > exploites ou copies sans autorisation. Si vous avez recu ce message
> > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les
> pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> > This message and its attachments may contain confidential or
> > privileged information that may be protected by law; they should not be
> distributed, used or copied without authorisation.
> __________________________________________________________
> ____________
> > ___________________________________________________
> >
> > Ce message et ses pieces jointes peuvent contenir des informations
> > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
> > exploites ou copies sans autorisation. Si vous avez recu ce message
> > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les
> pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> > This message and its attachments may contain confidential or
> > privileged information that may be protected by law; they should not be
> distributed, used or copied without authorisation.