Re: [spring] SID Conflict Resolution: A Simpler Proposal

[Marc Binderberger]

Hello Les,

I cannot help but thinking we get carried away with the SRMS ranges. For me 
the actual meaning of a range lays in it's expanded form; with this I mean

(, 10.1.1.1/32, 100, range 3) is expanded

10.1.1.1/32 -> SID 100
10.1.1.2/32 -> SID 101
10.1.1.3/32 -> SID 102


If you take it from the expanded form then we have the "Ignore overlap only". 
That is how I understand the phrase "per-prefix". I would prefer to discuss 
the prefix or SID conflict on this expanded, per-prefix basis. E.g. for the 
example

1. (150, 1.1.1.1/32 100 range 100)
2. (150, 1.1.1.1/32 500 range 2)

with the typo/mistake of 1.1.1.1 instead of 1.1.2.1 in the 2nd range I don't 
see why prefixes 1.1.1.3/32 - 1.1.1.100/32 should not be mapped to SIDs 102 - 
199. The conflict is for 1.1.1.1/32 and 1.1.1.2/32 alone and the question of 
conflict resolution is for these two prefixes alone.


Saying this, having a warning that these two ranges create a conflict would 
be a useful debugging information.


For the action, once a conflict based on the expanded form is detected: I 
would prefer to drop the traffic, i.e. in the example above

1.1.1.1/32 -> drop
1.1.1.2/32 -> drop

nor should there be any ingress label programmed for SIDs 100, 101, 500, 501.
But as I said in another email, as long as we can agree on a simple action - 
drop, strip all labels, do not program the prefix - and make it mandatory 
that all implementations support this one action then fine with me.



Regards, Marc




On Sun, 1 Jan 2017 17:15:18 +, Les Ginsberg (ginsberg) wrote:
> Mustapha –
>  
> Some responses inline, but I emphasize again that the most important issue 
> being discussed at the moment is what to do when conflicts are detected. 
> There are two proposals:
>  
> 1)Do not use the SIDs which are in conflict (“Ignore”)
> 2)Use some conflict resolution algorithm to choose how to use the 
> conflicting SIDs (“Ignore overlap only”)
>  
> I would encourage you and everyone else to comment on that.
>  
> If we choose #2 above then the specific preference rule (currently defined 
> in Section 3.3.4 of the draft) can be reviewed – but not much point in 
> doing so until we decide whether we are going to use a preference rule at 
> all.
>  
> From: Aissaoui, Mustapha (Nokia - CA) [mailto:mustapha.aissa...@nokia.com] 
> Sent: Friday, December 23, 2016 6:59 AM
> To: Les Ginsberg (ginsberg); spring@ietf.org
> Subject: RE: SID Conflict Resolution: A Simpler Proposal
>  
> Hi Les,
> I made some follow-up inline.
>  
> Regards,
> Mustapha.
>  
> From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] 
> Sent: Thursday, December 22, 2016 2:37 PM
> To: Aissaoui, Mustapha (Nokia - CA) ; 
> spring@ietf.org
> Subject: RE: SID Conflict Resolution: A Simpler Proposal
>  
> Mustapha -
>  
> From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Aissaoui, 
> Mustapha (Nokia - CA)
> Sent: Thursday, December 22, 2016 8:10 AM
> To: Les Ginsberg (ginsberg); spring@ietf.org
> Subject: Re: [spring] SID Conflict Resolution: A Simpler Proposal
>  
> Hi Les,
> I read slides 17-21 of the document you referenced below and I have the 
> following comments:
>  
> 1. Page 17, “Order Matters - Prefix vs SID Conflict”.
> When you perform resolution on  a per prefix basis, prefix conflicts are 
> naturally processed first followed by SID conflicts across different 
> prefixes. So the ordering issue described is only specific if you decided 
> to resolve conflicting SID entries outside of the natural prefix resolution 
> by a router. 
>  
> [Les:] What may seem “natural” to you might not to someone else. I don’t 
> care to debate that point. What is being illustrated here is that in order 
> to provide a normative specification that – if followed – guarantees 
> interoperability we have to specify the order in which conflicts are 
> processed otherwise different results may be obtained.
>  
> MA> I agree on the intent of specifying a procedure which achieves 
> interoperability. However, it seems to me this draft is ignoring the fact 
> that routers do per-prefix resolution and is trying to perform the SID 
> resolution outside of it.
> [Les2:] Section 3.2 of the draft details the types of conflicts which may 
> occur. These include:
>  
>   1)Prefix conflicts – different SIDs assigned to the same prefix
> 2)SID conflicts – multiple prefixes associated with the same SID
>  
> The term “pre-prefix resolution” suggests to me that you think all we 
> have to do is find all the SID advertisements associated with a given 
> prefix in order to determine whether we have a conflict or not. But that 
> only finds “prefix conflicts” – it does not find SID conflicts – and 
> both have to be dealt with.
> If you mean something else please clarify.
>  
> 2. Page 18, “Order Matters: Derived vs non-derived– prefix conflict”.
> It seems to me this issue is an artifact of the specific algorithm used to 
> resolve conflicts. Because the 

Re: [spring] SID Conflict Resolution: A Simpler Proposal

[Marc Binderberger]

mind-boggling discussion :-)

Hello SR experts.


Mustapha wrote

> I have the impression the authors are 
> trying to address SID conflict resolution outside of the natural per prefix 
> resolution on the router.

that was my thought too. From the routing protocol I deal with a prefix. Then 
I need to find the SID for the prefix to program my ingress/egress labels. If 
the mapping prefix -> SID has conflicting results _then_ I have a problem.


Or in other words:

1. (150, 1.1.1.1/32 100 range 100)
2. (150, 1.1.1.1/32 500 range 2)

would result in no mapping, following the new proposal. All due to a typo of 
1.1.1.1 instead of 1.1.2.1 in the 2nd mapping?  While I understand the 
algorithm I don't want to be the poor operator having my OSS screen full with 
alarms for 1.1.1.3..100 .


Btw, the "preference" field, what purpose does is serve?  Has this been 
introduced solely to tie-break conflicts?  So we have one more parameter that 
can be typo-d :-)
Or is there actually an application for it?


Robert wrote

> After mental reset I conclude that perhaps even the introduction of the 
> draft is questionable

That goes much further than what I had in mind ;-) but I wonder if we go too 
far. I still think it is useful to describe what is a conflict - and this way 
also saying what should not be mistaken for a conflict. The discussion about 
conflict-with-range vs. conflict-with-prefix seems useful to me.

My problem with the earlier drafts was more about the conflict 
resolution/reaction, I found it complex and too specific to generally agree 
on. My personal opinion is when you have a conflict then _drop_ the prefix 
traffic. But quite frankly "dropping", "not programming", "strip to IP" or 
whatever else, they are all simple operations. Or simple code path, as 
Stewart put it, as long as we stick to _one_ of them. The draft should demand 
one particular operation to be a MUST for interoperability.



Regards, Marc









On Fri, 23 Dec 2016 15:24:55 +, Aissaoui, Mustapha (Nokia - CA) wrote:
> Hi Robert,
> In fact you are touching on the point I am trying to make in my comment (1) 
> on the slides. Reading this draft, I have the impression the authors are 
> trying to address SID conflict resolution outside of the natural per prefix 
> resolution on the router. While in theory this can be done but it makes the 
> algorithm much more complex trying to compare overlapping SRMS SID entries 
> with different range sizes.
>  
> There are two sources of advertisement of the SID information:
> a. Per-prefix SID entries received in the  prefix SID sub-TLV within a 
> Prefix TLV (IS-IS IP Reach TLV or OSPF Extended Prefix TLV). 
> b. SRMS entries which advertise SID information for a range of prefixes.
>  
> The range size of the SRMS entry entirely depends on how the user wants to 
> advertise the information and has no meaning for the resolution. From a 
> router’s perspective, the SID information is associated with a prefix 
> regardless how it is advertised. 
>  
> The per-prefix SID information is preferred to the SRMS SID information. 
> And thus a simple algorithm which at the top level selects the SID among 
> set (a) based on the source advertising router and if empty selects the SID 
> among set (b) based on the SRMS preference and then based on the SRMS 
> router-id if same preference will work.  
>  
> Regards,
> Mustapha.
>  
> From: rras...@gmail.com [mailto:rras...@gmail.com] On Behalf Of Robert 
> Raszuk
> Sent: Thursday, December 22, 2016 5:29 PM
> To: Les Ginsberg (ginsberg) 
> Cc: Aissaoui, Mustapha (Nokia - CA) ; 
> spring@ietf.org
> Subject: Re: [spring] SID Conflict Resolution: A Simpler Proposal
>  
> Les,
>  
> After mental reset I conclude that perhaps even the introduction of the 
> draft is questionable as in real life it applies to be quite an unrealistic 
> scenario to have a situation where more then one protocol is used *in the 
> same time* as active in forwarding for an exact same IP prefix. 
>  
> Last time I checked SIDs are meaningless without a prefix they are attached 
> to and it is a prefix they accompany to indicate which SID should be used 
> on a given node. 
>  
> Therefor if you consider that today most implementations pretty well can 
> handle overlapping prefixes from multiple sources what real problem is this 
> draft solving ? 
>  
> Are you trying to create a forwarding graph by SIDs only detaching them 
> from IP prefixes all together ?
>  
> Cheers,
> R.
>  
>  
> On Thu, Dec 22, 2016 at 10:32 PM, Les Ginsberg (ginsberg) 
>  wrote:
>> Robert –
>>  
>> You have a complete misunderstanding of roles here.
>>  
>> How the owner of a route may be represented in the RIB isn’t impacted by 
>> SRMS or conflict resolution. Nor is the determination of which route is 
>> the best route. We are only determining whether to use or not use a SID 
>> which was associated with the prefix by some 

Re: [spring] draft-ietf-spring-conflict-resolution - Preference Rule

[Marc Binderberger]

Hello Bruno,

thanks for the detailed reply and apology for my late response.


First, let me re-phrase what I propose. Realized that I never explained 
exactly what I had in mind and using the "ignore" keyword was just a bad idea 
too. Will avoid "ignore" as this keyword has been used in different ways 
already.

So what I propose is: if a prefix has conflicting mapping information - 
prefix or SID conflict - then keep this prefix unlabeled. [1]

I don't see that draft-ietf-spring-conflict-resolution is exactly covering 
this idea.



Then:

> But I'm not sure that you are really calling for the network operator to 
> have this flexibility.

I actually do expect requests from network operators to implement their 
specific view on how to operate the network into the conflict algorithm. The 
protocol design should allow for it.

But there are also network operators who prefer to keep the network 
relatively "dumb" and implement their operational logic into their OSS 
systems. I don't see why vendors would want to impose the more complex logic 
on customers not asking or not wanting it. Which is why I argue against the 
idea to make the preference algorithm "the" standard.

(yes, "simple" or "dumb" allows for interpretation. I'm sure you get the 
point though)


Saying all this, of course we should support the request from Orange and 
others for the preference algorithm. We do have the "algorithm" field, e.g. 
draft-ietf-isis-segment-routing-extensions, that could carry the 
SPF+conflict+... algorithm required.



There was also a misunderstanding about my "solving a problem that should be 
rare" statement. I said it with a qualifier "with the quoted rule above" and 
the rule was

   "Local configuration conflicts can be prevented before they are advertised"

If implementations check for a conflict between what they want to advertise 
and what is already advertised by others in the network then we filter out 
conflicts from config change that is happening after a time window of e.g. 
several seconds since the last SR config change in the network. Not saying 
this is a fool-proof algorithm but it puts a perspective on the problem.


> Basically, what I propose is to keep it safe, and not introduce new risks

sorry but I disagree. I cannot name customers but there are network operators 
who consider code complexity that they don't need a risk.



To summarize: I see your point for the preference algorithm but I disagree 
that this should be "the" standard behaviour of Segment Routing 
implementations. Rather we should allow for different algorithm. To have 
basic interoperability I propose the algorithm [1] above as a starting point. 
Other algorithm can be defined within IETF if network operators are 
interested in - we obviously have one algorithm with interest already :-)


Best regards,
Marc




On Tue, 30 Aug 2016 17:08:24 +, bruno.decra...@orange.com wrote:
> Hello Marc,
> 
> Speaking as an individual contributor, and network operator.
> 
> Please see inline.
> 
>> From: Marc Binderberger [mailto:m...@sniff.de] > Sent: Tuesday, August 09, 
>> 2016 9:56 AM
>> 
>> Hello Bruno and spring list experts,
>> 
>> jumping late into the discussion (sorry).
> 
> Thanks for the feedback.
>  
>> 
>> I would see any kind of preference list to handle a conflict to be an
>> somewhat arbitrary decision.
> 
> Agreed.
> Stéphane has proposed the addition of a "preference" field attached to 
> mapping server (advertisements) to allow a network operator to control this 
> preference decision, depending on SP rules or current network status (e.g. 
> migrations)
> To increase this capacity for customization, I guess that an option would 
> be to extend this preference to other SID advertisements.
> But I'm not sure that you are really calling for the network operator to 
> have this flexibility. So I don't think that this comment is really the 
> point that you want to make.
> 
>> That is okay for a particular network (assuming
>> the network operator had a word or two about the rules) but I don't 
>> consider
>> this a good idea for a standard to reflect specific designs or
>> operational/troubleshooting procedures.
>> 
>> E.g. who is saying that IPv6 should be preferred over IPv4?
> 
> The working group.
> You are welcome to contribute. IIRC, this specific point has already been 
> changed based on WG feedback.
> 
>> What when the
>> operator's workhorse is still IPv4 traffic and s/he would prefer to 
>> sacrifice
>> IPv6 to keep IPv4 running?
>> 
>> 
>> In reality, don't we expect the rule ...
>> 
>>"Local configuration conflicts can be prevented befor