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

[Les Ginsberg (ginsberg)]

Robert -

From: rras...@gmail.com [mailto:rras...@gmail.com] On Behalf Of Robert Raszuk
Sent: Friday, December 09, 2016 2:00 PM
To: Les Ginsberg (ginsberg)
Cc: Van De Velde, Gunter (Nokia - BE); spring@ietf.org
Subject: Re: [spring] SID Conflict Resolution: A Simpler Proposal

Dear Les,

> This is the problem conflict resolution is trying to address.

The problem description is very clear.

IMO what router should do in this case is (depending on it's location)

a) not to install ANY label and only install IP routes.

[Les:] That is precisely what the Ignore policy will do.

b) install 100 and point it to IP switching paths to both 
1.1.1.1/32 & 2.2.2.2/32


If/when MPLS/SR forwarding will fail and the best we can do is not only to 
properly (sys)log it, but define a new ICMP error type which would attempt to 
inform the sender that SR path broke at that point in the network due to 
conflicting SID entries being detected and suppressed from entering LFIB.

In general SID Conflict Detection and proper signalling should be our focus 
here rather then guessing what should be the right automated/algorithmic way to 
hide and try to mitigate the real problem.
[Les:] Excellent – we are in agreement !

Les


Simple analogy would be of using static routes with static MPLS labels. I can 
assure you that there are legitimate valid use cases where loop get's enforced 
by configuration.

As a matter of fact those are done in production for link quality tests. Also I 
can have same label bound to N number of prefixes at ultimate node (with PHP 
disabled) such that packets received with label 100 will get ECMP to all of 
those N destinations. Let's observe that SR does not require to be deployed 
domain or AS wide in number of network topologies.

Kind regards,
R.


On Fri, Dec 9, 2016 at 10:43 PM, Les Ginsberg (ginsberg) 
> wrote:
Gunter –

It is a misunderstanding to think that conflict resolution of ANY FLAVOR 
affects the best path selection/installation. This is simply not the case.

We are talking about an MPLS forwarding plane which uses labels which are 
globally scoped. (The fact that the label is represented as an index into a 
router specific SRGB is not relevant).
If we have a conflict then a given label can be associated with multiple 
prefixes – here is one example:

1.1.1.1/32 index 100
2.2.2.2/32 index 100

If I choose to use index 100 for 1.1.1.1/32 – but my 
neighbor chooses to use index 100 for 2.2.2.2/32 – then when 
I encapsulate a packet addressed to 1.1.1.1 and forward it to my neighbor it 
will get sent in the direction of 2.2.2.2.
This is the problem conflict resolution is trying to address.

As regards “ignore overlap only” complexity, I repeat my earlier reply to Bruno:

“If you want to argue that these are solvable problems I won’t disagree with 
you – it is a question of where we want to put our time and effort. A number of 
folks are commenting that they prefer to focus on fixing the configuration and 
not invest  time in validating that conflict resolution is implemented in an 
interoperable way. As we (the authors) have stated from the beginning, we 
believe the emphasis should be on detecting and reporting the conflicts – not 
spending cycles implementing the most robust means of trying to operate 
optimally while the misconfiguration exists.”

   Les


From: Van De Velde, Gunter (Nokia - BE) 
[mailto:gunter.van_de_ve...@nokia.com]
Sent: Friday, December 09, 2016 12:11 PM
To: Les Ginsberg (ginsberg); spring@ietf.org
Subject: Re: [spring] SID Conflict Resolution: A Simpler Proposal

The method to “maximize forwarding” as mentioned in the draft seems to be in 
consistent logic with how the current
unicast routing table is build. For unicast routes the route selected for a 
given IP destination address is a function(prefix-length/admin-distance).
This is done for better address space management, and to have predictable 
routing incase of clashes in the routing table. Hence, to me, it seems only 
natural to
to keep promoting "ignore overlap only" as result as it mimics traditional 
unicast routing table constructs.

The alternative sounds a bit like stepping back to Class A/B/C addresses by 
just avoiding the problem and significantly impact potential clash scenarios as 
consequence due to oversimplification.

Finally, I do not understand the reasoning behind the sudden worry regarding 
"ignore overlap only" policy to be obscenely complex. If I understand IETF 
procedures well, and if
 “ignore overlap only” is documented properly, just like any standard track RFC 
should be, then how are incompatible behaviours possible? Should we not try to 
architect for
the BEST realistic future proof solution, and not for the easiest less optimal 
solution. (Keep in mind that at some 

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

[Les Ginsberg (ginsberg)]

Gunter –

It is a misunderstanding to think that conflict resolution of ANY FLAVOR 
affects the best path selection/installation. This is simply not the case.

We are talking about an MPLS forwarding plane which uses labels which are 
globally scoped. (The fact that the label is represented as an index into a 
router specific SRGB is not relevant).
If we have a conflict then a given label can be associated with multiple 
prefixes – here is one example:

1.1.1.1/32 index 100
2.2.2.2/32 index 100

If I choose to use index 100 for 1.1.1.1/32 – but my neighbor chooses to use 
index 100 for 2.2.2.2/32 – then when I encapsulate a packet addressed to 
1.1.1.1 and forward it to my neighbor it will get sent in the direction of 
2.2.2.2.
This is the problem conflict resolution is trying to address.

As regards “ignore overlap only” complexity, I repeat my earlier reply to Bruno:

“If you want to argue that these are solvable problems I won’t disagree with 
you – it is a question of where we want to put our time and effort. A number of 
folks are commenting that they prefer to focus on fixing the configuration and 
not invest  time in validating that conflict resolution is implemented in an 
interoperable way. As we (the authors) have stated from the beginning, we 
believe the emphasis should be on detecting and reporting the conflicts – not 
spending cycles implementing the most robust means of trying to operate 
optimally while the misconfiguration exists.”

   Les


From: Van De Velde, Gunter (Nokia - BE) [mailto:gunter.van_de_ve...@nokia.com]
Sent: Friday, December 09, 2016 12:11 PM
To: Les Ginsberg (ginsberg); spring@ietf.org
Subject: Re: [spring] SID Conflict Resolution: A Simpler Proposal

The method to “maximize forwarding” as mentioned in the draft seems to be in 
consistent logic with how the current
unicast routing table is build. For unicast routes the route selected for a 
given IP destination address is a function(prefix-length/admin-distance).
This is done for better address space management, and to have predictable 
routing incase of clashes in the routing table. Hence, to me, it seems only 
natural to
to keep promoting "ignore overlap only" as result as it mimics traditional 
unicast routing table constructs.

The alternative sounds a bit like stepping back to Class A/B/C addresses by 
just avoiding the problem and significantly impact potential clash scenarios as 
consequence due to oversimplification.

Finally, I do not understand the reasoning behind the sudden worry regarding 
"ignore overlap only" policy to be obscenely complex. If I understand IETF 
procedures well, and if
 “ignore overlap only” is documented properly, just like any standard track RFC 
should be, then how are incompatible behaviours possible? Should we not try to 
architect for
the BEST realistic future proof solution, and not for the easiest less optimal 
solution. (Keep in mind that at some point in time people believed that doing 
routing in the
style of Class A/B/C was the future also, and see where we are right now).

G/



From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Les Ginsberg 
(ginsberg)
Sent: Sunday, December 04, 2016 7:04 PM
To: spring@ietf.org
Subject: [spring] SID Conflict Resolution: A Simpler Proposal


When the problem addressed by draft-ietf-spring-conflict-resolution was first

presented at IETF 94, the authors defined the following priorities:



1)Detect the problem

2)Report the problem

This alerts the network operator to the existence of a conflict so that

the configuration error can be corrected.

3)Define consistent behavior

This avoids mis-forwarding while the conflict exists.

4)Don’t overengineer the solution

Given that it is impossible to know which of the conflicting entries

is the correct one, we should apply a simple algorithm to resolve the conflict.

5)Agree on the resolution behavior



The resolution behavior was deliberately the last point because it was

considered the least important.



Input was received over the past year which emphasized the importance of

trying to "maximize forwarding" in the presence of conflicts. Subsequent

revisions of the draft have tried to address this concern. However the authors

have repeatedly stressed that the solution being proposed

("ignore overlap only") was more complex than other offered alternatives and

would be more difficult to guarantee interoperability because subtle

differences in an implementation could produce different results.



At IETF97 significant feedback was received preferring a simpler solution to

the problem. The authors are very sympathetic to this feedback and therefore

are proposing a solution based on what the draft defines as the "Ignore"

policy - where all entries which are in conflict are ignored. We believe this

is far more desirable and aligns with the priorities listed above.



We outline the proposed solution below and would like to receive feedback from

the WG before 

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

[Van De Velde, Gunter (Nokia - BE)]

The method to “maximize forwarding” as mentioned in the draft seems to be in 
consistent logic with how the current
unicast routing table is build. For unicast routes the route selected for a 
given IP destination address is a function(prefix-length/admin-distance).
This is done for better address space management, and to have predictable 
routing incase of clashes in the routing table. Hence, to me, it seems only 
natural to
to keep promoting "ignore overlap only" as result as it mimics traditional 
unicast routing table constructs.

The alternative sounds a bit like stepping back to Class A/B/C addresses by 
just avoiding the problem and significantly impact potential clash scenarios as 
consequence due to oversimplification.

Finally, I do not understand the reasoning behind the sudden worry regarding 
"ignore overlap only" policy to be obscenely complex. If I understand IETF 
procedures well, and if
 “ignore overlap only” is documented properly, just like any standard track RFC 
should be, then how are incompatible behaviours possible? Should we not try to 
architect for
the BEST realistic future proof solution, and not for the easiest less optimal 
solution. (Keep in mind that at some point in time people believed that doing 
routing in the
style of Class A/B/C was the future also, and see where we are right now).

G/



From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Les Ginsberg 
(ginsberg)
Sent: Sunday, December 04, 2016 7:04 PM
To: spring@ietf.org
Subject: [spring] SID Conflict Resolution: A Simpler Proposal


When the problem addressed by draft-ietf-spring-conflict-resolution was first

presented at IETF 94, the authors defined the following priorities:



1)Detect the problem

2)Report the problem

This alerts the network operator to the existence of a conflict so that

the configuration error can be corrected.

3)Define consistent behavior

This avoids mis-forwarding while the conflict exists.

4)Don’t overengineer the solution

Given that it is impossible to know which of the conflicting entries

is the correct one, we should apply a simple algorithm to resolve the conflict.

5)Agree on the resolution behavior



The resolution behavior was deliberately the last point because it was

considered the least important.



Input was received over the past year which emphasized the importance of

trying to "maximize forwarding" in the presence of conflicts. Subsequent

revisions of the draft have tried to address this concern. However the authors

have repeatedly stressed that the solution being proposed

("ignore overlap only") was more complex than other offered alternatives and

would be more difficult to guarantee interoperability because subtle

differences in an implementation could produce different results.



At IETF97 significant feedback was received preferring a simpler solution to

the problem. The authors are very sympathetic to this feedback and therefore

are proposing a solution based on what the draft defines as the "Ignore"

policy - where all entries which are in conflict are ignored. We believe this

is far more desirable and aligns with the priorities listed above.



We outline the proposed solution below and would like to receive feedback from

the WG before publishing the next revision of the draft.



   Les (on behalf of the authors)



New Proposal



In the latest revision of the draft "SRMS Preference" was introduced. This

provides a way for a numerical preference to be explicitly associated with an

SRMS advertisement. Using this an operator can indicate which advertisement is

to be preferred when a conflict is present. The authors think this is a useful

addition and we therefore want to include this in the new solution.



The new preference rule used to resolve conflicts is defined as follows:



A given mapping entry is compared against all mapping entries in the database

with a preference greater than or equal to its own. If there is a conflict,

the mapping entry with lower preference is ignored. If two mapping entries are

in conflict and have equal preference then both entries are ignored.



Implementation of this policy is defined as follows:



Step 1: Within a single address-family/algorithm/topology sort entries

based on preference

Step 2: Starting with the lowest preference entries, resolve prefix conflicts

using the above preference rule. The output is an active policy per topology.

Step 3: Take the outputs from Step 2 and again sort them by preference

Step 4: Starting with the lowest preference entries, resolve SID conflicts

using the above preference rule



The output from Step 4 is then the current Active Policy.



Here are a few examples. Each mapping entry is represented by the tuple:

(Preference, Prefix/mask Index range <#>)



Example 1:



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

2. (149, 1.1.1.10/32 200 range 200)

3. (148, 1.1.1.101/32 500 range 10)



Entry 3 conflicts with entry 2, it is ignored.

Entry 2 conflicts with 

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

[Les Ginsberg (ginsberg)]

Mustapha -

From: Aissaoui, Mustapha (Nokia - CA) [mailto:mustapha.aissa...@nokia.com]
Sent: Friday, December 09, 2016 7:44 AM
To: Les Ginsberg (ginsberg); spring@ietf.org
Subject: RE: SID Conflict Resolution: A Simpler Proposal

I have a couple of comments on the below proposal.


1. Regarding the SRMS Preference Sub-TLV in section 3.1 of the draft. In 
many cases, a configuration on the resolving router can assign a preference to 
each SRMS in case there is no advertisement of this sub-TLV or to override an 
advertised value. I propose that this option be allowed. Here is a proposed 
update to the relevant paragraph:

"
   Advertisement of a preference value is optional.  Nodes which do not
  advertise a preference value are assigned a preference value of 128.
   A resolving router can override the default or the advertised value 
by local policy.

"

[Les:] In order to get consistent conflict resolution on all nodes in the 
network, it is necessary that they all have the same database - which includes 
the preference value. If you allow local policy to modify the preference you no 
longer have consistent databases on all nodes and we can no longer guarantee 
consistent conflict resolution. So your proposal is not viable IMO.



2. I am trying to understand the concept of sorting SRMS entries which have 
different prefixes and different range sizes.

Since a SID advertised in a prefix SID sub-TLV within a Prefix TLV (IS-IS IP 
Reach TLV or OSPF Extended Prefix TLV) has higher priority over a SID for the 
same prefix advertised from a SRMS, then you have to add to the below sorting 
an entry for each individual prefix which advertised a prefix SID sub-TLV 
within a prefix TLV.

At this point, the concept of an entry with multiple prefixes is moot and you 
may as well just sort on a per prefix basis which is the most natural thing to 
do given that the prefix resolution and then the SID resolution are performed 
on a per prefix basis. SID conflicts can be resolved on a per prefix basis 
using the below proposed preference algorithm without having to ignore SID 
values for unrelated prefixes just because it happens that they were advertised 
in the same SRMS entry.



[Les:] The simpler proposal does not require sorting on anything other than 
preference. After that, you can process entries in any order you want and you 
will get the same answer.

With "Ignore Overlap Only" one of the issues with trying to use the 
non-conflicting portions of a mapping entry which has a range > 1 is that the 
order in which you process entries influences the result. Please see slides 17 
- 20 from the IETF97 presentation: 
https://www.ietf.org/proceedings/97/slides/slides-97-spring-1_ietf97_draft-ietf-spring-conflict-resolution-02-00.pptx
 for some simple examples of this.



   Les



Regards,
Mustapha.

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Les Ginsberg 
(ginsberg)
Sent: Sunday, December 04, 2016 7:04 PM
To: spring@ietf.org
Subject: [spring] SID Conflict Resolution: A Simpler Proposal


When the problem addressed by draft-ietf-spring-conflict-resolution was first

presented at IETF 94, the authors defined the following priorities:



1)Detect the problem

2)Report the problem

This alerts the network operator to the existence of a conflict so that

the configuration error can be corrected.

3)Define consistent behavior

This avoids mis-forwarding while the conflict exists.

4)Don't overengineer the solution

Given that it is impossible to know which of the conflicting entries

is the correct one, we should apply a simple algorithm to resolve the conflict.

5)Agree on the resolution behavior



The resolution behavior was deliberately the last point because it was

considered the least important.



Input was received over the past year which emphasized the importance of

trying to "maximize forwarding" in the presence of conflicts. Subsequent

revisions of the draft have tried to address this concern. However the authors

have repeatedly stressed that the solution being proposed

("ignore overlap only") was more complex than other offered alternatives and

would be more difficult to guarantee interoperability because subtle

differences in an implementation could produce different results.



At IETF97 significant feedback was received preferring a simpler solution to

the problem. The authors are very sympathetic to this feedback and therefore

are proposing a solution based on what the draft defines as the "Ignore"

policy - where all entries which are in conflict are ignored. We believe this

is far more desirable and aligns with the priorities listed above.



We outline the proposed solution below and would like to receive feedback from

the WG before publishing the next revision of the draft.



   Les (on behalf of the authors)



New Proposal



In the latest revision of the draft "SRMS Preference" was introduced. This

provides a way 

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

[Les Ginsberg (ginsberg)]

Bruno -

Welcome back to the discussion. :)
Inline.

From: bruno.decra...@orange.com [mailto:bruno.decra...@orange.com]
Sent: Friday, December 09, 2016 2:07 AM
To: Les Ginsberg (ginsberg)
Cc: spring@ietf.org
Subject: RE: SID Conflict Resolution: A Simpler Proposal

Hi Les,

As a individual contributor, please find below some clarification questions 
[Bruno]

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Les Ginsberg 
(ginsberg)
Sent: Monday, December 05, 2016 1:04 AM
To: spring@ietf.org
Subject: [spring] SID Conflict Resolution: A Simpler Proposal


When the problem addressed by draft-ietf-spring-conflict-resolution was first

presented at IETF 94, the authors defined the following priorities:



1)Detect the problem

2)Report the problem

This alerts the network operator to the existence of a conflict so that

the configuration error can be corrected.

3)Define consistent behavior

This avoids mis-forwarding while the conflict exists.

4)Don't overengineer the solution

Given that it is impossible to know which of the conflicting entries

is the correct one, we should apply a simple algorithm to resolve the conflict.

5)Agree on the resolution behavior



The resolution behavior was deliberately the last point because it was

considered the least important.



Input was received over the past year which emphasized the importance of

trying to "maximize forwarding" in the presence of conflicts. Subsequent

revisions of the draft have tried to address this concern. However the authors

have repeatedly stressed that the solution being proposed

("ignore overlap only") was more complex than other offered alternatives and

would be more difficult to guarantee interoperability because subtle

differences in an implementation could produce different results.



At IETF97 significant feedback was received preferring a simpler solution to

the problem. The authors are very sympathetic to this feedback and therefore

are proposing a solution based on what the draft defines as the "Ignore"

policy - where all entries which are in conflict are ignored. We believe this

is far more desirable and aligns with the priorities listed above.



[Bruno] In the draft, the "Ignore" policy (§3.3.1) ignores all conflicting 
entries.

In your below proposition, the policy seems to pick the most preferred entry. 
This looks like more similar to the "Quarantine" policy proposed in the draft 
(§3.3.2)

Am I missing something?



[Les:] At the time "Ignore" was introduced (over a year ago) the notion of 
"SRMS preference" did not exist - that was only added in the most recent 
version of the draft.

We (the authors) feel that this is a useful construct because:



1)It provides an explicit basis on which to choose between conflicting entries.

2)It is particularly useful when bringing up a new SRMS as it allows the 
advertised values to be verified before they are used.



So, your comment is correct in that there is now a preference algorithm in use 
- whereas with the original definition of "Ignore" there was no preference 
algorithm. But the sole criteria of the preference rule is the explicitly 
configured preference - none of the other criteria proposed for Quarantine are 
used - and in particular we do not make partial use of a mapping entry as is 
the case with "Ignore Overlap Only".



I am happy to modify the nomenclature - but the point of this thread is not to 
replace a new draft revision - it is to get the sense of the WG before we 
publish a new revision as to whether we should continue down the "Ignore 
Overlap only" path or move to a simpler strategy - so let's not be too picky 
about the naming.



We outline the proposed solution below and would like to receive feedback from

the WG before publishing the next revision of the draft.



   Les (on behalf of the authors)



New Proposal



In the latest revision of the draft "SRMS Preference" was introduced. This

provides a way for a numerical preference to be explicitly associated with an

SRMS advertisement. Using this an operator can indicate which advertisement is

to be preferred when a conflict is present. The authors think this is a useful

addition and we therefore want to include this in the new solution.



The new preference rule used to resolve conflicts is defined as follows:



A given mapping entry is compared against all mapping entries in the database

with a preference greater than or equal to its own. If there is a conflict,

the mapping entry with lower preference is ignored. If two mapping entries are

in conflict and have equal preference then both entries are ignored.



Implementation of this policy is defined as follows:



Step 1: Within a single address-family/algorithm/topology sort entries

based on preference

[Bruno] I'm not sure what you are refering to by "preference". Is this the IGP 
"SRMS Preference sub-TLV" or is this the preference defined in the draft 
(§3.3.4)?



[Les:] It is the former.



Assuming you meant the 

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

[Aissaoui, Mustapha (Nokia - CA)]

I have a couple of comments on the below proposal.


1. Regarding the SRMS Preference Sub-TLV in section 3.1 of the draft. In 
many cases, a configuration on the resolving router can assign a preference to 
each SRMS in case there is no advertisement of this sub-TLV or to override an 
advertised value. I propose that this option be allowed. Here is a proposed 
update to the relevant paragraph:

"
   Advertisement of a preference value is optional.  Nodes which do not
  advertise a preference value are assigned a preference value of 128.
   A resolving router can override the default or the advertised value 
by local policy.

"



2. I am trying to understand the concept of sorting SRMS entries which have 
different prefixes and different range sizes.

Since a SID advertised in a prefix SID sub-TLV within a Prefix TLV (IS-IS IP 
Reach TLV or OSPF Extended Prefix TLV) has higher priority over a SID for the 
same prefix advertised from a SRMS, then you have to add to the below sorting 
an entry for each individual prefix which advertised a prefix SID sub-TLV 
within a prefix TLV.

At this point, the concept of an entry with multiple prefixes is moot and you 
may as well just sort on a per prefix basis which is the most natural thing to 
do given that the prefix resolution and then the SID resolution are performed 
on a per prefix basis. SID conflicts can be resolved on a per prefix basis 
using the below proposed preference algorithm without having to ignore SID 
values for unrelated prefixes just because it happens that they were advertised 
in the same SRMS entry.

Regards,
Mustapha.

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Les Ginsberg 
(ginsberg)
Sent: Sunday, December 04, 2016 7:04 PM
To: spring@ietf.org
Subject: [spring] SID Conflict Resolution: A Simpler Proposal


When the problem addressed by draft-ietf-spring-conflict-resolution was first

presented at IETF 94, the authors defined the following priorities:



1)Detect the problem

2)Report the problem

This alerts the network operator to the existence of a conflict so that

the configuration error can be corrected.

3)Define consistent behavior

This avoids mis-forwarding while the conflict exists.

4)Don't overengineer the solution

Given that it is impossible to know which of the conflicting entries

is the correct one, we should apply a simple algorithm to resolve the conflict.

5)Agree on the resolution behavior



The resolution behavior was deliberately the last point because it was

considered the least important.



Input was received over the past year which emphasized the importance of

trying to "maximize forwarding" in the presence of conflicts. Subsequent

revisions of the draft have tried to address this concern. However the authors

have repeatedly stressed that the solution being proposed

("ignore overlap only") was more complex than other offered alternatives and

would be more difficult to guarantee interoperability because subtle

differences in an implementation could produce different results.



At IETF97 significant feedback was received preferring a simpler solution to

the problem. The authors are very sympathetic to this feedback and therefore

are proposing a solution based on what the draft defines as the "Ignore"

policy - where all entries which are in conflict are ignored. We believe this

is far more desirable and aligns with the priorities listed above.



We outline the proposed solution below and would like to receive feedback from

the WG before publishing the next revision of the draft.



   Les (on behalf of the authors)



New Proposal



In the latest revision of the draft "SRMS Preference" was introduced. This

provides a way for a numerical preference to be explicitly associated with an

SRMS advertisement. Using this an operator can indicate which advertisement is

to be preferred when a conflict is present. The authors think this is a useful

addition and we therefore want to include this in the new solution.



The new preference rule used to resolve conflicts is defined as follows:



A given mapping entry is compared against all mapping entries in the database

with a preference greater than or equal to its own. If there is a conflict,

the mapping entry with lower preference is ignored. If two mapping entries are

in conflict and have equal preference then both entries are ignored.



Implementation of this policy is defined as follows:



Step 1: Within a single address-family/algorithm/topology sort entries

based on preference

Step 2: Starting with the lowest preference entries, resolve prefix conflicts

using the above preference rule. The output is an active policy per topology.

Step 3: Take the outputs from Step 2 and again sort them by preference

Step 4: Starting with the lowest preference entries, resolve SID conflicts

using the above preference rule



The output from Step 4 is then the current Active Policy.



Here are a few examples. 

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

[bruno.decraene]

Hi Les,

As a individual contributor, please find below some clarification questions 
[Bruno]

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Les Ginsberg 
(ginsberg)
Sent: Monday, December 05, 2016 1:04 AM
To: spring@ietf.org
Subject: [spring] SID Conflict Resolution: A Simpler Proposal


When the problem addressed by draft-ietf-spring-conflict-resolution was first

presented at IETF 94, the authors defined the following priorities:



1)Detect the problem

2)Report the problem

This alerts the network operator to the existence of a conflict so that

the configuration error can be corrected.

3)Define consistent behavior

This avoids mis-forwarding while the conflict exists.

4)Don't overengineer the solution

Given that it is impossible to know which of the conflicting entries

is the correct one, we should apply a simple algorithm to resolve the conflict.

5)Agree on the resolution behavior



The resolution behavior was deliberately the last point because it was

considered the least important.



Input was received over the past year which emphasized the importance of

trying to "maximize forwarding" in the presence of conflicts. Subsequent

revisions of the draft have tried to address this concern. However the authors

have repeatedly stressed that the solution being proposed

("ignore overlap only") was more complex than other offered alternatives and

would be more difficult to guarantee interoperability because subtle

differences in an implementation could produce different results.



At IETF97 significant feedback was received preferring a simpler solution to

the problem. The authors are very sympathetic to this feedback and therefore

are proposing a solution based on what the draft defines as the "Ignore"

policy - where all entries which are in conflict are ignored. We believe this

is far more desirable and aligns with the priorities listed above.



[Bruno] In the draft, the "Ignore" policy (§3.3.1) ignores all conflicting 
entries.

In your below proposition, the policy seems to pick the most preferred entry. 
This looks like more similar to the "Quarantine" policy proposed in the draft 
(§3.3.2)

Am I missing something?



We outline the proposed solution below and would like to receive feedback from

the WG before publishing the next revision of the draft.



   Les (on behalf of the authors)



New Proposal



In the latest revision of the draft "SRMS Preference" was introduced. This

provides a way for a numerical preference to be explicitly associated with an

SRMS advertisement. Using this an operator can indicate which advertisement is

to be preferred when a conflict is present. The authors think this is a useful

addition and we therefore want to include this in the new solution.



The new preference rule used to resolve conflicts is defined as follows:



A given mapping entry is compared against all mapping entries in the database

with a preference greater than or equal to its own. If there is a conflict,

the mapping entry with lower preference is ignored. If two mapping entries are

in conflict and have equal preference then both entries are ignored.



Implementation of this policy is defined as follows:



Step 1: Within a single address-family/algorithm/topology sort entries

based on preference

[Bruno] I'm not sure what you are refering to by "preference". Is this the IGP 
"SRMS Preference sub-TLV" or is this the preference defined in the draft 
(§3.3.4)?

Assuming you meant the SRMS preference, why limiting to this field, rather than 
including all fields defined in the draft preference algo?

Using the latter would reduce the risk of ignoring all entries (i.e. having no 
entry in output of this algo). Also a priori,  a sort would not be required as 
a single pass could select the most preferred entry.



Thanks

-- Bruno



Step 2: Starting with the lowest preference entries, resolve prefix conflicts

using the above preference rule. The output is an active policy per topology.

Step 3: Take the outputs from Step 2 and again sort them by preference

Step 4: Starting with the lowest preference entries, resolve SID conflicts

using the above preference rule



The output from Step 4 is then the current Active Policy.



Here are a few examples. Each mapping entry is represented by the tuple:

(Preference, Prefix/mask Index range <#>)



Example 1:



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

2. (149, 1.1.1.10/32 200 range 200)

3. (148, 1.1.1.101/32 500 range 10)



Entry 3 conflicts with entry 2, it is ignored.

Entry 2 conflicts with entry 1, it is ignored.

Active policy:



(150, 1.1.1.1/32 100 range 100)



Example 2:



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

2. (150, 1.1.1.10/32 200 range 200)

3. (150, 1.1.1.101/32 500 range 10)

4. (150, 2.2.2.1/32 1000 range 1)



Entry 1 conflicts with entry 2, both are marked as ignore.

Entry 3 conflicts with entry 2. It is marked as ignore.

Entry 4 has no conflicts with any entries



Active policy:

(150, 2.2.2.1/32 

Re: [spring] Conflict resolution - a plea for simplicity

[bruno.decraene]

Hi Stewart,

Thanks for your comments.
As an individual contributor, please find some comments inlined. [Bruno]

> From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Stewart Bryant  > 
> Sent: Friday, December 02, 2016 6:55 PM
> 
 > There was some discussion on the conflict resolution draft at IETF97
 > that got cut off with a request to discuss on the list.
 > 
 > As I understand the situation, we have a misconfiguration in the network,
 > and we are being encouraged to take an essentially aggressive strategy
 > of picking one of the configurations and assuming that must be right
 > in order to continue forwarding traffic. It seems to me that we are
 > tossing a coin here and whilst we could be sending traffic the
 > right way we could also be sending it the wrong way with bad
 > consequences in terms of misdelivery or inducing congestion.

[Bruno]
You are correct that the draft handles a case of network/node misconfiguration, 
and that we are mostly tossing a coin to select one of the conflicting entries.
However I'm not seeing cases that would lead to misdelivery, misrouting or 
induced congestion:
- we are facing a case were e.g. one SID have been affected to the two 
different Segment/IP prefix/FEC.
- Those SID are just a number, locally allocated by the Autonomous System. 
Nobody cares much whether a given FEC uses the index 53 or 42. However, what we 
do need is that all nodes use the same value for a given FEC. Hence the needs 
for a determinist rule. This is the purpose of this draft.

If you see such misrouting, could you please elaborate on this? e.g. with an 
example.

 > The alternative strategy is to note the conflict and not believe either
 > router. This more conservative strategy seems the better approach for
 > a number of reasons:
 > 
 > 1) Traffic will not be misdelivered, or use unintended parts of the network.
 
[Bruno] IMO that's the case for both strategy. cf 1rst comment.
 
 > 2) Traffic,  was being routed via SR rather than simple shortest path
 > for a reason and so you should not try to guess the operators decision,
 > you should rigidly execute it.
 
[Bruno] IMO that's the case for both strategy. cf 1rst comment.
 
 > 3) It seems to me that the aggressive approach fails 7 of Ross Callons
 > Twelve truths (RFC1925). These were published on 1/April, but the real
 > joke is that they ARE useful truths, so forget about the date. 3,
 > 4, *5*, *6*, 8, probably 10, certainly 12.
 
[Bruno] They may be useful truths, but they are a bit too general to me. Not 
sure they will really help when discussing trade-off. 
One may add the robustness principle (RFC 3117, 761), especially since we are 
not even discussing a protocol error.
 
 > 4) Finally there is the protocol 101 rule stating that the exception
 > path MUST be simple, because it is rarely executed and thus often
 > hosts most of the bugs.
 
[Bruno] good point. Thanks.
 
 > Point 4 is particularly important. What we have in the draft is
 > complex and difficult to test on a live network, and yet it is
 > only there to take action when someone makes a mistake.
 > Exception code like this is usually the Cinderella in the
 > system, rushed in at the end of development and hardly tested.
 > 
 > It is usually by far the best approach to assert that the
 > misconfiguration should never happen,

[Bruno] In an ideal world, there would be no configuration error and no bug. 
But unfortunately, I'm not living in this world, so this is not a valid 
hypothesis for me. Hence the need for this document, so that a consistent 
behavior is picked.
(Eventually, in a world with no human (involved), although even God seems to 
play dice with the universe :-) )

> have a very simple test
 > do detect it and do something very simple by effective when
 > it is detected. Given that routing only works because
 > routers tell the truth, and clearly one or both of the routers
 > has breached that trust, the best approach is to trust neither.
 
[Bruno] It's not about truth, and we don't care whether a given segment is 
given a value/index of N or M. In case of conflict, we have a set of values 
advertised, and we need to pick one, deterministically, using a preference or 
tie-break mechanism. 
That does not seem very far, to me, from the use case described in our draft 
https://tools.ietf.org/html/draft-bryant-rtgwg-param-sync-00#section-5 where 
different nodes advertise different value in the IGP and all nodes need to 
select the same one, in a distributed way.
 
 > What is unclear to me is what to do with the traffic, i.e. do
 > you degrade it to the base path, or do you drop it. I would think
 > that the latter is the more conservative, because presumably it
 > was put in the SR path for a reason, and so SHOULD be carried on
 > an SR path.
 
[Bruno] traffic and path is not affected, whether value 42 or 53 is selected 
for a given segment. What we do need is consistency across all nodes.

-- Bruno


 > - Stewart
 > 
 >