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

From: "Van De Velde, Gunter (Nokia - BE)" <[email-masked]>
Date: Fri, 9 Dec 2016 20:10:36 +0000

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:[email-masked]] On Behalf Of Les Ginsberg (ginsberg)
Sent: Sunday, December 04, 2016 7:04 PM
To: [email-masked]
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 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 1000 range 1)

Example 3:

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

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 entries 2, 3, and  4. All entries are marked ignore.

Active policy:

Empty

Example 4:

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

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

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

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

Entry 4 conflicts with entry 2. It is marked ignore.

Entry 2 conflicts with entry 3. Entries 2 and 3 are marked ignore.

Active policy:

(150, 1.1.1.1/32 100 range 10)

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 9 Dec 2016 21:43:04 +0000

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:[email-masked]]
Sent: Friday, December 09, 2016 12:11 PM
To: Les Ginsberg (ginsberg); [email-masked]
Subject: Re: [spring] SID Conflict Resolution: A Simpler Proposal

G/

From: spring [mailto:[email-masked]] On Behalf Of Les Ginsberg (ginsberg)
Sent: Sunday, December 04, 2016 7:04 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [spring] SID Conflict Resolution: A Simpler Proposal

1)Detect the problem

2)Report the problem

New Proposal

based on preference

Example 1:

Active policy:

Example 2:

Active policy:

Example 3:

Active policy:

Empty

Example 4:

Active policy:

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 9 Dec 2016 22:59:51 +0100

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

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) <[email-masked]
> 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 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.
>
> “*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_velde@
> nokia.com]
> *Sent:* Friday, December 09, 2016 12:11 PM
> *To:* Les Ginsberg (ginsberg); [email-masked]
> *Subject:* Re: [spring] SID Conflict Resolution: A Simpler Proposal
>
>
>
> 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
>
> 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
>
> *From:* spring [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Les Ginsberg (ginsberg)
> *Sent:* Sunday, December 04, 2016 7:04 PM
> *To:* [email-masked]
> *Subject:* [spring] SID Conflict Resolution: A Simpler Proposal
>
>
>
> *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.*
>
>
>
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 9 Dec 2016 22:03:42 +0000

Robert -

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

Dear Les,

[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<http://1.1.1.1/32> & 2.2.2.2/32<http://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) <[email-masked]<mailto:[email-masked]>> wrote:
Gunter –

1.1.1.1/32<http://1.1.1.1/32> index 100
2.2.2.2/32<http://2.2.2.2/32> index 100

If I choose to use index 100 for 1.1.1.1/32<http://1.1.1.1/32> – but my neighbor chooses to use index 100 for 2.2.2.2/32<http://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.

   Les

From: Van De Velde, Gunter (Nokia - BE) [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Friday, December 09, 2016 12:11 PM
To: Les Ginsberg (ginsberg); [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] SID Conflict Resolution: A Simpler Proposal

G/

1)Detect the problem

2)Report the problem

New Proposal

based on preference

Example 1:

1. (150, 1.1.1.1/32<http://1.1.1.1/32> 100 range 100)

2. (149, 1.1.1.10/32<http://1.1.1.10/32> 200 range 200)

3. (148, 1.1.1.101/32<http://1.1.1.101/32> 500 range 10)

Active policy:

(150, 1.1.1.1/32<http://1.1.1.1/32> 100 range 100)

Example 2:

1. (150, 1.1.1.1/32<http://1.1.1.1/32> 100 range 100)

2. (150, 1.1.1.10/32<http://1.1.1.10/32> 200 range 200)

3. (150, 1.1.1.101/32<http://1.1.1.101/32> 500 range 10)

4. (150, 2.2.2.1/32<http://2.2.2.1/32> 1000 range 1)

Active policy:

(150, 2.2.2.1/32<http://2.2.2.1/32> 1000 range 1)

Example 3:

1. (150, 1.1.1.1/32<http://1.1.1.1/32> 100 range 500)

2. (150, 1.1.1.10/32<http://1.1.1.10/32> 200 range 200)

3. (150, 1.1.1.101/32<http://1.1.1.101/32> 500 range 10)

4. (150, 2.2.2.1/32<http://2.2.2.1/32> 1000 range 1)

Active policy:

Empty

Example 4:

1. (150, 1.1.1.1/32<http://1.1.1.1/32> 100 range 10)

2. (149, 1.1.1.10/32<http://1.1.1.10/32> 200 range 300)

3. (149, 1.1.1.101/32<http://1.1.1.101/32> 500 range 10)

4. (148, 2.2.2.1/32<http://2.2.2.1/32> 1000 range 1)

Active policy:

(150, 1.1.1.1/32<http://1.1.1.1/32> 100 range 10)

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

---

From: "Van De Velde, Gunter (Nokia - BE)" <[email-masked]>
Date: Sat, 10 Dec 2016 06:29:26 +0000

Inline: GV>

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Friday, 9 December 2016 at 22:43
To: "Van De Velde, Gunter (Nokia - BE)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [spring] SID Conflict Resolution: A Simpler Proposal

Gunter –

GV> I know. I was just making the comparison with routing, as there the overlapping space is carved up as solution.

1.1.1.1/32 index 100
2.2.2.2/32 index 100

GV> I understood that

GV> Looks like there are also a significant number of people challenging the impression that "ignore overlap only" policy to be obscenely complex. It is the technically superior solution, hence my believe to keep proposal as ”ignore overlap only”. If you need help to create the text if it indeed is perceived as obscenely complex by you, then I’m sure there are people on the list willing to step up for help.

G/

   Les

G/

1)Detect the problem

2)Report the problem

New Proposal

based on preference

Example 1:

Active policy:

Example 2:

Active policy:

Example 3:

Active policy:

Empty

Example 4:

Active policy:

---

From: "Henderickx, Wim (Nokia - BE)" <[email-masked]>
Date: Sat, 10 Dec 2016 08:27:22 +0000

I also vote for maximizing forwarding based on customer input. Although I agree we want to avoid SID conflicts, it is going to happen and we need to minimize the implications in the network.
Life is not easy

From: spring <[email-masked]> on behalf of Gunter VAN DE VELDE <[email-masked]>
Date: Saturday, 10 December 2016 at 07:29
To: "Les Ginsberg (ginsberg)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [spring] SID Conflict Resolution: A Simpler Proposal

Inline: GV>

Gunter –

1.1.1.1/32 index 100
2.2.2.2/32 index 100

GV> I understood that

G/

   Les

G/

1)Detect the problem

2)Report the problem

New Proposal

based on preference

Example 1:

Active policy:

Example 2:

Active policy:

Example 3:

Active policy:

Empty

Example 4:

Active policy: