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

[<[e-mail]>]

Hi Les,

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

From: spring [mailto:[e-mail]] On Behalf Of Les Ginsberg (ginsberg)
Sent: Monday, December 05, 2016 1:04 AM
To: [e-mail]
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 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)









_________________________________________________________________________________________________________________________

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.