Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution: Updating other drafts

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

(Changed the subject a bit)

Here is my proposal as regards the need to update other SR related drafts regarding handling invalid SRGBs.

1)No need for any change to SR architecture draft.

2) What is already in https://www.ietf.org/id/draft-ietf-isis-segment-routing-extensions-06.txt
Section 3.1

"The originating router MUST NOT advertise overlapping ranges.

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

We need to add equivalent language to:

https://www.ietf.org/id/draft-ietf-ospf-ospfv3-segment-routing-extensions-04.txt
Section 3.2

and

https://www.ietf.org/id/draft-ietf-ospf-segment-routing-extensions-06.txt
Section 3.2

This makes the conflict resolution draft the authoritative document and no additional changes to other SR documents will be needed in the future no matter what changes occur in the conflict resolution draft.

   Les

From: spring [mailto:[email-masked]] On Behalf Of Les Ginsberg (ginsberg)
Sent: Wednesday, January 06, 2016 9:22 PM
To: [email-masked]; LITKOWSKI Stephane SCE/OINIS
Cc: [email-masked]
Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution: SRGB INCONSISTENCY

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>

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

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

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

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

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

</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]<mailto:[email-masked]>
Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB INCONSISTENCY

Stephane -

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Tuesday, January 05, 2016 12:45 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,

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 -

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

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

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

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

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

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

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

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

[Les:] An interesting point. What I am after here is recognition that without a valid SRGB the indication from a node that it is capable of "processing SR MPLS encapsulated IPv4/IPv6 packets on all interfaces" does 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???
[SLI] I'm was not suggesting to use only Adj-SID ... as I also do not see a real use case for that. I'm just saying that the specification does not prevent it. So may be let's prevent it ...so we can update the architecture document saying that advertising a valid SRGB is a must. There is something wrong to me here, because we will state that a node with invalid SRGB will be treated as non SR capable while the architecture does not forbid to not have a SRGB and does not say anything on how the architecture works with no SRGB (we can only guess that only Adj-SID can be used).

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

    Les

   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

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

The draft defines one possible solution -from Section 2:

" Each range is examined in the order it was advertised.  If it does

   not overlap with any advertised range which preceded it the

   advertised range is used.  If the range overlaps with any preceding

   range it MUST NOT be used and all ranges advertised after the first

   encountered overlapping range also MUST NOT be used."

This is one instance of a class of solutions which attempt to make use of part of the advertisements even when there is some inconsistency (overlap) in the set of SRGB ranges received. A more complete discussion of this class of solutions can be seen in https://mailarchive.ietf.org/arch/attach/spring/txtk0n56G.txt - many thanx to Bruno for writing this.

However, there is an alternative solution which was suggested (notably by Acee Lindem) after the draft was written. This alternative is to ignore the entire set of SRGB advertisements and treat the problematic router as if it were not SR MPLS capable. This alternative was discussed during the presentation in SPRING WG at IETF94 (see https://www.ietf.org/proceedings/94/slides/slides-94-spring-2.pdf slide #3<https://www.ietf.org/proceedings/94/slides/slides-94-spring-2.pdf%20slide%20#3>).  It is also discussed in Bruno's post (https://mailarchive.ietf.org/arch/attach/spring/txtk0n56G.txt - see Section 2.2).

The basis of the alternative solution is that a correct implementation should never allow inconsistent SRGB ranges to be successfully configured (let alone advertised). So this is not a case of a misconfiguration - it is a case of a defective implementation. It  then seems appropriate to put the onus on the originating router to only send valid SRGB advertisements rather than forcing all the receivers to try to "correct" the invalid information in some consistent way. This has a number of advantages:

1.       It is by far the simplest to implement

2.       It isolates the router which is untrustworthy

3.       As the problem can only occur as a result of a defective implementation the behavior of the originating router is unpredictable - it is therefore safer not to use the information

It is worth noting that since the invalid advertisement is the result of some sort of defect in the originating router's implementation, it is not safe to assume that the source will actually be using the advertised SRGB in a manner consistent with the selective choice made by the receiving routers.

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

"The set of received ranges is examined . If there is overlap between any two of the advertised ranges the entire SRGB set is considered invalid and is ignored.

The originating router is considered to be incapable of supporting the SR-MPLS forwarding plane. Routers which receive an SRGB advertisement with overlapping ranges SHOULD report the occurrence."

Comments?

   Les

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.

---

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

Hi Les,

BGP needs also to be taken into account : draft-ietf-idr-bgp-prefix-sid.

IMO, as I already pointed,  it would be easier to handle it a single document rather than in the protocol docs. Moreover we will have the sender part in many docs, and the receiver part in the spring-conflict-resolution draft.

Best Regards,

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Wednesday, January 13, 2016 17:50
To: DECRAENE Bruno IMT/OLN; LITKOWSKI Stephane SCE/OINIS
Cc: [email-masked]
Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: Updating other drafts

and

   Les

From: spring [mailto:[email-masked]] On Behalf Of Les Ginsberg (ginsberg)
Sent: Wednesday, January 06, 2016 9:22 PM
To: [email-masked]<mailto:[email-masked]>; LITKOWSKI Stephane SCE/OINIS
Cc: [email-masked]<mailto:[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: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 14 Jan 2016 09:20:30 +0000

Stephane -

From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, January 14, 2016 12:27 AM
To: Les Ginsberg (ginsberg); DECRAENE Bruno IMT/OLN
Cc: [email-masked]
Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: Updating other drafts

Hi Les,

[Les:] Perhaps. The BGP draft contains a reference to the OSPF draft as regards SRGB (see Section 4.3) - this might suffice -  but in principle I agree with you that we need to ensure that all protocols reference the common conflict resolution document. The authors of the BGP draft should indicate what language they believe is needed there.

[Les:] Just to be sure I understand you, you are advocating putting the SRGB sender behavior specification in draft-ginsberg-spring-conflict-resolution as well as the receiver behavior?
Sender behavior HAS to be specified in the protocol documents as it describes the normative behavior of the protocols. Inclusion of the sender behavior in draft-ginsberg-spring-conflict-resolution would then be redundant. I generally resist this because I think one of two things can happen:

1)The text is - either due to different wording or different context - subject to a different interpretation.
2)The text is entirely redundant

I am open to adding the (redundant) sender text - but I would prefer not to do so.

   Les

Best Regards,

and

   Les

   Les

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.

Thank you.

---

From: <[email-masked]>
Date: Thu, 14 Jan 2016 10:45:43 +0000

[Les:] Just to be sure I understand you, you are advocating putting the SRGB sender behavior specification in draft-ginsberg-spring-conflict-resolution as well as the receiver behavior?
Sender behavior HAS to be specified in the protocol documents as it describes the normative behavior of the protocols.

[SLI] Well that's a point of view, but in this case the receiver side has also to be in the protocols. All depends of the responsibility : is it a protocol related responsibility or not or a more global architectural requirement that all the protocols will need defacto to fill.

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Thursday, January 14, 2016 10:21
To: LITKOWSKI Stephane SCE/OINIS; DECRAENE Bruno IMT/OLN
Cc: [email-masked]
Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: Updating other drafts

Stephane -

Hi Les,

Inclusion of the sender behavior in draft-ginsberg-spring-conflict-resolution would then be redundant. I generally resist this because I think one of two things can happen:

   Les

Best Regards,

and

   Les

   Les

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.

Thank you.

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Thu, 14 Jan 2016 16:08:11 +0000

Hi Stephane,

to me it’s perfectly fine to have the sender behavior described in the protocol because this is the critical part of the whole game. 

If all implementations behave properly at the sender side, you won’t have any problem at the receiver side.

Also, the protocol-specific draft is the reference document for any implementor so it’s important to find all the necessary information so that routing updates are formatted properly.

Now, the receiver-side can be more complex because the receiver behavior may involve more than just one protocol. We will come to this when we will discuss SID allocation conflicts among protocols. Therefore, the receiver behavior must be described into a protocol-agnostic document.

s.

> On Jan 14, 2016, at 11:45 AM, [email-masked] wrote:
> 
> [SLI] Well that’s a point of view, but in this case the receiver side has also to be in the protocols. All depends of the responsibility : is it a protocol related responsibility or not or a more global architectural requirement that all the protocols will need defacto to fill. 
>  
>  
> 1)The text is – either due to different wording or different context – subject to a different interpretation.
> I am open to adding the (redundant) sender text – but I would prefer not to do so.
>  
>    Les
>  
>  
> Best Regards,
>  
> “The originating router MUST NOT advertise overlapping ranges.
>  
>    [I-D.ginsberg-spring-conflict-resolution].”
>  
> Bruno (AKA Mr. co-chair J) –
>  
> 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
>  
>  
> [SLI] I’m was not suggesting to use only Adj-SID … as I also do not see a real use case for that. I’m just saying that the specification does not prevent it. So may be let’s prevent it …so we can update the architecture document saying that advertising a valid SRGB is a must. There is something wrong to me here, because we will state that a node with invalid SRGB will be treated as non SR capable while the architecture does not forbid to not have a SRGB and does not say anything on how the architecture works with no SRGB (we can only guess that only Adj-SID can be used).
>  
>  
> [Les2:] OK good – I think we agree on this point also. What is needed is to ensure that there is appropriate language in the SR architecture draft and/or the protocol drafts to specify how receiving an invalid SRGB affects the interpretation of “SR-MPLS capability”. 
>  
> To: LITKOWSKI Stephane SCE/OINIS; DECRAENE Bruno IMT/OLN; [email-masked]
> To: Les Ginsberg (ginsberg); DECRAENE Bruno IMT/OLN; [email-masked]
> To: LITKOWSKI Stephane SCE/OINIS; DECRAENE Bruno IMT/OLN; [email-masked]
> To: Les Ginsberg (ginsberg); DECRAENE Bruno IMT/OLN; [email-masked]
> [Les:] And to you…
> [Les:] Hmmm…IS-IS draft (for example) already states (Section 3.1):
>  
> <snip>
> Isn’t this sufficient?
> The issue with putting this text in the protocol doc, is that you need to ensure that all protocols will always have this restriction. It’s not really a protocol thing, more a configuration management one …
>  
> [Les2:] If your concern is to make sure that all the protocol documents provide equivalent language – I agree this should be done and we will do the diligence necessary to make sure that text is included in all the places needed. My comment was that adding such a statement in this specification is really out of place. The right place to state the requirement is in the sender specification. I think we agree on this.
>  
> Now regarding the sentence :” The originating router is considered to be incapable of supporting the SR-MPLS forwarding plane”. Do we have something in the architecture document saying that advertising a SRGB is mandatory to use SR ? Pure theorical example : what if someone wants only to use Adj-SIDs in SR network ? there is no need to advertise a SRGB. Stating that the node must be considered as non SR capable is strong, it will also prevent the usage of Adj-SID which will work well without SRGB. If we consider that having a SRGB is mandatory, we need to have this requirement in the architecture document.
>  
> [Les:] An interesting point. What I am after here is recognition that without a valid SRGB the indication from a node that it is capable of “processing SR MPLS encapsulated IPv4/IPv6 packets on all interfaces” does not apply. 
> You are suggesting that a node which is not capable of supporting SR-MPLS dataplane for prefix-SIDs should still be allowed to support ADJ-SIDs – although it would have to be restricted to local SIDs  (ADJ-SIDs can be assigned from the global SID space - just not the most common usage). While you may be right in that such a practice is not explicitly forbidden by any of the specifications, I am struggling to find a real world use case.
>  
> Doing so certainly complicates implementations. Implementations today verify whether a node supports SR-MPLS before using SR-MPLS advertisements (prefix-SIDs, ADJ-SIDs). You are proposing that this logic be enhanced to treat the case where the node has sent an invalid SRGB as if the node is still SR-MPLS capable but for local SIDs only. I don’t deny this could be done – I just don’t understand why.
>  
> [SLI] I’m was not suggesting to use only Adj-SID … as I also do not see a real use case for that. I’m just saying that the specification does not prevent it. So may be let’s prevent it …so we can update the architecture document saying that advertising a valid SRGB is a must. There is something wrong to me here, because we will state that a node with invalid SRGB will be treated as non SR capable while the architecture does not forbid to not have a SRGB and does not say anything on how the architecture works with no SRGB (we can only guess that only Adj-SID can be used).
>  
>  
> [Les2:] OK good – I think we agree on this point also. What is needed is to ensure that there is appropriate language in the SR architecture draft and/or the protocol drafts to specify how receiving an invalid SRGB affects the interpretation of “SR-MPLS capability”. I will take an action item to follow up on that with the various draft authors.
>  
>     Les
>  
>  
>  
>    Les
>  
>  
> Best regards,
>  
> Stephane
>  
>  
> To: DECRAENE Bruno IMT/OLN; [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).
>  
> 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
>  
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring

---

From: <[email-masked]>
Date: Thu, 14 Jan 2016 17:12:42 +0000

Hi Stefano,

My worry is that tomorrow we will have a new protocol, and this KEY piece may be forgotten because nothing tells that this is required... and this is a cross protocol behavior that we want.
I'm fine to have it in the protocol as far as we have a more global document telling that all the protocols MUST follow this rule and IMO the architecture document is a good place. Now taking into account, that the arch doc is almost closed (even not yet completely), I'm fine also to have this statement in the conflict-resolution draft. This is a really small addition and my preference is clearly to update the arch doc.

The receiver side for the SRGB part is per protocol as the consensus was in the thread that cross validation for SRGB is not necessary. We must not mix topic, here the topic is where do we put the sender and receiver behaviors for the SRGB validation. SID conflicts is another subject that we also need to discuss : but let's close this one first.

I would also say that both sender and receiver parts are key, and I would not give any priority to one over the other except if now vendors stop to produce buggy codes ;)

Best regards,

Stephane

-----Original Message-----
From: Stefano Previdi (sprevidi) [mailto:[email-masked]] 
Sent: Thursday, January 14, 2016 17:08
To: LITKOWSKI Stephane SCE/OINIS
Cc: Les Ginsberg (ginsberg); DECRAENE Bruno IMT/OLN; [email-masked]
Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution: Updating other drafts

Hi Stephane,

s.

> 2) What is already in 
> https://www.ietf.org/id/draft-ietf-isis-segment-routing-extensions-06.
> txt
> Section 3.1
>  
> 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 …
>  
> ______________________________________________________________________
> ___________________________________________________
>  
> 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.
> ______________________________________________________________________
> ___________________________________________________
>  
> 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.
> ______________________________________________________________________
> ___________________________________________________
>  
> 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.
> ______________________________________________________________________
> ___________________________________________________
>  
> 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.
> ______________________________________________________________________
> ___________________________________________________
> 
> 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.

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Thu, 14 Jan 2016 17:38:50 +0000

Hi Stephane,

> On Jan 14, 2016, at 6:12 PM, [email-masked] wrote:
> 
> Hi Stefano,
> 
> My worry is that tomorrow we will have a new protocol, and this KEY piece may be forgotten because nothing tells that this is required… 

why would it be like that ? The conflict resolution can still mandate the sender behavior that is explicitly stated in the protocol draft. It’s a matter of text duplication (and in general, the sender behavior is pretty simple).

> and this is a cross protocol behavior that we want.

> I'm fine to have it in the protocol as far as we have a more global document telling that all the protocols MUST follow this rule and IMO the architecture document is a good place.

the conflict-resolution draft is the right place. The SR architecture draft is not intended to go into such level of details.

Still, it’s important that each protocol specification has the description of the sender behavior.

> Now taking into account, that the arch doc is almost closed (even not yet completely), I'm fine also to have this statement in the conflict-resolution draft.

we’re in agreement. Note that I wouldn’t put it in the arch draft even if it wasn’t in LC.

> This is a really small addition and my preference is clearly to update the arch doc.

I don’t agree:

sender behavior is pretty small but if you want it in the arch doc then you also have to include the receiver behavior and this is a different story.

That’s why we have the conflict draft.

> The receiver side for the SRGB part is per protocol as the consensus was in the thread that cross validation for SRGB is not necessary.

I want a generic approach, not specific to a single conflict. SRGB is the easiest one but wait for the SID allocation conflict… that’s where the party really begins.

So, again, I prefer to see:

. sender behavior properly documented in each protocol 
. sender behavior to also been documented in conflict draft (for completeness)
. receiver behavior (which may imply multi-protocol behavior) documented into the conflict draft.
. receiver behavior referenced in protocol drafts (i.e.: a reference to the conflict draft).

> We must not mix topic, here the topic is where do we put the sender and receiver behaviors for the SRGB validation. SID conflicts is another subject that we also need to discuss : but let's close this one first.

I agree on the SID conflict fun… but still sender behavior is pretty simple.

> I would also say that both sender and receiver parts are key,

indeed but if the sender does the proper thing, most (not all, but most) of the receiver problems vanish.

> and I would not give any priority to one over the other except if now vendors stop to produce buggy codes ;)

vendors produce features… ;-)

s.

---

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

So I think we have an agreement by duplicating the sender requirement in the conflict draft.

-----Original Message-----
From: Stefano Previdi (sprevidi) [mailto:[email-masked]] 
Sent: Thursday, January 14, 2016 18:39
To: LITKOWSKI Stephane SCE/OINIS
Cc: Les Ginsberg (ginsberg); DECRAENE Bruno IMT/OLN; [email-masked]
Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution: Updating other drafts

Hi Stephane,

> My worry is that tomorrow we will have a new protocol, and this KEY 
> piece may be forgotten because nothing tells that this is required…

I don’t agree:

. sender behavior properly documented in each protocol . sender behavior to also been documented in conflict draft (for completeness) . receiver behavior (which may imply multi-protocol behavior) documented into the conflict draft.
. receiver behavior referenced in protocol drafts (i.e.: a reference to the conflict draft).

s.

---

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

Stephane -

> Sent: Friday, January 15, 2016 12:08 AM
> To: Stefano Previdi (sprevidi)

[Les:] Yes - this will be done.

   Les

> why would it be like that ? The conflict resolution can still mandate the
> sender behavior that is explicitly stated in the protocol draft. It’s a matter of
> text duplication (and in general, the sender behavior is pretty simple).
> 
> 
> > I'm fine to have it in the protocol as far as we have a more global document
> telling that all the protocols MUST follow this rule and IMO the architecture
> document is a good place.
> 
> 
> the conflict-resolution draft is the right place. The SR architecture draft is not
> intended to go into such level of details.
> 
> > Now taking into account, that the arch doc is almost closed (even not yet
> completely), I'm fine also to have this statement in the conflict-resolution
> draft.
> 
> 
> sender behavior is pretty small but if you want it in the arch doc then you also
> have to include the receiver behavior and this is a different story.
> 
> > The receiver side for the SRGB part is per protocol as the consensus was in
> the thread that cross validation for SRGB is not necessary.
> 
> 
> I want a generic approach, not specific to a single conflict. SRGB is the easiest
> one but wait for the SID allocation conflict… that’s where the party really
> begins.
> 
> . sender behavior properly documented in each protocol . sender behavior to
> also been documented in conflict draft (for completeness) . receiver
> behavior (which may imply multi-protocol behavior) documented into the
> conflict draft.
> > We must not mix topic, here the topic is where do we put the sender and
> receiver behaviors for the SRGB validation. SID conflicts is another subject
> that we also need to discuss : but let's close this one first.
> 
> 
> > to me it’s perfectly fine to have the sender behavior described in the
> protocol because this is the critical part of the whole game.
> >
> > Also, the protocol-specific draft is the reference document for any
> implementor so it’s important to find all the necessary information so that
> routing updates are formatted properly.
> >
> > Now, the receiver-side can be more complex because the receiver
> behavior may involve more than just one protocol. We will come to this
> when we will discuss SID allocation conflicts among protocols. Therefore, the
> receiver behavior must be described into a protocol-agnostic document.
> >
> > s.
> >
> >
> >
> >> [Les:] Just to be sure I understand you, you are advocating putting the
> SRGB sender behavior specification in draft-ginsberg-spring-conflict-
> resolution as well as the receiver behavior?
> >> Sender behavior HAS to be specified in the protocol documents as it
> describes the normative behavior of the protocols.
> >>
> >> [SLI] Well that’s a point of view, but in this case the receiver side has also
> to be in the protocols. All depends of the responsibility : is it a protocol
> related responsibility or not or a more global architectural requirement that
> all the protocols will need defacto to fill.
> >>
> >>
> >> [Les:] Perhaps. The BGP draft contains a reference to the OSPF draft as
> regards SRGB (see Section 4.3) - this might suffice -  but in principle I agree
> with you that we need to ensure that all protocols reference the common
> conflict resolution document. The authors of the BGP draft should indicate
> what language they believe is needed there.
> >>
> >> IMO, as I already pointed,  it would be easier to handle it a single
> document rather than in the protocol docs. Moreover we will have the
> sender part in many docs, and the receiver part in the spring-conflict-
> resolution draft.
> >>
> >>
> >>
> >> Inclusion of the sender behavior in draft-ginsberg-spring-conflict-
> resolution would then be redundant. I generally resist this because I think
> one of two things can happen:
> >>
> >> This makes the conflict resolution draft the authoritative document and
> no additional changes to other SR documents will be needed in the future no
> matter what changes occur in the conflict resolution draft.
> >>
> >>   Les
> >>
> >>
> >>
> >>
> >> 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
> >>
> >>
> >> [SLI] I’m was not suggesting to use only Adj-SID … as I also do not see a
> real use case for that. I’m just saying that the specification does not prevent
> it. So may be let’s prevent it …so we can update the architecture document
> saying that advertising a valid SRGB is a must. There is something wrong to
> me here, because we will state that a node with invalid SRGB will be treated
> as non SR capable while the architecture does not forbid to not have a SRGB
> and does not say anything on how the architecture works with no SRGB (we
> can only guess that only Adj-SID can be used).
> >>
> >>
> >> [Les2:] OK good – I think we agree on this point also. What is needed is to
> ensure that there is appropriate language in the SR architecture draft and/or
> the protocol drafts to specify how receiving an invalid SRGB affects the
> interpretation of “SR-MPLS capability”.
> >>
> >> As of today, the SR architecture has passed WG Last Call and his pending
> shepherd write up. Are you saying that there is a need to introduce technical
> change in the SR architecture?
> >>
> >> Before introducing such technical change in the document, draft authors
> would need to discuss them in the WG. Thanks.
> >>
> >> </chair hat>
> >>
> >> -- Bruno
> >>
> >>
> >> The text must state that  there must be a local configuration mechanism
> that avoids sender to originate overlapping SRGB.
> >>
> >> [SLI] I missed this, thanks. Anyway from a readability point of view, it
> would be good to recall that the protocol documents address the sender
> side. Do we have the same for BGP ?
> >> The issue with putting this text in the protocol doc, is that you
> >> need to ensure that all protocols will always have this restriction.
> >> It’s not really a protocol thing, more a configuration management one
> >> …
> >>
> >> [Les2:] If your concern is to make sure that all the protocol documents
> provide equivalent language – I agree this should be done and we will do the
> diligence necessary to make sure that text is included in all the places
> needed. My comment was that adding such a statement in this specification
> is really out of place. The right place to state the requirement is in the sender
> specification. I think we agree on this.
> >>
> >> In this case, as you mention, if a router receives overlapping SRGB, this is a
> bad behavior and we cannot guess if the forwarding plane is correctly
> programmed or not on the originator, so it is better to avoid it.
> >>
> >> Now regarding the sentence :” The originating router is considered to be
> incapable of supporting the SR-MPLS forwarding plane”. Do we have
> something in the architecture document saying that advertising a SRGB is
> mandatory to use SR ? Pure theorical example : what if someone wants only
> to use Adj-SIDs in SR network ? there is no need to advertise a SRGB. Stating
> that the node must be considered as non SR capable is strong, it will also
> prevent the usage of Adj-SID which will work well without SRGB. If we
> consider that having a SRGB is mandatory, we need to have this requirement
> in the architecture document.
> >>
> >> [Les:] An interesting point. What I am after here is recognition that
> without a valid SRGB the indication from a node that it is capable of
> “processing SR MPLS encapsulated IPv4/IPv6 packets on all interfaces” does
> 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.
> >>
> >> [SLI] I’m was not suggesting to use only Adj-SID … as I also do not see a
> real use case for that. I’m just saying that the specification does not prevent
> it. So may be let’s prevent it …so we can update the architecture document
> saying that advertising a valid SRGB is a must. There is something wrong to
> me here, because we will state that a node with invalid SRGB will be treated
> as non SR capable while the architecture does not forbid to not have a SRGB
> and does not say anything on how the architecture works with no SRGB (we
> can only guess that only Adj-SID can be used).
> >>
> >>
> >> [Les2:] OK good – I think we agree on this point also. What is needed is to
> ensure that there is appropriate language in the SR architecture draft and/or
> the protocol drafts to specify how receiving an invalid SRGB affects the
> interpretation of “SR-MPLS capability”. I will take an action item to follow up
> on that with the various draft authors.
> >>
> >>    Les
> >>
> >>
> >>
> >>   Les
> >>
> >>
> >> Best regards,
> >>
> >> Stephane
> >>
> >>
> >> 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).
> 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:
> >>
> >> 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
> >>
> >>
> __________________________________________________________
> ___________
> >> _ ___________________________________________________
> >>
> >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les
> pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> >> privileged information that may be protected by law; they should not be
> distributed, used or copied without authorisation.
> __________________________________________________________
> ___________
> >> _ ___________________________________________________
> >>
> >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les
> pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> >> privileged information that may be protected by law; they should not be
> distributed, used or copied without authorisation.
> __________________________________________________________
> ___________
> >> _ ___________________________________________________
> >>
> >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les
> pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> >> privileged information that may be protected by law; they should not be
> distributed, used or copied without authorisation.
> __________________________________________________________
> ___________
> >> _ ___________________________________________________
> >>
> >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les
> pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> >> privileged information that may be protected by law; they should not be
> distributed, used or copied without authorisation.
> __________________________________________________________
> ___________
> >> _ ___________________________________________________
> >>
> >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les
> pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> >> privileged information that may be protected by law; they should not be
> distributed, used or copied without authorisation.
> > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les
> pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> > privileged information that may be protected by law; they should not be
> distributed, used or copied without authorisation.
> __________________________________________________________
> __________________________________________________________
> _____
> 
> 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.