Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution

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

Bruno -

First, thank you very much for the time you have invested in thinking about the issues and writing alternative text for the draft. I can appreciate that this took significant time - and your input will certainly help us move forward.

I want to reemphasize the goals that hopefully we all share. This is best illustrated in Slide #9 from my presentation at IETF94: https://www.ietf.org/proceedings/94/slides/slides-94-spring-2.pdf

Detection, reporting, and consistent handling are the points of emphasis. What is deliberately deemphasized is the choice of resolution behavior. This is done because of the points made in Slide #8:

We could evaluate every possible solution and how it behaves in all of the possible misconfigurations. But I think this will take a very long time(years...) and give us very little return on the time spent. Indeed, over a year has already been spent in private/semi-private/public discussions on this topic and at the time the draft was written we were no closer to achieving consensus than when we started.

My goal is to have a version with broad consensus ready for WG adoption by IETF95. To achieve that we need input from more folks than you - hopefully your hard work will encourage others to contribute. But we also need a commitment to the priorities outlined in the slides reproduced above.

To the extent that your contributions help to clarify the options we have it is very valuable work and I again express my gratitude to you for providing this input. But if we spend the next few months trying to complete definition of all of the possible options and how they behave in a variety of potential misconfigurations I believe we will not be able to meet the goal.

In response to your post I am going to start two different threads:

1)SRGB Inconsistency

2)SID Conflict Resolution.

I want to separate these two topics because I think they do not have a logical relationship - and because I am hopeful that we will be able to achieve consensus easily on SRGB inconsistency. :)

This will then allow us to spend more cycles on SID Conflict resolution where I think the bulk of the remaining discussion is likely to occur.

Please look for the two new threads in the next day or two.

   Les

> -----Original Message-----

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

> Sent: Thursday, December 17, 2015 9:27 AM

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

> Subject: draft-ginsberg-spring-conflict-resolution

> Hi Les, authors, WG

> As an individual contributor, please find below some more detailed

> comments and considerations on the draft.

> Following the "please send text" request expressed during the meeting,

> please find enclosed some proposed text. (xml, txt, diff versus public

> version).

> I wished I had sent this before, but writing the text took longer than

> expected. BTW I still not happy with my text, but hopefully current text  (or

> at least the table of content) should be enough to give an idea on the

> direction I have in mind.

> Thanks,

> Regards,

> Bruno

> __

> As previous expressed on the mailing list and during the meeting, I'm

> especially concerned with Mapping Server advertisement where a single

> typo/bug can conflict with many/all SIDs in the network. In this case, I don't

> think that dropping all traffic to those SIDs is a desirable option.

> One option is to prefer individual advertisement (prefix SID) over general

> ones (Mapping Server). i.e. more specific wins. Note that this is the approach

> currently taken by the IS-IS draft:

> "   For a given prefix, if both a MS entry with its Prefix-SID Sub-TLV

>    and a Prefix TLV (e.g.: TLV135) with its Prefix-SID are received, the

>    Prefix-SID advertised within the Prefix TLV MUST be preferred while

>    the MS entry MUST be ignored."

> We can probably assume that this is already implemented (by compliant

> implementations), so I'm not sure to see the value of changing existing

> implementations if this is to get a more disruptive result for the network.

> __

> Regarding SID conflict, the current draft proposes to drop all conflicting

> information.

> Looking at the big picture, this means: the more (Mapping Server)

> redundancy, the more risk of conflict, the less availability.

> This is probably not the property that we are looking for.

> __

> I support the comment to consider the error handling work "recently" done

> in the IDR WG. IMHO, WG and authors did a good work on such a difficult

> subject (just like for SID conflicts, at the beginning opinions were diverse,

> and everyone had good reasons).

> I'm not sure how much reading the end result (RFC 7606) helps in

> understanding all the trade-off considered during the work. Reading the

> operational requirements, given that the IGP infrastructure is probably even

> more important than BGP for network operators/clients/traffic, it may be

> worthwhile to read BGP error handling operation requirements (

> https://tools.ietf.org/html/draft-ietf-grow-ops-reqs-for-bgp-error-handling-<https://tools.ietf.org/html/draft-ietf-grow-ops-reqs-for-bgp-error-handling-07>

> 07<https://tools.ietf.org/html/draft-ietf-grow-ops-reqs-for-bgp-error-handling-07> ) Discussion with the people involved may help. FYI, as for me, the point I

> learnt are:

> - when we detect an error on the receiving side, there is a bug. In general, it's

> difficult to know whether the bug is on the sending side or the receiving side.

> Clearly, for the receiving side, the first reaction is to blame the sending side.

> For each error, it's useful to consider both options (i.e. error may be on

> my/receiving side). And even if the error is on the sending side, the receiver

> may run the same implementation (so "sender is too buggy to live" may

> apply to your own implementation i.e. the receiving side).

> - when we detect an error, it's useful to consider all possible causes and

> consequences before deciding to make things worse (e.g. killing a

> session/transit node/prefix). In particular, there may not be a single error but

> many (SIDs, source routers (especially if the error is on the receiving side)).

> So it's useful to consider that the decision may be multiplied 10 or 100 times.

> Clearly there are difference between IGP & BGP: usually more redundancy in

> BGP (more signaling path (redundant RR) and more AS exit points), more

> prefixes hence the cost of dropping one prefix is relatively less important,

> two-way point to point signaling channel, messages are flooded unchanged

> so people are less likely to shoot the messenger and errors are less likely to

> be multiplied during propagation....

> __

> "An

>    alternative is to ensure at the nodes which originate these

>    advertisements that no such overlap is allowed to be configured.

>    Such overlaps can then be considered as a conflict if they are

>    received.  This allows a simpler and more efficient implementation of

>    the database.  This is the approach assumed in this document."

> I encourage implementation to check the configurations before accepting it.

> And to check its routing advertisement before sending it. I would assume

> that state of the art implementation will do it. Yet, I don't think it should be

> considered as an excuse to avoid error handling at the protocol level.

> BTW, I'm not sure how much you expect implementation checks to be done

> before committing/sending. e.g. If an operator configure a range on the

> SRMS, and this ranges conflict with existing SID advertised by other nodes,

> would you expect the implementation to detect such conflict and reject the

> configuration?

> More generally, if we assume some extensive checks by implementations

> before committing/sending, and that given such assumption we define a

> light error handling, I'd like such assumptions be documented in the

> document and probably be made normative (since the receiving side, is

> expected a specific behavior from the sending side, this is normative).

> Also "implementation of the database" is implementation dependent and is

> probably just one aspect of the implementation simplicity/efficiency.

> And speaking for myself, simplicity/efficiency/availability of 100s networks

> running segment routing significantly out weight the "simplicity and

> efficiency" of one to ten implementations.

> __

> "The occurrence of conflicts is

>           easily diagnosed from the behavior of the network as the forwarding

>           of traffic which would, in the absence of conflicts, utilize

>           segments no longer does so."

> I don't think that we need to kill customer's traffic to raise awareness of the

> network operator. And I don't support the idea that the more traffic you kill,

> the easier and faster the error is resolved.

> If you need to raise an error, please do so! e.g. in logs, syslogs, SNMP traps,

> netconf event notification... Dropping the traffic is not providing more

> information, it is increasing the pressure and hence the probability of quick

> erroneous actions. Not to mention that as all services will run over packet

> networks, and as there is a pressure to reduce costs we may have a single

> converged network for all services. In this case, there is a chance that if the

> network is down, some people/tools/equipment may not be reached

> anymore/easily. e.g. calling people on their cell phone does not work when

> the packet network is down.

> __

> "   The downside of ignoring conflicting entries is that forwarding of

>    all packets with destinations covered by the conflicting entries will

>    always be negatively impacted."

> Let's call a spade a spade. (btw, I prefer the French version :s/spade/cat

> which nowadays should be more popular on the Internet ;-) ) The traffic is

> not "negatively impacted", the traffic is "dropped". And for all

> services/customers/BGP routes using theses SIDs.

> __

> 3.2.2.  Preference Algorithm

> [...]

> "This approach requires that conflicting entries first be identified"

> All approach requires conflicting entries to be identified. This is not a

> drawback of the "preference algorithm"

> "Based on which  entry is preferred this in turn may impact what other

> entries are  considered in conflict"

> This is not additional rule/work. This is applying the same rule/algo to

> subsequent entries.

> Also, from the network perspective, in the end, this will not drop more

> entries than the "ignore rule", quite the contrary.

> "Based on

>           which entry is preferred this in turn may impact what other entries

>           are considered in conflict i.e. if A conflicts with B and B

>           conflicts with C - it is possible that A does NOT conflict with C.

>           Hence if as a result of the evaluation of the conflict between A and

>           B, entry B is not used the conflict between B and C will not be

>           considered."

> I'm not sure to get what is implied. As A and B conflicts and B and C conflicts,

> with "ignore conflicting entries", I would assume that all A, B, C be ignored,

> no? Or do you plan to ignore conflicting entries until there is no conflict? In

> which case we would only remove one of the two conflicting entries and end

> up with a "preference" resolution 'and never drop both conflicting entries

> since once we drop the first, there is no more conflict) ___

> __________________________________________________________

> __________________________________________________________

> _____

> 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: Mon, 4 Jan 2016 08:41:12 +0000

Hi Bruno,

And best wishes all for this new year.

It seems that posting your txt back as attachment to the list does not work so I will put my comments on the text directly in the email :

- In §2.2 : you keep the statement "The following ranges are used:" empty, may be it would be better to change with something like : "None of the ranges are used in this case" 

- §2.6 : It should be mentioned that this kind of behavior should never happen because the sender
must have local configuration procedures to avoid this kind of behavior.
But in case there is something going wrong and such advertisement is received, routers must have a consistent behavior.
IMO, as the local implementation must avoid this kind of advertisement (and I think we need to state this somewhere), drop all
sounds the best option because as this might be a bug, nothing says that the forwarding is correctly setup on the node sending the bad advertisement.

- §3. : IGP LSDB may be too restrictive, as depending of the label management
   implementation, there might be cross protocol conflicts of SIDs.

- §3.2.1 : 
[SLI] Maybe we should mention that this kind of conflict has a "limited" impact.
On the LSR, we have more LFIB consumption but no traffic impact, as we are creating 
multiple parallel LSPs towards the same destination.
At the iLSR side, there might be some churn in the FIB (IP to MPLS entry) as it will have
to choose one or the other advertisement in order to program the entry.

- §3.2.2 :
[SLI] As previous comment, we may need to mention the impact of such conflict : inconsistent routing (even possible loops)
 if there is disagreement between routers (LSRs).

- §3.3 :
[SLI] We must mention, that traffic is dropped for the destination affected by the conflict.
So if a new advertisement is received after a while leading to a conflict, traffic will be blackholed 
for the affected destination which is IMO not a good option.

- §3.4 :
[SLI] What happens if BGP sends the same SID ?

-§3.5 :
   [SLI] Maybe we need to remind that we already have a tiebreaking rule between MS entries and Prefix SIDs :
   "For a given prefix, if both a MS entry with its Prefix-SID Sub-TLV
   and a Prefix TLV (e.g.: TLV135) with its Prefix-SID are received, the
   Prefix-SID advertised within the Prefix TLV MUST be preferred while
   the MS entry MUST be ignored."

   [SLI] Giving a preference to MS entries may be a very good idea from
   an operational point of view, especially if someone wants to migrate
   mappings from one range to another for example. This discussion is out of
   scope but we may need to think about it.

- there are multiple small typo issues in SRGB examples : e.g. Range 3: (500, 5990 <=> Range 3: (500, 599) ; Range 1: (100, 199] <=> Range 1: (100, 199)

-----Original Message-----
From: spring [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, December 17, 2015 18:27
To: [email-masked]; Les Ginsberg (ginsberg)
Subject: [spring] draft-ginsberg-spring-conflict-resolution

Hi Les, authors, WG

As an individual contributor, please find below some more detailed comments and considerations on the draft.

Following the "please send text" request expressed during the meeting, please find enclosed some proposed text. (xml, txt, diff versus public version).

I wished I had sent this before, but writing the text took longer than expected. BTW I still not happy with my text, but hopefully current text  (or at least the table of content) should be enough to give an idea on the direction I have in mind. 

Thanks,
Regards,
Bruno

__
As previous expressed on the mailing list and during the meeting, I'm especially concerned with Mapping Server advertisement where a single typo/bug can conflict with many/all SIDs in the network. In this case, I don't think that dropping all traffic to those SIDs is a desirable option.
One option is to prefer individual advertisement (prefix SID) over general ones (Mapping Server). i.e. more specific wins. Note that this is the approach currently taken by the IS-IS draft:
"   For a given prefix, if both a MS entry with its Prefix-SID Sub-TLV
   and a Prefix TLV (e.g.: TLV135) with its Prefix-SID are received, the
   Prefix-SID advertised within the Prefix TLV MUST be preferred while
   the MS entry MUST be ignored."

We can probably assume that this is already implemented (by compliant implementations), so I'm not sure to see the value of changing existing implementations if this is to get a more disruptive result for the network.
__
Regarding SID conflict, the current draft proposes to drop all conflicting information.
Looking at the big picture, this means: the more (Mapping Server) redundancy, the more risk of conflict, the less availability.
This is probably not the property that we are looking for.
__

I support the comment to consider the error handling work "recently" done in the IDR WG. IMHO, WG and authors did a good work on such a difficult subject (just like for SID conflicts, at the beginning opinions were diverse, and everyone had good reasons).
I'm not sure how much reading the end result (RFC 7606) helps in understanding all the trade-off considered during the work. Reading the operational requirements, given that the IGP infrastructure is probably even more important than BGP for network operators/clients/traffic, it may be worthwhile to read BGP error handling operation requirements ( https://tools.ietf.org/html/draft-ietf-grow-ops-reqs-for-bgp-error-handling-07 ) Discussion with the people involved may help. FYI, as for me, the point I learnt are:
- when we detect an error on the receiving side, there is a bug. In general, it's difficult to know whether the bug is on the sending side or the receiving side. Clearly, for the receiving side, the first reaction is to blame the sending side. For each error, it's useful to consider both options (i.e. error may be on my/receiving side). And even if the error is on the sending side, the receiver may run the same implementation (so "sender is too buggy to live" may apply to your own implementation i.e. the receiving side).
- when we detect an error, it's useful to consider all possible causes and consequences before deciding to make things worse (e.g. killing a session/transit node/prefix). In particular, there may not be a single error but many (SIDs, source routers (especially if the error is on the receiving side)). So it's useful to consider that the decision may be multiplied 10 or 100 times.

Clearly there are difference between IGP & BGP: usually more redundancy in BGP (more signaling path (redundant RR) and more AS exit points), more prefixes hence the cost of dropping one prefix is relatively less important, two-way point to point signaling channel, messages are flooded unchanged so people are less likely to shoot the messenger and errors are less likely to be multiplied during propagation....

__
"An

I encourage implementation to check the configurations before accepting it. And to check its routing advertisement before sending it. I would assume that state of the art implementation will do it. Yet, I don't think it should be considered as an excuse to avoid error handling at the protocol level.
BTW, I'm not sure how much you expect implementation checks to be done before committing/sending. e.g. If an operator configure a range on the SRMS, and this ranges conflict with existing SID advertised by other nodes, would you expect the implementation to detect such conflict and reject the configuration?
More generally, if we assume some extensive checks by implementations before committing/sending, and that given such assumption we define a light error handling, I'd like such assumptions be documented in the document and probably be made normative (since the receiving side, is expected a specific behavior from the sending side, this is normative).
Also "implementation of the database" is implementation dependent and is probably just one aspect of the implementation simplicity/efficiency.
And speaking for myself, simplicity/efficiency/availability of 100s networks running segment routing significantly out weight the "simplicity and efficiency" of one to ten implementations.

__

I don't think that we need to kill customer's traffic to raise awareness of the network operator. And I don't support the idea that the more traffic you kill, the easier and faster the error is resolved.
If you need to raise an error, please do so! e.g. in logs, syslogs, SNMP traps, netconf event notification... Dropping the traffic is not providing more information, it is increasing the pressure and hence the probability of quick erroneous actions. Not to mention that as all services will run over packet networks, and as there is a pressure to reduce costs we may have a single converged network for all services. In this case, there is a chance that if the network is down, some people/tools/equipment may not be reached anymore/easily. e.g. calling people on their cell phone does not work when the packet network is down.

__

Let's call a spade a spade. (btw, I prefer the French version :s/spade/cat  which nowadays should be more popular on the Internet ;-) ) The traffic is not "negatively impacted", the traffic is "dropped". And for all services/customers/BGP routes using theses SIDs.

__

All approach requires conflicting entries to be identified. This is not a drawback of the "preference algorithm"

"Based on which  entry is preferred this in turn may impact what other entries are  considered in conflict"

This is not additional rule/work. This is applying the same rule/algo to subsequent entries.
Also, from the network perspective, in the end, this will not drop more entries than the "ignore rule", quite the contrary.

"Based on

I'm not sure to get what is implied. As A and B conflicts and B and C conflicts, with "ignore conflicting entries", I would assume that all A, B, C be ignored, no? Or do you plan to ignore conflicting entries until there is no conflict? In which case we would only remove one of the two conflicting entries and end up with a "preference" resolution 'and never drop both conflicting entries since once we drop the first, there is no more conflict) ___

_________________________________________________________________________________________________________________________

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: Martin Horneffer <[email-masked]>
Date: Tue, 5 Jan 2016 13:25:01 +0100

Hello Bruno, Les and everyone,

while I do appreciate and understand Les' motivation to forward this 
document quickly, I would rather support Bruno's approach to first do a 
little of analyses and discussions of the possible options before 
finally deciding for one. So: many thanks to both of you for the work 
you have done here!

And I don' agree that this should delay progress for years; just a rough 
analysis and discussion should be ok and help the technology to improve 
significantly. Of course, if there were people who wanted to impede 
progress of SR standardization, they could use this for their purposes. 
But then they would always find ways, regardless of the exact approach.

When it comes to evaluating the different options, I would ask the 
authors and the WG to not limit the view to "traffic lost", but to 
overall operational /robustness/ and /security/.

In this context those criteria - traffic affected, robustness and 
security - may well all lead to the same preference of options. They are 
not exactly the same, however.

For example in Bruno's discussion in 3.6, all three criteria would 
strongly favor option 3.

Best regards,
Martin

Am 17.12.15 um 18:26 schrieb [email-masked]:
> Let's call a spade a spade. (btw, I prefer the French version :s/spade/cat  which nowadays should be more popular on the Internet ;-) )
> The traffic is not "negatively impacted", the traffic is "dropped". And for all services/customers/BGP routes using theses SIDs.
>
> __
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring

---

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

Hi Stéphane,

Many thanks for contributing on this subject and for your comments.

Please see inline [Bruno]
Les, there is a specific question for you at the penultimate comment.

I'll send an updated text and diff in a few days, after considering comments from currently unread emails.

Bruno

> From: LITKOWSKI Stephane SCE/OINIS
> Sent: Monday, January 04, 2016 9:41 AM
> To: DECRAENE Bruno IMT/OLN; [email-masked]; Les Ginsberg (ginsberg)
> Subject: RE: draft-ginsberg-spring-conflict-resolution
> 
> Hi Bruno,
> 
> It seems that posting your txt back as attachment to the list does not work so I
> will put my comments on the text directly in the email :

[Bruno] sorry for the inconvenience. To avoid commenting twice, you could have copy / past the .txt attachment into the email body.

> - In §2.2 : you keep the statement "The following ranges are used:" empty,
> may be it would be better to change with something like : "None of the ranges
> are used in this case"

[Bruno] This is already spelled out lines above "In case of conflicts, all the ranges advertised are invalidated and dropped."
But I see what you mean. On the other hand, the goal was to have a short summary to allow comparison between options.
Currently I've changed to 
"The following ranges are used:
      <none>"

But any other option is welcomed

> must have local configuration procedures to avoid this kind of behavior.

Added: These SRGB ranges are advertised by a single node. As per [SR-IS-IS], a node MUST not advertise overlapping SRGB ranges. Hence a SRGB range conflict means a bug in the implementation of the originator.

> But in case there is something going wrong and such advertisement is
> received, routers must have a consistent behavior.
> IMO, as the local implementation must avoid this kind of advertisement (and I
> think we need to state this somewhere),

[Bruno] I agree with you. I think this should be mentioned in §2.7 "Discussion" rather than in §2.6. I propose to add:
"These SRGB ranges are advertised by a single node. As per [SR-IS-IS], a node MUST not advertise overlapping SRGB ranges. Hence a SRGB range conflict means a bug in the implementation of the originator. However, bugs happen and we need a consistent error handling behaviour across the network to minimize mis-routing and to allow ingress to know the state of the network and act upon (e.g. reroute around the bug)"

> drop all
> sounds the best option because as this might be a bug, nothing says that the
> forwarding is correctly setup on the node sending the bad advertisement.

[Bruno] At this point in time, I would rather write down the pro&con of each option, in order to allow technical discussion, refinement and hopefully drive the discussion toward consensus.
Personally, as of today, I would favor either "Drop all" or "Drop from conflict". The latter have the nice property that, assuming that the network was running correctly before, the issue is with the added SRGB range which may be expected to be added to allow for future growth. i.e. not currently used. So this seems overkill to drop all traffic, for a SRGB range which has been added and is not even used by global SIDs.

>    implementation, there might be cross protocol conflicts of SIDs.

[Bruno] Agreed. But:
- this is a text from Les, I'll leave the resolution to Les
- I'd rather avoid making the issue more complex, while we still can't agree on conflict resolution within a protocol.

[Bruno] Agreed. Good point thanks.
Added in 3.2.1 (1 prefix, multiple SIDs): "The consequences of this conflict is that multiple MPLS FIB entries would be programmed for a single IP Prefix. This has no impact on the traffic but use more MPLS FIB entries, which may or not be problematic  for the network equipments."

> - §3.2.2 :
> [SLI] As previous comment, we may need to mention the impact of such
> conflict : inconsistent routing (even possible loops)

[Bruno] Agreed. Good point thanks.
Added in 3.2.2 (1 SID, multiple prefixes): " The consequences of this conflict is that in the absence of conflict resolution two IP prefixes would be forwarded to the same destination. If they are part of the same FEC (Forwarding Equivalent Class), this is not an issue. Otherwise, this leads to mis-routing of a prefix to a wrong destination. In a VPN network, this may lead to VPN breach which is very problematic (even if the breach would be unidirectional only). In case of inconsistent conflict resolution across nodes, this may lead to persistent forwarding loops."

> for the affected destination 

[Bruno] From an editorial standpoint, I have chosen to describe the options from a specification standpoint. So that those sections should be non controvertials.
Discussion is done in §3.6 "Discussion".

>From a technical standpoint, I agree with you and this is discussed in 3.6.2 'Network operation"

>which is IMO not a good option.
[Bruno] Personally, I agree with you. I would even say that this is not acceptable that a single typo in a MS advertisement shut down half of the network.
But at this point in the document and discussion, I'd rather stick to facts and remove opinions.
 
> [SLI] What happens if BGP sends the same SID ?

[Bruno] At this point, I'm focusing to conflict within a single protocol. Given the disagreements, I'd rather reduce the scope to simplify.
But I agree with you that this is a valid question.

>    scope but we may need to think about it.

[Bruno] Excellent point. But as the resolutions rules proposed in draft-ginsberg-spring-conflict-resolution do not seem achieve the above goal, I had assume that this current text from draft-ietf-isis-segment-routing-extensions would be removed and replaced by the resolutions rules described in  draft-ginsberg-spring-conflict-resolution.
Les, could you please clarify this point?

> - there are multiple small typo issues in SRGB examples : e.g. Range 3: (500,
> 5990 <=> Range 3: (500, 599) ; Range 1: (100, 199] <=> Range 1: (100, 199)

[Bruno] Thanks. Fixed. (at least I'm consistent in my typos ;-) (which is expected when copy/pasting) )

> please find enclosed some proposed text. (xml, txt, diff versus public version).
> 
> I wished I had sent this before, but writing the text took longer than expected.
> BTW I still not happy with my text, but hopefully current text  (or at least the
> table of content) should be enough to give an idea on the direction I have in
> mind.
> 
> Thanks,
> Regards,
> Bruno
> 
> __
> I support the comment to consider the error handling work "recently" done in
> the IDR WG. IMHO, WG and authors did a good work on such a difficult subject
> (just like for SID conflicts, at the beginning opinions were diverse, and
> everyone had good reasons).
> https://tools.ietf.org/html/draft-ietf-grow-ops-reqs-for-bgp-error-handling-07
> ) Discussion with the people involved may help. FYI, as for me, the point I
> learnt are:
> may run the same implementation (so "sender is too buggy to live" may apply
> to your own implementation i.e. the receiving side).
> many (SIDs, source routers (especially if the error is on the receiving side)). So
> it's useful to consider that the decision may be multiplied 10 or 100 times.
> 
> two-way point to point signaling channel, messages are flooded unchanged so
> people are less likely to shoot the messenger and errors are less likely to be
> multiplied during propagation....
> 
> __
> "An
> And to check its routing advertisement before sending it. I would assume that
> state of the art implementation will do it. Yet, I don't think it should be
> before committing/sending. e.g. If an operator configure a range on the SRMS,
> and this ranges conflict with existing SID advertised by other nodes, would you
> expect the implementation to detect such conflict and reject the
> configuration?
> before committing/sending, and that given such assumption we define a light
> error handling, I'd like such assumptions be documented in the document and
> probably be made normative (since the receiving side, is expected a specific
> behavior from the sending side, this is normative).
> which nowadays should be more popular on the Internet ;-) ) The traffic is not
> "negatively impacted", the traffic is "dropped". And for all
> Also, from the network perspective, in the end, this will not drop more entries
> than the "ignore rule", quite the contrary.
> 
> "Based on
> ____________________________________________________________
> ____________________________________________________________
> _
>

---

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

Hi Les,

> Detection, reporting, and consistent handling are the points of emphasis. What is deliberately deemphasized is the choice of resolution behavior

Agreed.
I think that we also recently agreed that this work (load) from both a specification and implementation standpoint is needed and has the same cost whatever the resolution action is chosen. That's a good first step.

> We could evaluate every possible solution and how it behaves in all of the possible misconfigurations. But I think this will take a very long time(years...) and give us very little return on the ti…

I disagree.
I share your observation that we already spent many time discussing this point either in private/semi-private/IS-IS mailing list, with too little outcome, both in term of quality of the technical discussions and results.
I assume that in term of goals, all people involved so far are working to achieve both a good technical outcome and in time for the deployments. In particular I'm not seeing anyone having a political agenda to delay the resolution.
I also see that people involved are "rather" good: good technical skills, good involvement in particular in term of time commitment.
Based on the above I would assume (or hope) that the lack of convergence is rather based on different perspectives. Both from a technical perspective and from a role standpoint (e.g. vendor vs operator). IMO converging on this will require more discussion and sharing of the analysis that each one is making, to agree on the requirements and the cost/benefits of each option. Then I'm hoping that we'll agree that on some points, the different is not significant enough to make them a blocking issue. Then hopefully we should be able to identify the hopefully very few key points of disagreement/difference of perspective. Then discuss and get rough consensus on those.
We already tried to bypass this step of sharing the analysis, and this didn't work. Let's not lose more time doing the same process and expecting a different outcome.

> My goal is to have a version with broad consensus ready for WG adoption by IETF95
Good. IMHO the status of the document is not the key issue: the disagreement was previously located in draft-ietf-isis-segment-routing-extensions<http://tools.ietf.org/wg/isis/draft-ietf-isis-segment-routing-extensions/> which is a WG document, and that didn't make any difference.

> we need input from more folks than you
Yes, this would indeed be good. I'd like to thank Martin, Rob and Stéphane for their active contributions. I'd like to encourage all network operators to looks at this point, especially operators considering using Mapping Server (now or anytime latter) as this feature open the ability for a single CLI typo to conflict with all SIDs in the network. Hence the consequences may be very significant if one chose to stop forwarding the traffic for all SID having conflicts.

Note however that this point has already being discussed in the SR team in the early days of Segment Routing discussions, with multiple SP involved, and the outcome, written in draft-ietf-isis-segment-routing-extensions<http://tools.ietf.org/wg/isis/draft-ietf-isis-segment-routing-extensions/> was that:
   For a given prefix, if both a MS entry with its Prefix-SID Sub-TLV
   and a Prefix TLV (e.g.: TLV135) with its Prefix-SID are received, the
   Prefix-SID advertised within the Prefix TLV MUST be preferred while
   the MS entry MUST be ignored.
https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions-06#section-2.4.5

And many of the recent discussions is based on your proposition to change this behavior and put MS entry and Prefix-SID Sub-TLV at the same priority level.

I will return your comment to you: we need inputs from more vendors. In particular because most your arguments are about implementation cost/complexity, and this point may be very implementation specific. I'd like to thank Wim and Pushpasis for their active contributions.

Thanks for initiating 2 threads on SRGBs and SID conflicts. I agree that these 2 points can be discussed independently.

-- Bruno

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

Bruno -

1)SRGB Inconsistency

   Les

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

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

---

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

Hi Martin,

Many thanks for contributing to the discussion. We really need multiple contributions to resolve the deadlock.

As a network operator, I would clearly agree with you.

> When it comes to evaluating the different options, I would ask the authors and the WG to not limit the view to "traffic lost", but to overall operational robustness and security.

Good points.
It would really help if you could propose some text to be added in the document.

Thanks
-- Bruno

From: Martin Horneffer [mailto:[email-masked]]
Sent: Tuesday, January 05, 2016 1:25 PM
To: DECRAENE Bruno IMT/OLN; [email-masked]; Les Ginsberg (ginsberg)
Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution

while I do appreciate and understand Les' motivation to forward this document quickly, I would rather support Bruno's approach to first do a little of analyses and discussions of the possible options before finally deciding for one. So: many thanks to both of you for the work you have done here!

And I don' agree that this should delay progress for years; just a rough analysis and discussion should be ok and help the technology to improve significantly. Of course, if there were people who wanted to impede progress of SR standardization, they could use this for their purposes. But then they would always find ways, regardless of the exact approach.

When it comes to evaluating the different options, I would ask the authors and the WG to not limit the view to "traffic lost", but to overall operational robustness and security.

In this context those criteria - traffic affected, robustness and security - may well all lead to the same preference of options. They are not exactly the same, however.

For example in Bruno's discussion in 3.6, all three criteria would strongly favor option 3.

Best regards,
Martin

Am 17.12.15 um 18:26 schrieb [email-masked]<mailto:[email-masked]>:

Hi Les, authors, WG

Thanks,

Regards,

Bruno

__

__

__

__

"An

__

__

__

[...]

"Based on

          considered."

I'm not sure to get what is implied. As A and B conflicts and B and C conflicts, with "ignore conflicting entries", I would assume that all A, B, C be ignored, no? Or do you plan to ignore conflicting entries until there is no conflict? In which case we would only remove one of the two conflicting entries and end up with a "preference" resolution 'and never drop both conflicting entries since once we drop the first, there is no more conflict)

___

Thank you.

spring mailing list

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

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 6 Jan 2016 23:03:25 +0000

Bruno -

I think there are two questions for me below - look for my answers inline.
Let me know if I missed anything.

> Sent: Wednesday, January 06, 2016 10:04 AM
> To: LITKOWSKI Stephane SCE/OINIS
> Cc: [email-masked]; Les Ginsberg (ginsberg)
> > It seems that posting your txt back as attachment to the list does not
> > work so I will put my comments on the text directly in the email :
> 
> [Bruno] sorry for the inconvenience. To avoid commenting twice, you could
> have copy / past the .txt attachment into the email body.
> 
> 
> > - In §2.2 : you keep the statement "The following ranges are used:"
> > empty, may be it would be better to change with something like : "None
> > of the ranges are used in this case"
> 
> [Bruno] This is already spelled out lines above "In case of conflicts, all the
> ranges advertised are invalidated and dropped."
> But I see what you mean. On the other hand, the goal was to have a short
> summary to allow comparison between options.
> > - §2.6 : It should be mentioned that this kind of behavior should
> > never happen because the sender must have local configuration
> > procedures to avoid this kind of behavior.
> 
> Added: These SRGB ranges are advertised by a single node. As per [SR-IS-IS],
> a node MUST not advertise overlapping SRGB ranges. Hence a SRGB range
> conflict means a bug in the implementation of the originator.
> 
> > IMO, as the local implementation must avoid this kind of advertisement
> > (and I think we need to state this somewhere),
> 
> [Bruno] I agree with you. I think this should be mentioned in §2.7
> "Discussion" rather than in §2.6. I propose to add:
> "These SRGB ranges are advertised by a single node. As per [SR-IS-IS], a node
> MUST not advertise overlapping SRGB ranges. Hence a SRGB range conflict
> means a bug in the implementation of the originator. However, bugs happen
> and we need a consistent error handling behaviour across the network to
> minimize mis-routing and to allow ingress to know the state of the network
> and act upon (e.g. reroute around the bug)"
> 
> > drop all
> > sounds the best option because as this might be a bug, nothing says
> > that the forwarding is correctly setup on the node sending the bad
> advertisement.
> 
> [Bruno] At this point in time, I would rather write down the pro&con of each
> option, in order to allow technical discussion, refinement and hopefully drive
> the discussion toward consensus.
> Personally, as of today, I would favor either "Drop all" or "Drop from conflict".
> The latter have the nice property that, assuming that the network was
> running correctly before, the issue is with the added SRGB range which may
> be expected to be added to allow for future growth. i.e. not currently used.
> So this seems overkill to drop all traffic, for a SRGB range which has been
> added and is not even used by global SIDs.
> 
> 

[Les:] I am not proposing that we do cross-protocol validation of SRGBs. This would indeed increase the complexity and I am not convinced we would gain much.
SID conflict detection is a different matter - there we do indeed want to include all protocols.

> > On the LSR, we have more LFIB consumption but no traffic impact, as we
> > are creating multiple parallel LSPs towards the same destination.
> > At the iLSR side, there might be some churn in the FIB (IP to MPLS
> > entry) as it will have to choose one or the other advertisement in
> > order to program the entry.
> 
> Added in 3.2.1 (1 prefix, multiple SIDs): "The consequences of this conflict is
> that multiple MPLS FIB entries would be programmed for a single IP Prefix.
> This has no impact on the traffic but use more MPLS FIB entries, which may
> or not be problematic  for the network equipments."
> 
> 
> > - §3.2.2 :
> > conflict : inconsistent routing (even possible loops)  if there is
> > disagreement between routers (LSRs).
> 
> Added in 3.2.2 (1 SID, multiple prefixes): " The consequences of this conflict is
> that in the absence of conflict resolution two IP prefixes would be forwarded
> to the same destination. If they are part of the same FEC (Forwarding
> Equivalent Class), this is not an issue. Otherwise, this leads to mis-routing of a
> prefix to a wrong destination. In a VPN network, this may lead to VPN breach
> which is very problematic (even if the breach would be unidirectional only).
> In case of inconsistent conflict resolution across nodes, this may lead to
> persistent forwarding loops."
> 
> 
> > - §3.3 :
> > So if a new advertisement is received after a while leading to a
> > conflict, traffic will be blackholed for the affected destination
> 
> [Bruno] From an editorial standpoint, I have chosen to describe the options
> from a specification standpoint. So that those sections should be non
> controvertials.
> [Bruno] Personally, I agree with you. I would even say that this is not
> acceptable that a single typo in a MS advertisement shut down half of the
> network.
> [Bruno] At this point, I'm focusing to conflict within a single protocol. Given
> the disagreements, I'd rather reduce the scope to simplify.
> >    [SLI] Maybe we need to remind that we already have a tiebreaking
> > rule between MS entries and Prefix SIDs :
> [Bruno] Excellent point. But as the resolutions rules proposed in draft-
> ginsberg-spring-conflict-resolution do not seem achieve the above goal, I had
> assume that this current text from draft-ietf-isis-segment-routing-
> extensions would be removed and replaced by the resolutions rules
> described in  draft-ginsberg-spring-conflict-resolution.
[Les:] I "think" you are referring to this text from the IS-IS draft (Section 2.4.5):

This text should be removed - the protocol drafts should simply reference the spring-conflict-resolution draft. Indeed one of the motivations for spring-conflict-resolution draft is to unblock the protocol drafts and isolate the conflict resolution to a single common draft. This means the protocol drafts MUST be agnostic and if they say anything at all it would be to reference spring-conflict-resolution draft.

   Les

> expected.
> > BTW I still not happy with my text, but hopefully current text  (or at
> > least the table of content) should be enough to give an idea on the
> > typo/bug can conflict with many/all SIDs in the network. In this case,
> > I don't think that dropping all traffic to those SIDs is a desirable option.
> > One option is to prefer individual advertisement (prefix SID) over
> > general ones (Mapping Server). i.e. more specific wins. Note that this
> > is the approach currently taken by the IS-IS draft:
> > implementations), so I'm not sure to see the value of changing
> > existing implementations if this is to get a more disruptive result for the
> network.
> > __
> > I support the comment to consider the error handling work "recently"
> > done in the IDR WG. IMHO, WG and authors did a good work on such a
> > difficult subject (just like for SID conflicts, at the beginning
> > opinions were diverse, and everyone had good reasons).
> > understanding all the trade-off considered during the work. Reading
> > the operational requirements, given that the IGP infrastructure is
> > probably even more important than BGP for network
> > operators/clients/traffic, it may be worthwhile to read BGP error
> > handling operation requirements (
> > ) Discussion with the people involved may help. FYI, as for me, the
> > point I learnt are:
> > - when we detect an error on the receiving side, there is a bug. In
> > general, it's difficult to know whether the bug is on the sending side or the
> receiving side.
> > For each error, it's useful to consider both options (i.e. error may
> > be on my/receiving side). And even if the error is on the sending
> > side, the receiver may run the same implementation (so "sender is too
> > buggy to live" may apply to your own implementation i.e. the receiving
> side).
> > - when we detect an error, it's useful to consider all possible causes
> > and consequences before deciding to make things worse (e.g. killing a
> > session/transit node/prefix). In particular, there may not be a single
> > error but many (SIDs, source routers (especially if the error is on
> > the receiving side)). So it's useful to consider that the decision may be
> multiplied 10 or 100 times.
> >
> > Clearly there are difference between IGP & BGP: usually more
> > redundancy in BGP (more signaling path (redundant RR) and more AS exit
> > points), more prefixes hence the cost of dropping one prefix is
> > relatively less important, two-way point to point signaling channel,
> > messages are flooded unchanged so people are less likely to shoot the
> > messenger and errors are less likely to be multiplied during propagation....
> >
> > __
> > "An
> > And to check its routing advertisement before sending it. I would
> > assume that state of the art implementation will do it. Yet, I don't
> > think it should be considered as an excuse to avoid error handling at the
> protocol level.
> > before committing/sending. e.g. If an operator configure a range on
> > the SRMS, and this ranges conflict with existing SID advertised by
> > other nodes, would you expect the implementation to detect such
> > conflict and reject the configuration?
> > Also "implementation of the database" is implementation dependent and
> > is probably just one aspect of the implementation simplicity/efficiency.
> > And speaking for myself, simplicity/efficiency/availability of 100s
> > networks running segment routing significantly out weight the
> > "simplicity and efficiency" of one to ten implementations.
> >
> > __
> > I don't think that we need to kill customer's traffic to raise
> > awareness of the network operator. And I don't support the idea that
> > the more traffic you kill, the easier and faster the error is resolved.
> > If you need to raise an error, please do so! e.g. in logs, syslogs,
> > SNMP traps, netconf event notification... Dropping the traffic is not
> > providing more information, it is increasing the pressure and hence
> > the probability of quick erroneous actions. Not to mention that as all
> > services will run over packet networks, and as there is a pressure to
> > reduce costs we may have a single converged network for all services.
> > In this case, there is a chance that if the network is down, some
> > people/tools/equipment may not be reached anymore/easily. e.g. calling
> > people on their cell phone does not work when the packet network is
> down.
> >
> > __
> > Let's call a spade a spade. (btw, I prefer the French version
> > :s/spade/cat which nowadays should be more popular on the Internet ;-)
> > ) The traffic is not "negatively impacted", the traffic is "dropped".
> > And for all services/customers/BGP routes using theses SIDs.
> >
> > __
> > All approach requires conflicting entries to be identified. This is
> > not a drawback of the "preference algorithm"
> >
> > Also, from the network perspective, in the end, this will not drop
> > more entries than the "ignore rule", quite the contrary.
> >
> > "Based on
> > I'm not sure to get what is implied. As A and B conflicts and B and C
> > conflicts, with "ignore conflicting entries", I would assume that all
> > A, B, C be ignored, no? Or do you plan to ignore conflicting entries
> > until there is no conflict? In which case we would only remove one of
> > the two conflicting entries and end up with a "preference" resolution
> > 'and never drop both conflicting entries since once we drop the first,
> > there is no more conflict) ___
> >
> >
> >
> >
> > 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: <[email-masked]>
Date: Thu, 7 Jan 2016 16:12:47 +0000

Hi,

[SLI] IMO, complexity of SRGB cross protocol validation  depends on how the implementation is done. The SRGB may or may not really be owned by the protocol directly. Protocol just do the advertisement, but SRGB may be owned by SR that may do suballocation for a particular protocol. That really depends on how it has been coded. I'm not sure that in Cisco implementation that ISIS requests label range directly from the label manager ? If "SR process" owns all the labels and just receive requests from protocols to reserve a particular SRGB, it has the global view and can manage overlap easily. For example, if user tries to configure a BGP SRGB that overlaps with ISIS SRGB, it can be easily refused by the SR process. 

So we go back to the question of the requirements ... I think it would be really helpful that the WG agree on the requirement before talking about solutions.

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

Bruno -

> > It seems that posting your txt back as attachment to the list does 
> > not work so I will put my comments on the text directly in the email :
> 
> [Bruno] sorry for the inconvenience. To avoid commenting twice, you 
> could have copy / past the .txt attachment into the email body.
> 
> 
> > empty, may be it would be better to change with something like : 
> > "None of the ranges are used in this case"
> 
> [Bruno] This is already spelled out lines above "In case of conflicts, 
> all the ranges advertised are invalidated and dropped."
> But I see what you mean. On the other hand, the goal was to have a 
> short summary to allow comparison between options.
> Added: These SRGB ranges are advertised by a single node. As per 
> [SR-IS-IS], a node MUST not advertise overlapping SRGB ranges. Hence a 
> SRGB range conflict means a bug in the implementation of the originator.
> 
> > IMO, as the local implementation must avoid this kind of 
> > advertisement (and I think we need to state this somewhere),
> 
> "These SRGB ranges are advertised by a single node. As per [SR-IS-IS], 
> conflict means a bug in the implementation of the originator. However, 
> bugs happen and we need a consistent error handling behaviour across 
> the network to minimize mis-routing and to allow ingress to know the 
> state of the network and act upon (e.g. reroute around the bug)"
> 
> > drop all
> [Bruno] At this point in time, I would rather write down the pro&con 
> of each option, in order to allow technical discussion, refinement and 
> hopefully drive the discussion toward consensus.
> running correctly before, the issue is with the added SRGB range which 
> may be expected to be added to allow for future growth. i.e. not currently used.
> So this seems overkill to drop all traffic, for a SRGB range which has 
> been added and is not even used by global SIDs.
> 
> 
> - I'd rather avoid making the issue more complex, while we still can't 
> agree on conflict resolution within a protocol.
> 

> > On the LSR, we have more LFIB consumption but no traffic impact, as 
> > we are creating multiple parallel LSPs towards the same destination.
> Added in 3.2.1 (1 prefix, multiple SIDs): "The consequences of this 
> conflict is that multiple MPLS FIB entries would be programmed for a single IP Prefix.
> This has no impact on the traffic but use more MPLS FIB entries, which 
> may or not be problematic  for the network equipments."
> 
> 
> > - §3.2.2 :
> Added in 3.2.2 (1 SID, multiple prefixes): " The consequences of this 
> conflict is that in the absence of conflict resolution two IP prefixes 
> would be forwarded to the same destination. If they are part of the 
> same FEC (Forwarding Equivalent Class), this is not an issue. 
> Otherwise, this leads to mis-routing of a prefix to a wrong 
> destination. In a VPN network, this may lead to VPN breach which is very problematic (even if the breach would be unidirectional only).
> In case of inconsistent conflict resolution across nodes, this may 
> lead to persistent forwarding loops."
> 
> 
> > - §3.3 :
> [Bruno] From an editorial standpoint, I have chosen to describe the 
> options from a specification standpoint. So that those sections should 
> be non controvertials.
> [Bruno] Personally, I agree with you. I would even say that this is 
> not acceptable that a single typo in a MS advertisement shut down half 
> of the network.
> [Bruno] At this point, I'm focusing to conflict within a single 
> protocol. Given the disagreements, I'd rather reduce the scope to simplify.
> [Bruno] Excellent point. But as the resolutions rules proposed in 
> draft- ginsberg-spring-conflict-resolution do not seem achieve the 
> above goal, I had assume that this current text from 
> draft-ietf-isis-segment-routing- extensions would be removed and 
> replaced by the resolutions rules described in  draft-ginsberg-spring-conflict-resolution.

   Les

> > 5990 <=> Range 3: (500, 599) ; Range 1: (100, 199] <=> Range 1: 
> > (100,
> > 199)
> 
> > Following the "please send text" request expressed during the 
> > meeting, please find enclosed some proposed text. (xml, txt, diff 
> > versus public
> version).
> >
> > BTW I still not happy with my text, but hopefully current text  (or 
> > at least the table of content) should be enough to give an idea on 
> > the direction I have in mind.
> >
> > Thanks,
> > Regards,
> > Bruno
> >
> > __
> > As previous expressed on the mailing list and during the meeting, 
> > I'm especially concerned with Mapping Server advertisement where a 
> > single typo/bug can conflict with many/all SIDs in the network. In 
> > this case, I don't think that dropping all traffic to those SIDs is a desirable option.
> > general ones (Mapping Server). i.e. more specific wins. Note that 
> > this is the approach currently taken by the IS-IS draft:
> > We can probably assume that this is already implemented (by 
> > compliant implementations), so I'm not sure to see the value of 
> > changing existing implementations if this is to get a more 
> > disruptive result for the
> network.
> > __
> > https://tools.ietf.org/html/draft-ietf-grow-ops-reqs-for-bgp-error-h
> > an
> > dling-07
> > Clearly, for the receiving side, the first reaction is to blame the 
> > sending
> side.
> > side, the receiver may run the same implementation (so "sender is 
> > too buggy to live" may apply to your own implementation i.e. the 
> > receiving
> side).
> > - when we detect an error, it's useful to consider all possible 
> > causes and consequences before deciding to make things worse (e.g. 
> > killing a session/transit node/prefix). In particular, there may not 
> > be a single error but many (SIDs, source routers (especially if the 
> > error is on the receiving side)). So it's useful to consider that 
> > the decision may be
> > redundancy in BGP (more signaling path (redundant RR) and more AS 
> > exit points), more prefixes hence the cost of dropping one prefix is 
> > messages are flooded unchanged so people are less likely to shoot 
> > the messenger and errors are less likely to be multiplied during propagation....
> >
> > __
> > "An
> > I encourage implementation to check the configurations before 
> > accepting
> it.
> > More generally, if we assume some extensive checks by 
> > implementations before committing/sending, and that given such 
> > assumption we define a light error handling, I'd like such 
> > assumptions be documented in the document and probably be made 
> > normative (since the receiving side, is expected a specific behavior from the sending side, this is normative).
> > Also "implementation of the database" is implementation dependent 
> > and is probably just one aspect of the implementation simplicity/efficiency.
> > SNMP traps, netconf event notification... Dropping the traffic is 
> > not providing more information, it is increasing the pressure and 
> > hence the probability of quick erroneous actions. Not to mention 
> > that as all services will run over packet networks, and as there is 
> > a pressure to reduce costs we may have a single converged network for all services.
> > people/tools/equipment may not be reached anymore/easily. e.g. 
> > calling people on their cell phone does not work when the packet 
> > network is
> down.
> >
> > __
> > "Based on which  entry is preferred this in turn may impact what 
> > other entries are  considered in conflict"
> >
> > I'm not sure to get what is implied. As A and B conflicts and B and 
> > C conflicts, with "ignore conflicting entries", I would assume that 
> > all A, B, C be ignored, no? Or do you plan to ignore conflicting 
> > entries until there is no conflict? In which case we would only 
> > remove one of the two conflicting entries and end up with a 
> > "preference" resolution 'and never drop both conflicting entries 
> > 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,
> > 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.
> 
> 
> d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 7 Jan 2016 17:19:24 +0100

Hi Stephane,

> For example, if user tries to configure a BGP SRGB that
> overlaps with ISIS SRGB

Can you elaborate why that would be a bad thing to have two protocols
advertise even not partially overlapping but identical SRGB from a given
node ?

Also while we are at the node doing the check during configuration let's do
not forget that not all configurations these days are real time and inline.
To add concepts of forward referencing are also used which may allow on
purpose to configure overlapping blocks before even given IGP (or protocol
in general) is activated on any interface.

Best,
r.

On Thu, Jan 7, 2016 at 5:12 PM, <[email-masked]> wrote:

> Hi,
>
> [Les:] I am not proposing that we do cross-protocol validation of SRGBs.
> This would indeed increase the complexity and I am not convinced we would
> gain much.
> [SLI] IMO, complexity of SRGB cross protocol validation  depends on how
> the implementation is done. The SRGB may or may not really be owned by the
> protocol directly. Protocol just do the advertisement, but SRGB may be
> owned by SR that may do suballocation for a particular protocol. That
> really depends on how it has been coded. I'm not sure that in Cisco
> implementation that ISIS requests label range directly from the label
> manager ? If "SR process" owns all the labels and just receive requests
> from protocols to reserve a particular SRGB, it has the global view and can
> manage overlap easily. For example, if user tries to configure a BGP SRGB
> that overlaps with ISIS SRGB, it can be easily refused by the SR process.
>
> So we go back to the question of the requirements ... I think it would be
> really helpful that the WG agree on the requirement before talking about
> solutions.
>
>
> [Les:] I am not proposing that we do cross-protocol validation of SRGBs.
> This would indeed increase the complexity and I am not convinced we would
> gain much.
> > > [SLI] Maybe we should mention that this kind of conflict has a
> "limited"
> > impact.
> > destination. In a VPN network, this may lead to VPN breach which is very
> problematic (even if the breach would be unidirectional only).
> > replaced by the resolutions rules described in
> draft-ginsberg-spring-conflict-resolution.
> This text should be removed - the protocol drafts should simply reference
> the spring-conflict-resolution draft. Indeed one of the motivations for
> spring-conflict-resolution draft is to unblock the protocol drafts and
> isolate the conflict resolution to a single common draft. This means the
> protocol drafts MUST be agnostic and if they say anything at all it would
> be to reference spring-conflict-resolution draft.
>
>    Les
>
>
> >
> > > normative (since the receiving side, is expected a specific behavior
> from the sending side, this is normative).
> 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,
> information that may be protected by law;

---

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

Stephane -

I know that you are well versed in this issue from the discussion we had some time back on the SR YANG model. :-)

At that time we agreed that SRGB logically belongs at global scope - though there are some use cases where we may want per protocol SRGBs.

https://www.ietf.org/id/draft-ietf-spring-sr-yang-01.txt currently says (Section 3):

"SRGB (Segment Routing Global Block): Defines a list of label
      blocks represented by a pair of lower-bound/upper-bound labels.
      The SRGB is also agnostic to the control plane used.  So all
      routing-protocol instance will have to advertise the same SRGB."

This covers the vast majority of use cases (and lets please not use this thread to discuss the exception cases :-) ).

However, because we know there are use cases where the above may not be true, I would like not to prevent (or make more difficult) solutions to the cases where we need per protocol SRGBs. I think we get a significant benefit from doing per protocol validation - the implementation of that is much simpler than doing cross protocol validation - and we do not prevent the exception cases where we need per protocol SRGB from being supported in the future.

Does this seem fair to you?

   Les

> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Thursday, January 07, 2016 8:13 AM
> To: Les Ginsberg (ginsberg); DECRAENE Bruno IMT/OLN
> Cc: [email-masked]
> [Les:] I am not proposing that we do cross-protocol validation of SRGBs. This
> would indeed increase the complexity and I am not convinced we would gain
> much.
> [SLI] IMO, complexity of SRGB cross protocol validation  depends on how the
> implementation is done. The SRGB may or may not really be owned by the
> owned by SR that may do suballocation for a particular protocol. That really
> depends on how it has been coded. I'm not sure that in Cisco
> manager ? If "SR process" owns all the labels and just receive requests from
> protocols to reserve a particular SRGB, it has the global view and can manage
> overlap easily. For example, if user tries to configure a BGP SRGB that
> overlaps with ISIS SRGB, it can be easily refused by the SR process.
> 
> [Les:] I am not proposing that we do cross-protocol validation of SRGBs. This
> would indeed increase the complexity and I am not convinced we would gain
> much.
> the spring-conflict-resolution draft. Indeed one of the motivations for spring-
> conflict-resolution draft is to unblock the protocol drafts and isolate the
> conflict resolution to a single common draft. This means the protocol drafts
> MUST be agnostic and if they say anything at all it would be to reference
> spring-conflict-resolution draft.
> 
>    Les
> 
> 
> >

---

From: <[email-masked]>
Date: Fri, 8 Jan 2016 09:23:54 +0000

Hi Robert,

Regarding SRGB management, it’s really a design choice. There was already some discussion in the past.
If people/implementations uses a global SRGB which is agnostic to protocols, cross protocol validation does not really make sense.
If people/implementations uses per protocol SRGB, cross protocol validation makes sense.
I do not see a real use case for the partial overlapping between protocols.

I agree with you that using a common SRGB for all protocols works well and only SID conflict management in necessary in this case.

Brgds,

Stephane

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Thursday, January 07, 2016 17:19
To: LITKOWSKI Stephane SCE/OINIS
Cc: Les Ginsberg (ginsberg); DECRAENE Bruno IMT/OLN; [email-masked]
Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution

Hi Stephane,

> For example, if user tries to configure a BGP SRGB that

Can you elaborate why that would be a bad thing to have two protocols advertise even not partially overlapping but identical SRGB from a given node ?

Also while we are at the node doing the check during configuration let's do not forget that not all configurations these days are real time and inline. To add concepts of forward referencing are also used which may allow on purpose to configure overlapping blocks before even given IGP (or protocol in general) is activated on any interface.

Best,
r.

On Thu, Jan 7, 2016 at 5:12 PM, <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

-----Original Message-----
From: Les Ginsberg (ginsberg) [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, January 07, 2016 00:03
To: DECRAENE Bruno IMT/OLN; LITKOWSKI Stephane SCE/OINIS
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: draft-ginsberg-spring-conflict-resolution

Bruno -

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
> Cc: [email-masked]<mailto:[email-masked]>; Les Ginsberg (ginsberg)
> > To: DECRAENE Bruno IMT/OLN; [email-masked]<mailto:[email-masked]>; Les Ginsberg (ginsberg)

   Les

> > From: spring [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of
> > [email-masked]<mailto:[email-masked]>

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 8 Jan 2016 10:33:55 +0100

Hi,

So we agree that you can't write a draft to define SRGB errors as those are
local design choices. Done with that :)

As far as "SID conflict" I am not sure I would agree too ... if I can
tunnel to an anycast IP address why I can not tunnel to anycast SID -
configured as same on N different nodes ?

The only sort of error which I see so far to be detected is overlapping
ranges being advertised by single node and current trend is to detect it
during configuration. But is this really an error ? Why can't we just treat
overlapping ranges as such and once received construct a SRGB for a given
node out of those overlapping or not overlapping ranges ?

Cheers,
R.

On Fri, Jan 8, 2016 at 10:23 AM, <[email-masked]> wrote:

> If people/implementations uses a global SRGB which is agnostic to
> protocols, cross protocol validation does not really make sense.
>
> I agree with you that using a common SRGB for all protocols works well and
> only SID conflict management in necessary in this case.
>
>
>
> Brgds,
>
>
>
> Stephane
>
>
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Robert
> Raszuk
> *Sent:* Thursday, January 07, 2016 17:19
> *To:* LITKOWSKI Stephane SCE/OINIS
> *Cc:* Les Ginsberg (ginsberg); DECRAENE Bruno IMT/OLN; [email-masked]
> *Subject:* Re: [spring] draft-ginsberg-spring-conflict-resolution
>
>
>
> Hi Stephane,
>
>
>
> Also while we are at the node doing the check during configuration let's
> do not forget that not all configurations these days are real time and
> inline. To add concepts of forward referencing are also used which may
> allow on purpose to configure overlapping blocks before even given IGP (or
> protocol in general) is activated on any interface.
>
>
>
> Best,
>
> r.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

---

From: <[email-masked]>
Date: Fri, 8 Jan 2016 09:35:55 +0000

Hi Les,

Yes we come back to the Yang discussion :)
I think the text you pointed is no more valid, as the consensus was to authorize per protocol configuration as a feature. I think we missed to update this definition part when we updated the model.

Here is the augmentation for ISIS :

augment /rt:routing/rt:routing-instance/rt:routing-protocols/rt:routing-protocol
        /isis:isis:
   +--rw segment-routing
   |  +--rw enabled?    boolean
   |  +--rw bindings
   |     +--rw advertise
   |     |  +--rw policies*   string
   |     +--rw receive?     boolean
   +--rw protocol-srgb {sr:protocol-srgb}?
      +--rw srgb* [lower-bound upper-bound]
         +--rw lower-bound    uint32
         +--rw upper-bound    uint32

Now, we may have some implementations using a common SRGB for all protocols, and some implementations that allows for per protocol SRGB. I would not go into the discussion on which one is an expection and which one is the most used (there are too few SR deployments today to say something about this and moreover they are tied to implementation limitations).

Anyway, as the choice of using one or the other option is a provider decision (design choice), I agree that it would be hard to guess from an implementation point of view what was the design choice and what consistency rule to apply (at least from a receiver point of view).

Best Regards,

Stephane

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

Stephane -

   Les

> [Les:] I am not proposing that we do cross-protocol validation of 
> SRGBs. This would indeed increase the complexity and I am not 
> convinced we would gain much.
> [SLI] IMO, complexity of SRGB cross protocol validation  depends on 
> how the implementation is done. The SRGB may or may not really be 
> owned by the protocol directly. Protocol just do the advertisement, 
> but SRGB may be owned by SR that may do suballocation for a particular 
> protocol. That really depends on how it has been coded. I'm not sure 
> that in Cisco implementation that ISIS requests label range directly 
> from the label manager ? If "SR process" owns all the labels and just 
> receive requests from protocols to reserve a particular SRGB, it has 
> the global view and can manage overlap easily. For example, if user 
> tries to configure a BGP SRGB that overlaps with ISIS SRGB, it can be easily refused by the SR process.
> 
> So we go back to the question of the requirements ... I think it would 
> be really helpful that the WG agree on the requirement before talking 
> about solutions.
> 
> 
> > [Bruno] This is already spelled out lines above "In case of 
> > conflicts, all the ranges advertised are invalidated and dropped."
> > [SR-IS-IS], a node MUST not advertise overlapping SRGB ranges. Hence 
> > a SRGB range conflict means a bug in the implementation of the originator.
> >
> > > But in case there is something going wrong and such advertisement 
> > > is received, routers must have a consistent behavior.
> > "These SRGB ranges are advertised by a single node. As per 
> > [SR-IS-IS], a node MUST not advertise overlapping SRGB ranges. Hence 
> > a SRGB range conflict means a bug in the implementation of the 
> > originator. However, bugs happen and we need a consistent error 
> > handling behaviour across the network to minimize mis-routing and to 
> > allow ingress to know the state of the network and act upon (e.g. reroute around the bug)"
> >
> > > drop all
> > > sounds the best option because as this might be a bug, nothing 
> > > says that the forwarding is correctly setup on the node sending 
> > > the bad
> > advertisement.
> >
> > of each option, in order to allow technical discussion, refinement 
> > and hopefully drive the discussion toward consensus.
> > Personally, as of today, I would favor either "Drop all" or "Drop 
> > from
> conflict".
> > The latter have the nice property that, assuming that the network 
> > was running correctly before, the issue is with the added SRGB range 
> > which may be expected to be added to allow for future growth. i.e. 
> > not currently
> used.
> > So this seems overkill to drop all traffic, for a SRGB range which 
> > has been added and is not even used by global SIDs.
> >
> >
> > - I'd rather avoid making the issue more complex, while we still 
> > can't agree on conflict resolution within a protocol.
> >
> 
> [Les:] I am not proposing that we do cross-protocol validation of 
> SRGBs. This would indeed increase the complexity and I am not 
> convinced we would gain much.
> > > On the LSR, we have more LFIB consumption but no traffic impact, 
> > > as we are creating multiple parallel LSPs towards the same destination.
> > conflict is that multiple MPLS FIB entries would be programmed for a 
> > single
> IP Prefix.
> > This has no impact on the traffic but use more MPLS FIB entries, 
> > which may or not be problematic  for the network equipments."
> >
> >
> > > - §3.2.2 :
> > > [SLI] As previous comment, we may need to mention the impact of 
> > > such conflict : inconsistent routing (even possible loops)  if 
> > > there is disagreement between routers (LSRs).
> >
> > Added in 3.2.2 (1 SID, multiple prefixes): " The consequences of 
> > this conflict is that in the absence of conflict resolution two IP 
> > prefixes would be forwarded to the same destination. If they are 
> > part of the same FEC (Forwarding Equivalent Class), this is not an issue.
> > options from a specification standpoint. So that those sections 
> > should be non controvertials.
> > From a technical standpoint, I agree with you and this is discussed 
> > in
> > 3.6.2 'Network operation"
> >
> > not acceptable that a single typo in a MS advertisement shut down 
> > half of the network.
> > >    [SLI] Maybe we need to remind that we already have a 
> > > tiebreaking rule between MS entries and Prefix SIDs :
> > >    mappings from one range to another for example. This discussion 
> > > is out
> of
> [Les:] I "think" you are referring to this text from the IS-IS draft 
> (Section
> 2.4.5):
> 
> This text should be removed - the protocol drafts should simply 
> reference the spring-conflict-resolution draft. Indeed one of the 
> motivations for spring- conflict-resolution draft is to unblock the 
> protocol drafts and isolate the conflict resolution to a single common 
> draft. This means the protocol drafts MUST be agnostic and if they say 
> anything at all it would be to reference spring-conflict-resolution draft.
> 
>    Les
> 
> 
> >
> > > - there are multiple small typo issues in SRGB examples : e.g. 
> > > Range
> > > 3: (500,
> > > BTW I still not happy with my text, but hopefully current text  
> > > (or at least the table of content) should be enough to give an 
> > > idea on the direction I have in mind.
> > >
> > > Thanks,
> > > Regards,
> > > Bruno
> > >
> > > __
> > > this case, I don't think that dropping all traffic to those SIDs 
> > > is a desirable
> option.
> > > understanding all the trade-off considered during the work. 
> > > Reading the operational requirements, given that the IGP 
> > > infrastructure is probably even more important than BGP for 
> > > network operators/clients/traffic, it may be worthwhile to read 
> > > BGP error handling operation requirements ( 
> > > ) Discussion with the people involved may help. FYI, as for me, 
> > > the point I learnt are:
> > > - when we detect an error on the receiving side, there is a bug. 
> > > In general, it's difficult to know whether the bug is on the 
> > > sending side or the
> > receiving side.
> > > Clearly, for the receiving side, the first reaction is to blame 
> > > the sending
> > side.
> > > For each error, it's useful to consider both options (i.e. error 
> > > may be on my/receiving side). And even if the error is on the 
> > > sending side, the receiver may run the same implementation (so 
> > > "sender is too buggy to live" may apply to your own implementation 
> > > i.e. the receiving
> > side).
> > > killing a session/transit node/prefix). In particular, there may 
> > > not be a single error but many (SIDs, source routers (especially 
> > > if the error is on the receiving side)). So it's useful to 
> > > consider that the decision may be
> > > exit points), more prefixes hence the cost of dropping one prefix 
> > > is relatively less important, two-way point to point signaling 
> > > channel, messages are flooded unchanged so people are less likely 
> > > to shoot the messenger and errors are less likely to be multiplied 
> > > during
> propagation....
> > >
> > > __
> > > "An
> > > assume that state of the art implementation will do it. Yet, I 
> > > don't think it should be considered as an excuse to avoid error 
> > > handling at the
> > protocol level.
> > > before committing/sending. e.g. If an operator configure a range 
> > > on the SRMS, and this ranges conflict with existing SID advertised 
> > > by other nodes, would you expect the implementation to detect such 
> > > normative (since the receiving side, is expected a specific 
> > > behavior from
> > > And speaking for myself, simplicity/efficiency/availability of 
> > > 100s networks running segment routing significantly out weight the 
> > > awareness of the network operator. And I don't support the idea 
> > > that the more traffic you kill, the easier and faster the error is resolved.
> > > If you need to raise an error, please do so! e.g. in logs, 
> > > syslogs, SNMP traps, netconf event notification... Dropping the 
> > > traffic is not providing more information, it is increasing the 
> > > pressure and hence the probability of quick erroneous actions. Not 
> > > to mention that as all services will run over packet networks, and 
> > > as there is a pressure to reduce costs we may have a single 
> > > converged network for
> all services.
> > > All approach requires conflicting entries to be identified. This 
> > > is not a drawback of the "preference algorithm"
> > >
> > > I'm not sure to get what is implied. As A and B conflicts and B 
> > > and C conflicts, with "ignore conflicting entries", I would assume 
> > > that all A, B, C be ignored, no? Or do you plan to ignore 
> > > conflicting entries until there is no conflict? In which case we 
> > > would only remove one of the two conflicting entries and end up 
> > > with a "preference" resolution 'and never drop both conflicting 
> > > entries since once we drop the first, there is no more conflict) 
> > > ___
> > >
> > >
> > >
> > >
> >
> > > etant susceptibles d'alteration, Orange decline toute 
> > > privileged information that may be protected by law; they should 
> > > not be distributed, used or copied without authorisation.

---

From: <[email-masked]>
Date: Fri, 8 Jan 2016 09:39:01 +0000

So we agree that you can't write a draft to define SRGB errors as those are local design choices. Done with that :)
[SLI] Yes, see my reply to Les ☺

As far as "SID conflict" I am not sure I would agree too ... if I can tunnel to an anycast IP address why I can not tunnel to anycast SID - configured as same on N different nodes ?
[SLI] Anycast SID is not a conflict because the IP prefix is the same.

Sent: Friday, January 08, 2016 10:34

Hi,

So we agree that you can't write a draft to define SRGB errors as those are local design choices. Done with that :)
[SLI] Yes, see my reply to Les ☺

As far as "SID conflict" I am not sure I would agree too ... if I can tunnel to an anycast IP address why I can not tunnel to anycast SID - configured as same on N different nodes ?
[SLI] Anycast SID is not a conflict.

The only sort of error which I see so far to be detected is overlapping ranges being advertised by single node and current trend is to detect it during configuration. But is this really an error ? Why can't we just treat overlapping ranges as such and once received construct a SRGB for a given node out of those overlapping or not overlapping ranges ?

Cheers,
R.

On Fri, Jan 8, 2016 at 10:23 AM, <[email-masked]<mailto:[email-masked]>> wrote:
Hi Robert,

Brgds,

Stephane

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Robert Raszuk
Sent: Thursday, January 07, 2016 17:19
To: LITKOWSKI Stephane SCE/OINIS
Cc: Les Ginsberg (ginsberg); DECRAENE Bruno IMT/OLN; [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution

Hi Stephane,

Best,
r.

-----Original Message-----
From: Les Ginsberg (ginsberg) [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, January 07, 2016 00:03
To: DECRAENE Bruno IMT/OLN; LITKOWSKI Stephane SCE/OINIS
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: draft-ginsberg-spring-conflict-resolution

Bruno -

   Les

Thank you.

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 8 Jan 2016 13:52:06 +0000

> On 8 Jan 2016, at 09:39, <[email-masked]> <[email-masked]> wrote:
> 

Taking a long term view why conflate anycast SID with an IP address? SIDs are instructions not addresses, and we may wish to use them to instruct well known operation in the network.

Stewart

---

From: <[email-masked]>
Date: Fri, 8 Jan 2016 14:09:32 +0000

Why not ... but in this case why also having Node-SID bound to a prefix ? Today Anycast and Node-SID are all a subcase of the IGP Prefix SID, so bound to a prefix.
I agree that there is no real need to bind them to a prefix as long as we can still compute the path towards the SID (now we inherit IP path). 

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]] 
Sent: Friday, January 08, 2016 14:52
To: LITKOWSKI Stephane SCE/OINIS
Cc: Robert Raszuk; Les Ginsberg (ginsberg); [email-masked]; DECRAENE Bruno IMT/OLN
Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution

Stewart

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 8 Jan 2016 15:25:39 +0100

Stephane,

IP addresses are not used in path computation. Those are just leaves. You
can easily compute topology by just using nodes and links without IP
addresses. SIDs should have semantics similar to IP address but presence of
one should not mandate or be in any way tight to the other.

Cheers,
R.

On Fri, Jan 8, 2016 at 3:09 PM, <[email-masked]> wrote:

> Why not ... but in this case why also having Node-SID bound to a prefix ?
> Today Anycast and Node-SID are all a subcase of the IGP Prefix SID, so
> bound to a prefix.
> I agree that there is no real need to bind them to a prefix as long as we
> can still compute the path towards the SID (now we inherit IP path).
>
> Taking a long term view why conflate anycast SID with an IP address? SIDs
> are instructions not addresses, and we may wish to use them to instruct
> well known operation in the network.
>
> Stewart
>
>

---

From: <[email-masked]>
Date: Mon, 11 Jan 2016 15:17:07 +0000

Fully agree but this is not the choice that has been made at the beginning. Do you want to propose a change ?

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Friday, January 08, 2016 15:26
To: LITKOWSKI Stephane SCE/OINIS
Cc: Stewart Bryant; Les Ginsberg (ginsberg); [email-masked]; DECRAENE Bruno IMT/OLN
Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution

Stephane,

IP addresses are not used in path computation. Those are just leaves. You can easily compute topology by just using nodes and links without IP addresses. SIDs should have semantics similar to IP address but presence of one should not mandate or be in any way tight to the other.

Cheers,
R.

On Fri, Jan 8, 2016 at 3:09 PM, <[email-masked]<mailto:[email-masked]>> wrote:
Why not ... but in this case why also having Node-SID bound to a prefix ? Today Anycast and Node-SID are all a subcase of the IGP Prefix SID, so bound to a prefix.
I agree that there is no real need to bind them to a prefix as long as we can still compute the path towards the SID (now we inherit IP path).

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Friday, January 08, 2016 14:52
To: LITKOWSKI Stephane SCE/OINIS
Cc: Robert Raszuk; Les Ginsberg (ginsberg); [email-masked]<mailto:[email-masked]>; DECRAENE Bruno IMT/OLN
Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution

> On 8 Jan 2016, at 09:39, <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>> wrote:
>

Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 11 Jan 2016 16:17:00 +0000

Actually SIDs should not have the semantics of an IP address.

They should have the semantics of an instruction. If you want
to make an analogy, that should be with a MPLS label. Where
some people think of a label as short hand for an address. If
a label could only be an address we could not have used them
to identify VPNs or to convey the more complex operation
associated with a pseudowire label.

It would pay dividends to get this right now else later we will
regret not being able to add some function to the architecture
because someone had built on the assumption that SID==Address.

- Stewart

On 11/01/2016 15:17, [email-masked] wrote:
>
> Fully agree but this is not the choice that has been made at the 
> beginning. Do you want to propose a change ?
>
> *From:[email-masked] [mailto:[email-masked]] *On Behalf Of 
> *Robert Raszuk
> *Sent:* Friday, January 08, 2016 15:26
> *Cc:* Stewart Bryant; Les Ginsberg (ginsberg); [email-masked]; 
> DECRAENE Bruno IMT/OLN
> IP addresses are not used in path computation. Those are just leaves. 
> You can easily compute topology by just using nodes and links without 
> IP addresses. SIDs should have semantics similar to IP address but 
> presence of one should not mandate or be in any way tight to the other.
>
> Cheers,
> R.
>
> On Fri, Jan 8, 2016 at 3:09 PM, <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
> Why not ... but in this case why also having Node-SID bound to a 
> prefix ? Today Anycast and Node-SID are all a subcase of the IGP 
> Prefix SID, so bound to a prefix.
> I agree that there is no real need to bind them to a prefix as long as 
> we can still compute the path towards the SID (now we inherit IP path).
>
> Cc: Robert Raszuk; Les Ginsberg (ginsberg); [email-masked] 
> <mailto:[email-masked]>; DECRAENE Bruno IMT/OLN
> > On 8 Jan 2016, at 09:39, <[email-masked] 
> <mailto:[email-masked]>> <[email-masked] 
> <mailto:[email-masked]>> wrote:
> >
> Taking a long term view why conflate anycast SID with an IP address? 
> SIDs are instructions not addresses, and we may wish to use them to 
> instruct well known operation in the network.
>
> Stewart
>
> 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;