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

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 5 Dec 2016 00:04:27 +0000

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: Shraddha Hegde <[email-masked]>
Date: Thu, 8 Dec 2016 13:35:38 +0000

Hi Les,

The newer approach describes the conflict resolution for the SRMS entries.
How is the conflict resolved across individual prefix advertisements and SRMS advertisements?

It is useful to assign a default preference (best possible preference)to individual prefix-sid advertisements while resolving the
Conflicts such that individual advertisements always wins.

Rgds
shraddha

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Monday, December 5, 2016 5:34 AM
To: [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: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 8 Dec 2016 14:03:37 +0000

Shraddha -

Current version of the draft (https://www.ietf.org/id/draft-ietf-spring-conflict-resolution-02.txt ) states in Section 3,1

"Advertisement of a preference value is optional.  Nodes which do not
   advertise a preference value are assigned a preference value of 128.

All SIDs advertised in prefix reachability advertisements implicitly
   have a preference value of 192."

So the default behavior is that SIDs in prefix reachability advertisements are preferred over SRMS entries.

The proposal below makes no changes to that.

   Les

From: Shraddha Hegde [mailto:[email-masked]]
Sent: Thursday, December 08, 2016 5:36 AM
To: Les Ginsberg (ginsberg); [email-masked]
Subject: RE: [spring] SID Conflict Resolution: A Simpler Proposal

Hi Les,

Rgds
shraddha

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Monday, December 5, 2016 5:34 AM
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: <[email-masked]>
Date: Fri, 9 Dec 2016 10:07:10 +0000

Hi Les,

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

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

1)Detect the problem

2)Report the problem

[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?

New Proposal

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

Example 1:

Active policy:

Example 2:

Active policy:

Example 3:

Active policy:

Empty

Example 4:

Active policy:

_________________________________________________________________________________________________________________________

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: "Aissaoui, Mustapha (Nokia - CA)" <[email-masked]>
Date: Fri, 9 Dec 2016 15:43:39 +0000

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:[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

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: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 9 Dec 2016 18:30:32 +0000

Bruno -

Welcome back to the discussion. :)
Inline.

From: [email-masked] [mailto:[email-masked]]
Sent: Friday, December 09, 2016 2:07 AM
To: Les Ginsberg (ginsberg)
Cc: [email-masked]
Subject: RE: SID Conflict Resolution: A Simpler Proposal

Hi Les,

1)Detect the problem

2)Report the problem

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.

New Proposal

based on preference

[Les:] It is the former.

[Les:] The point of the alternative proposal is a simplification. The presentation in Seoul (check out the slides) highlighted complexities in the implementation of "ignore-overlap-only" - in particular subtleties in the order in which an implementation looks at entries which could produce interoperability issues even though implementations are using the same preference rule. The alternative reduces the chances of these interoperability issues occurring because the algorithm used is simpler and less subject to subtle implementation differences.

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. I know you disagree on this point - but that is exactly what the WG is debating - not whether it is possible to make "ignore overlap only" work.

   Les

Thanks

-- Bruno

Example 1:

Active policy:

Example 2:

Active policy:

Example 3:

Active policy:

Empty

Example 4:

Active policy:

Thank you.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 9 Dec 2016 18:48:32 +0000

Mustapha -

From: Aissaoui, Mustapha (Nokia - CA) [mailto:[email-masked]]
Sent: Friday, December 09, 2016 7:44 AM
To: Les Ginsberg (ginsberg); [email-masked]
Subject: RE: SID Conflict Resolution: A Simpler Proposal

"

"

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

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

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: <[email-masked]>
Date: Mon, 12 Dec 2016 16:12:52 +0000

Les,

On the complexity side, I have the feeling that a portion of this complexity comes from editorial choices in the draft. And in particular that the text and concepts used for the per FEC policy could be simplified.

Indeed, what we need for a consistent behavior across all implementations, is to specify the behavior of the end result. We should not need to discuss implementation internals.
A priori, the following text should be enough:

"In step 1, Prefix conflicts are resolved on a per FEC/IP prefix/Segment basis. For each FEC, the preferred SID is selected, as per the preference function (e.g. best Preference field, then smallest SID)
                Note that following this step, each prefix covered by an IGP SID advertisement has exactly one SID.
In step 2, SID conflicts are resolved. For each SID, the preferred Prefix is selected as per the preference function.
                Note that following this step, each SID has a single prefix. However some prefix may have no SID."

With the above text, there is no need for the draft to introduce generalized mapping entries, nor to split original entries into multiple ranges, nor to clarify whether the info are to be taken from the original or derived entries...

Then each implementation is free to choose its own data-structure and implementation details.
e.g one may split original entries into multiple ranges if this is your choice.
Another one may simply decompress the MS advertisement by adding the SID to each prefix, as if it were coming from a prefixSID. (As the MS range is "essentially a compression scheme") so if its too complex to handle in its compress form, lets decompress).
e.g. after receiving the MS entry (128, 1.1.1.1/32 100 range 255), the SID 100 (resp. 101...354) is added to the IP prefix 1.1.1.1 (resp. 1.1.1.2... 1.1.1.255)
Following this decompression, comparison is much more simple as there is no more MS entries which are not directly comparable to prefix SID.
e.g. in the worst case, a prefix as a set of SID, and one is selected using the preference function. A simple preference may be to select the highest Preference, and then the smallest SID to tie-brake.

In summary, having multiple advertisements for a routing entries and having to select one, is not new in the routing space/area. In this case, the complexity comes from the Mapping Server range, rather than the selection of one SID. So let's just decompress this Mapping Server range, and the problem gets simpler and very similar to what we are used to in the routing space, i.e. select the best route/path/entry

2) Preference function
For all policy except "ignore all", there is a need for a preference function. So this point is not a changing the complexity between a per advertisement policy (quarantine/new proposal) and a per FEC policy (e.g. ignore overlap)

Thanks,
--Bruno

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Friday, December 09, 2016 7:31 PM
To: DECRAENE Bruno IMT/OLN
Cc: [email-masked]
Subject: RE: SID Conflict Resolution: A Simpler Proposal

Bruno -

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Friday, December 09, 2016 2:07 AM
To: Les Ginsberg (ginsberg)
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: SID Conflict Resolution: A Simpler Proposal

Hi Les,

1)Detect the problem

2)Report the problem

Am I missing something?

New Proposal

based on preference

[Les:] It is the former.

   Les

Thanks

-- Bruno

Example 1:

Active policy:

Example 2:

Active policy:

Example 3:

Active policy:

Empty

Example 4:

Active policy:

Thank you.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 13 Dec 2016 02:07:20 +0000

Bruno -

There is absolutely nothing in the draft which discusses implementation choices. In Section 3.3.7 there is a conceptual discussion that states in part:

"Mapping entries with a range greater than
   1 which are in conflict with other mapping entries have to internally
   be split into 2 or more "derived mapping entries".  The derived
   mapping entries then fall into two categories - those that are in
   conflict with other mapping entries and those which are NOT in
   conflict.  The former are ignored and the latter are used."

This isn't specifying an implementation data structure - it is simply stating the fact that for a mapping entry with a range greater than one has to be to identify which portions of that mapping entry are "unusable" because of conflict and which portions are usable. Conceptually this results in "derived mapping entries" - but how one chooses to implement them is deliberately not stated. One could (as you suggest below) expand the entry into individual per FEC entries - or one could associate some adjunct data structure which tracks the usability status of each prefix - or one could recalculate the conflict on demand whenever one needs to know the usable SID for a prefix and eliminate the need for additional data structures - or one could link child derived mapping entries to the "raw" received mapping entry. The draft is agnostic in this regard.

The point I am making is that there are two issues which only arise with "ignore overlap only":

1)One has to come up with a way to track the usability of each prefix/SID pair covered by the advertised range while still remembering the original advertisement because the granularity of usability is NOT the raw advertisement

2)When one implements the conflict resolution algorithm there are subtleties which can affect the outcome which are peculiar to "ignore overlap only" because of the possible partial use of a raw mapping entry. See Slide 18 of the slides for IETF97.

Neither of these issue arise with "Ignore".

Now, can we specify the normative behavior of "ignore overlap only" such that it is clear? Yes
Is it possible to implement "ignore overlap only"? Yes

However, bugs exist despite everyone's best efforts, and part of the argument for simplicity includes:

·         Simpler requirements make implementation bugs less likely

·         As conflict resolution is an error pathway it inevitably gets exercised less often - so bugs are less likely to be found

·         Additional test effort is then required to adequately test "ignore overlap only"

·         All of the above could result in non-interoperable implementations

Perhaps the words used to describe "ignore overlap only" could be reduced or revised to be more clear - but that would not alter the functional requirements.
Everyone gets to decide what value to put on the differences between the two approaches, but I don't think I have incorrectly identified what is required to implement "ignore overlap only".

   Les

From: [email-masked] [mailto:[email-masked]]
Sent: Monday, December 12, 2016 8:13 AM
To: Les Ginsberg (ginsberg)
Cc: [email-masked]
Subject: RE: SID Conflict Resolution: A Simpler Proposal

Les,

2) Preference function

Thanks,
--Bruno

Bruno -

Hi Les,

1)Detect the problem

2)Report the problem

Am I missing something?

New Proposal

based on preference

[Les:] It is the former.

   Les

Thanks

-- Bruno

Example 1:

Active policy:

Example 2:

Active policy:

Example 3:

Active policy:

Empty

Example 4:

Active policy:

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Wed, 14 Dec 2016 16:05:18 +0000

Les,

Please see inline [Buno]

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Tuesday, December 13, 2016 3:07 AM
To: DECRAENE Bruno IMT/OLN
Cc: [email-masked]
Subject: RE: SID Conflict Resolution: A Simpler Proposal

Bruno -

This isn't specifying an implementation data structure - it is simply stating the fact that for a mapping entry with a range greater than one has to be to identify which portions of that mapping entry are "unusable" because of conflict and which portions are usable. Conceptually this results in "derived mapping entries"
[Bruno] Equally conceptually, this result in decompressing the Mapping Server (MS) range by attaching the MS SID to each FEC. Then we get a per FEC resolution. IMHO I find this concept less complex.
- but how one chooses to implement them is deliberately not stated. One could (as you suggest below) expand the entry into individual per FEC entries - or one could associate some adjunct data structure which tracks the usability status of each prefix - or one could recalculate the conflict on demand whenever one needs to know the usable SID for a prefix and eliminate the need for additional data structures - or one could link child derived mapping entries to the "raw" received mapping entry. The draft is agnostic in this regard.

[Bruno] My use of the term « data structure » was probably incorrect. However the draft does propose a specific algorithm (split mapping entries) with an associated "Information Model" (derived entries). Then slides and discussion highlight the complexity of this algorithm, which brings some specific additional points perceived as additional complexity. e.g. we now need to specify whether the preference is to use the protocol entries or the derived entries.
My point is that such text, discussions and perceived complexity is specific to this algorithm, and standardizing this is debatable. e.g. some implementation may feel obliged to use this algorithm. I'd rather have a text which is not specific to the algorithm used to achieve the end result/rule.

1)One has to come up with a way to track the usability of each prefix/SID pair covered by the advertised range while still remembering the original advertisement because the granularity of usability is NOT the raw advertisement
[Bruno] Agreed. One has to "decompress" the Mapping Server range field. But to me this is specific to the choice made to compress this information. The (de)compression algo seems reasonably simple to me.
If we don't want to handle the decompression on the receiving side, because this is too complex, then we probably shouldn't compress it in the first place. This would typically require the network operator to decompress it in the configuration file of the Mapping Server (sending side). Even for such a non-software professional, the script seems doable. But on the protocol side, this would present a scaling impact to have the Mapping Server advertise 100s of individual FEC. And the justification for this seem poor (it's too complex for a software company to write the code to decompress the range field, so we chose to ask N network operators to write the script to generate 100s of configuration lines, by mostly decompressing the range field).

2)When one implements the conflict resolution algorithm there are subtleties which can affect the outcome which are peculiar to "ignore overlap only" because of the possible partial use of a raw mapping entry. See Slide 18 of the slides for IETF97.
[Bruno] Exactly my point. This slide and subtleties are specific to the specific algorithm chosen. Alternatively, if you decompress the received mapping entries, you don't have such subtleties/complexity

·         As conflict resolution is an error pathway it inevitably gets exercised less often - so bugs are less likely to be found
[Bruno] Debatable. By design, we'll need redundant MS hence redundant MS entries. Then if MS is used to incrementally deploy SR in a LDP network, which was its goal, we'll also have SID prefix entries. So in nominal case, we'll have 2 or 3 SID advertisement per FEC, and the conflict resolution draft/code needs to handle this. (Whichever policy is chosen).

Perhaps the words used to describe "ignore overlap only" could be reduced or revised to be more clear - but that would not alter the functional requirements.
Everyone gets to decide what value to put on the differences between the two approaches, but I don't think I have incorrectly identified what is required to implement "ignore overlap only".
[Bruno] indeed. But the perceived complexity may be different: decompressing the range field is relatively simple to understand, then selecting the best SID among a set is nothing new in the routing space.
-- Bruno
   Les

Les,

2) Preference function

Thanks,
--Bruno

Bruno -

Hi Les,

1)Detect the problem

2)Report the problem

Am I missing something?

New Proposal

based on preference

[Les:] It is the former.

   Les

Thanks

-- Bruno

Example 1:

Active policy:

Example 2:

Active policy:

Example 3:

Active policy:

Empty

Example 4:

Active policy:

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Wed, 21 Dec 2016 14:39:39 +0000

Les,

Still as an individual contributor, SID conflict resolution is about a trade-off between implementation complexity and network availability. Hence evaluating the consequences on network availability is at least as important as evaluating the implementation complexity; especially as the former is easier to quantify while the latter may be implementation specific. So on this FEC/network availability standpoint, please find below three comments.

1) The slides presented might IMHO slightly mislead a reader:
- the discussion on network availability compares "Quarantine" vs "Ignore Overlap"
- the conclusion discuss "Ignore Overlap" vs "Ignore"

So they are comparing different things, while a quick reader may assume that apples were compared to apples.
Note that I'm not saying (and not thinking) that this is misleading on purpose. I'm expressing the way I read it.

2) Regarding the new proposal, post Seoul, it is vocal on the complexity side, but not on the network availability side which is not evaluated. This does not helps the WG understanding of the trade-off involved and the making of an informed decision.
I'm even wondering if the network availability has been considered since by default, this proposal seems to kill, by design, the SRMS and SR-LDP inter-working.
SRMS has been designed in order to allow for the inter-working with LDP, in a brown-field scenario where SR is introduced in a LDP MPLS network.
e.g. a typical set of advertisements would be
1. PrefixSID: (192, 1.1.1.1/32 100 range 1)
2. MS:        (128, 1.1.1.1/32 100 range 255)

With this simple example, not even having a configuration error but using a nominal configuration, the MS advertisement would be ignored with the ignore policy, hence the LDP interwork would not work, and all LDP/non-SR nodes would loose SID hence loose SR connectivity.
Eventually, you may change the algorithm, to look beyond the most preferred entry, and check whether the SIDs are really different or not. And if not, change the algo to pick the largest range rather than the highest preference. But this is adding complexity to cover a specific case, while keeping the solution weak in term of network availability, in the general case. e.g. if we do have a different SID, many  prefix (99%) would lose their SID.

3) Finally, when discussing "Ignore Overlap", a typical quote from the authors is "maximize forwarding" or "operate optimally", as if we were trying to optimize for the last bit. But note that "Ignore Overlap" is _not_ maximizing forwarding.  Maximizing forwarding would be much more complex, and nobody on the list has even tried for this, including draft-ietf-spring-conflict-resolution.
e.g. with following advertisements with a misconfiguration
1. PrefixSID: (192, 1.1.1.1/32 101 range 1)
2. MS:        (128, 1.1.1.1/32 100 range 255)

During prefix conflict, for 1.1.1.1/32 Ignore Overlap selects the SID from prefixSID entry, which will latter have a SID conflict with the MS entry (SID 101, prefixes 1.1.1.1 vs 1.1.1.2). As a result, 1.1.1.2 won't get a SID.
In this specific case, a solution "maximizing the forwarding" would have ignored the PrefixSID. But in the general case, "maximizing the forwarding" may require evaluating all options, and then pick the best one based on all results.

So please let's keep evaluating the impact on the network availability. Berlin presentation was a good example on this.

--Bruno

Bruno -

Hi Les,

1)Detect the problem

2)Report the problem

Am I missing something?

New Proposal

based on preference

[Les:] It is the former.

   Les

Thanks

-- Bruno

Example 1:

Active policy:

Example 2:

Active policy:

Example 3:

Active policy:

Empty

Example 4:

Active policy:

Thank you.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 22 Dec 2016 01:49:33 +0000

Bruno -

From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, December 21, 2016 6:40 AM
To: Les Ginsberg (ginsberg)
Cc: [email-masked]
Subject: RE: SID Conflict Resolution: A Simpler Proposal

Les,

[Les:] Please remember the history here. Prior to Seoul the input we had was:
"Ignore" is least desirable - evaluate between "Quarantine" and "Ignore Overlap".
The discussion over the previous few months therefore was comparing the latter two. Slides for both Berlin and Seoul were therefore prepared with that in mind.

Significant feedback at Seoul and since has made "Ignore" a candidate again - so the email thread has now focused on "Ignore" vs "Ignore Overlap Only".
If I had received this feedback before Seoul I would have prepared different slides.

My apologies for not being clairvoyant. :)

[Les:] Your interpretation is incorrect. There is no conflict in the example you provide - therefore no entries will be ignored (this is true no matter what conflict resolution strategy is chosen).
The definition of conflicts can be found in Section 3.2 of the draft. Nothing in this discussion proposes changes to that- and the definition of a conflict has never been under debate.

What we have discussed over the last 6 months or more has been what to do when conflicts exist- this is Section 3.3 of the draft.

So please let's keep evaluating the impact on the network availability. Berlin presentation was a good example on this.
[Les:] Well, the Berlin slides (see Slide 25) use the term "Maximize SR Forwarding".
https://www.ietf.org/proceedings/96/slides/slides-96-spring-4.pdf

One of the problems with making a choice when conflicts exist is that there is no way of knowing what prefixes are the most important in a particular network deployment.  "Ignore overlap only" aimed to maximize the number of prefixes which had SIDs in the hope that we would have a greater chance of including the more important prefixes - but since all of our tie-breakers are simply arbitrary choices there is no guarantee. From Section 3.3.4 of the draft:

2 Smaller range wins
3.  IPv6 entry wins over IPv4 entry
4.  Longer prefix length wins
5.  Smaller algorithm wins
6.  Smaller starting address (considered as an unsigned integer
       value) wins
   7.  Smaller starting SID wins

If you were to seriously try to focus on "network availability" we would need to incorporate additional information which might include:

·         Is a prefix reachable?

·         How much traffic depends on each prefix

·         What class of traffic depends on each prefix

This can only increase the complexity of the implementation - and I have no doubt the debate about the best heuristics could go on without end.

I return again to the priorities which the authors stated from the beginning:

1)Detect the problem
2)Report the problem

For some of us, the resolution behavior is the least important. For you it seems it is the most important.
That is what  the debate is really about.

   Les

--Bruno

Bruno -

Hi Les,

1)Detect the problem

2)Report the problem

Am I missing something?

New Proposal

based on preference

[Les:] It is the former.

   Les

Thanks

-- Bruno

Example 1:

Active policy:

Example 2:

Active policy:

Example 3:

Active policy:

Empty

Example 4:

Active policy:

Thank you.

Thank you.

---

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

And one more thought for everyone to mull over while enjoying the holidays...

Consistency is a requirement of any solution i.e. all routers in the network MUST use the same algorithm operating on the same database.
However, this requirement goes beyond routers - it is also required of any entity - specifically controllers - which might specify an engineered path consisting of prefix SIDs.

I think no one questions that all routers will implement the standardized solution - but will all controllers?

Consider the consequences if a controller does not implement the solution.

We have the following conflict:

(192, 1.1.1.1/32 100 range 1)
(192, 2.2.2.2/32 100 range 1)

If we use a policy which chooses a winning entry in such a case (such as "Ignore Overlap Only") the winner will be (192, 1.1.1.1/32 100 range 1) (based on current preference rules defined in the draft).
Labels associated with SID 100 will be installed in router forwarding plans and direct traffic towards 1.1.1.1.

If we use a policy which does not use either of the conflicting entries routers will NOT install labels associated with SID 100 in the forwarding plane and traffic arriving with such a label will be dropped.

If a controller which does NOT do conflict resolution builds an engineered path which traverses 2.2.2.2, it will send a label stack including SID 100.

Using "Ignore Overlap Only", routers will forward a packet with SID 100 towards 1.1.1.1 rather than 2.2.2.2.

Using "Ignore", packets using SID 100 will be dropped.

I am not optimistic that all controllers will implement conflict resolution. If I am right, the consequences of the combination of the Conflict Resolution policy chosen and a Controller which does not implement conflict resolution should be considered.

  Les

From: spring [mailto:[email-masked]] On Behalf Of Les Ginsberg (ginsberg)
Sent: Wednesday, December 21, 2016 5:50 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [spring] SID Conflict Resolution: A Simpler Proposal

Bruno -

Les,

2 Smaller range wins

·         Is a prefix reachable?

1)Detect the problem
2)Report the problem

   Les

--Bruno

Bruno -

Hi Les,

1)Detect the problem

2)Report the problem

Am I missing something?

New Proposal

based on preference

[Les:] It is the former.

   Les

Thanks

-- Bruno

Example 1:

Active policy:

Example 2:

Active policy:

Example 3:

Active policy:

Empty

Example 4:

Active policy:

Thank you.

Thank you.

---

From: "Aissaoui, Mustapha (Nokia - CA)" <[email-masked]>
Date: Thu, 22 Dec 2016 16:10:12 +0000

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.

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 algorithm uses parameters such as "Range (start w smallest)" then obviously derived SRMS entries will lend a different result than original SRMS entries.

With the pre-prefix resolution, the only information kept from the original SRMS entry is the preference and the advertising or owner router. Anything else is not used. It seems to me a simple algorithm based on preference first then followed by some rule on selecting the advertising router if conflicts exist within the same preference would work.

3.     Finally, there is something which has not been addressed in the slides. There is still a possibility of conflicting entries among SIDs advertised using the prefix SID sub-TLV within a Prefix TLV (IS-IS IP Reach TLV or OSPF Extended Prefix TLV). A simple rule selecting the advertising router should also work fine here.

Regards,
Mustapha.

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Friday, December 09, 2016 1:49 PM
To: Aissaoui, Mustapha (Nokia - CA) <[email-masked]>; [email-masked]
Subject: RE: SID Conflict Resolution: A Simpler Proposal

Mustapha -

From: Aissaoui, Mustapha (Nokia - CA) [mailto:[email-masked]]
Sent: Friday, December 09, 2016 7:44 AM
To: Les Ginsberg (ginsberg); [email-masked]<mailto:[email-masked]>
Subject: RE: SID Conflict Resolution: A Simpler Proposal

"

"

   Les

Regards,
Mustapha.

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: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 22 Dec 2016 19:37:00 +0000

Mustapha -

From: spring [mailto:[email-masked]] On Behalf Of Aissaoui, Mustapha (Nokia - CA)
Sent: Thursday, December 22, 2016 8:10 AM
To: Les Ginsberg (ginsberg); [email-masked]
Subject: Re: [spring] SID Conflict Resolution: A Simpler Proposal

Hi Les,

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

[Les:] You have implemented things in a certain way. Someone else might choose to implement in a different way. A normative specification does not (and should not) constrain an implementation. What is being illustrated here is that if the implementation does not retain the underived entry (in whatever internal form it chooses) different results will be obtained because the preference algorithm depends on comparing the underived ranges.

[Les:] No - source of an advertisement has been quite deliberately excluded from the preference algorithm. With redistribution/route leaking the source of an advertisement may appear to be different on different routers- this would result in different results on different routers.

   Les

Regards,
Mustapha.

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Friday, December 09, 2016 1:49 PM
To: Aissaoui, Mustapha (Nokia - CA) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: SID Conflict Resolution: A Simpler Proposal

Mustapha -

"

"

   Les

Regards,
Mustapha.

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: Thu, 22 Dec 2016 20:51:54 +0100

Hi Les,

On #1 I am also with Mustapha here. For clarity of this discussion can you
enumerate when from RIB to FIB/LFIB you are installing the exact same
active prefix from more then one producer ? Is SRMS sort of zombie here and
not treated as real route producer hence we have an issue ? And the issue
is only with conflicts of SRMS + real route producer ?

On #3 you said that *"with redistribution/route leaking the source of an
advertisement may appear to be different on different routers"* that is
very true. In fact with simple static route or static label configured on a
router the RIB and FIB on that router will be different then RIB and FIB on
the other routers without such static route. And the point is that such
static route or label is there for a reason you may not know about. So
struggling for data plane consistency ​deliberately excluding source when
operational needs require otherwise is not really that much helpful I am
afraid.

Greetings,
Robert.

On Thu, Dec 22, 2016 at 8:37 PM, Les Ginsberg (ginsberg) <[email-masked]
> wrote:

> Mustapha -
>
>
>
> *From:* spring [mailto:[email-masked]] *On Behalf Of *Aissaoui,
> Mustapha (Nokia - CA)
> *Sent:* Thursday, December 22, 2016 8:10 AM
> *To:* Les Ginsberg (ginsberg); [email-masked]
> *Subject:* Re: [spring] SID Conflict Resolution: A Simpler Proposal
>
>
>
> Hi Les,
>
> 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.*
>
>
>
> 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 algorithm uses parameters such as “Range
> (start w smallest)” then obviously derived SRMS entries will lend a
> different result than original SRMS entries.
>
> With the pre-prefix resolution, the only information kept from the
> original SRMS entry is the preference and the advertising or owner router.
> Anything else is not used. It seems to me a simple algorithm based on
> preference first then followed by some rule on selecting the advertising
> router if conflicts exist within the same preference would work.
>
>
>
> *[Les:] You have implemented things in a certain way. Someone else might
> choose to implement in a different way. A normative specification does not
> (and should not) constrain an implementation. What is being illustrated
> here is that if the implementation does not retain the underived entry (in
> whatever internal form it chooses) different results will be obtained
> because the preference algorithm depends on comparing the underived ranges.*
>
>
>
> 3.     Finally, there is something which has not been addressed in the
> slides. There is still a possibility of conflicting entries among SIDs
> advertised using the prefix SID sub-TLV within a Prefix TLV (IS-IS IP Reach
> TLV or OSPF Extended Prefix TLV). A simple rule selecting the advertising
> router should also work fine here.
>
>
>
> *[Les:] No – source of an advertisement has been quite *
> *​​*
> *deliberately excluded from the preference algorithm. With
> redistribution/route leaking the source of an advertisement may appear to
> be different on different routers- this would result in different results
> on different routers.*
>
>
>
> *   Les*
>
>
>
> Regards,
>
> Mustapha.
>
>
>
> *From:* Les Ginsberg (ginsberg) [mailto:[email-masked]
> <[email-masked]>]
> *Sent:* Friday, December 09, 2016 1:49 PM
> *To:* Aissaoui, Mustapha (Nokia - CA) <[email-masked]>;
> [email-masked]
> *Subject:* RE: SID Conflict Resolution: A Simpler Proposal
>
>
>
> Mustapha -
>
>
>
> *From:* Aissaoui, Mustapha (Nokia - CA) [mailto:mustapha.aissaoui@
> nokia.com <[email-masked]>]
> *Sent:* Friday, December 09, 2016 7:44 AM
> *To:* Les Ginsberg (ginsberg); [email-masked]
> *Subject:* RE: SID Conflict Resolution: A Simpler 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:
>
> “
>
> “
> *[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
> <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:[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
>
>
>
> 4)Don’t overengineer the solution
>
> *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: Thu, 22 Dec 2016 21:32:41 +0000

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

The Introduction to the draft states:

“The problem to be addressed is protocol independent i.e., segment
   related advertisements may be originated by multiple nodes using
   different protocols and yet the conflict resolution MUST be the same
   on all nodes regardless of the protocol used to transport the
   advertisements.”

Please do a mental reset. ☺

   Les

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Thursday, December 22, 2016 11:52 AM
To: Les Ginsberg (ginsberg)
Cc: Aissaoui, Mustapha (Nokia - CA); [email-masked]
Subject: Re: [spring] SID Conflict Resolution: A Simpler Proposal

Hi Les,

On #1 I am also with Mustapha here. For clarity of this discussion can you enumerate when from RIB to FIB/LFIB you are installing the exact same active prefix from more then one producer ? Is SRMS sort of zombie here and not treated as real route producer hence we have an issue ? And the issue is only with conflicts of SRMS + real route producer ?

On #3 you said that "with redistribution/route leaking the source of an advertisement may appear to be different on different routers" that is very true. In fact with simple static route or static label configured on a router the RIB and FIB on that router will be different then RIB and FIB on the other routers without such static route. And the point is that such static route or label is there for a reason you may not know about. So struggling for data plane consistency ​deliberately excluding source when operational needs require otherwise is not really that much helpful I am afraid.

Greetings,
Robert.

On Thu, Dec 22, 2016 at 8:37 PM, Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>> wrote:
Mustapha -

From: spring [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Aissaoui, Mustapha (Nokia - CA)
Sent: Thursday, December 22, 2016 8:10 AM
To: Les Ginsberg (ginsberg); [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] SID Conflict Resolution: A Simpler Proposal

Hi Les,

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

It seems to me this issue is an artifact of the specific algorithm used to resolve conflicts. Because the algorithm uses parameters such as “Range (start w smallest)” then obviously derived SRMS entries will lend a different result than original SRMS entries.

[Les:] No – source of an advertisement has been quite
​​
deliberately excluded from the preference algorithm. With redistribution/route leaking the source of an advertisement may appear to be different on different routers- this would result in different results on different routers.

   Les

Regards,
Mustapha.

Mustapha -

“

“

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

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.

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: Robert Raszuk <[email-masked]>
Date: Thu, 22 Dec 2016 23:29:15 +0100

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) <
[email-masked]> wrote:

> 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 advertisement.
>
>
>
> Please do a mental reset. J
>
>
>
>    Les
>
>
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Robert
> Raszuk
> *Sent:* Thursday, December 22, 2016 11:52 AM
> *To:* Les Ginsberg (ginsberg)
> *Cc:* Aissaoui, Mustapha (Nokia - CA); [email-masked]
>
> On Thu, Dec 22, 2016 at 8:37 PM, Les Ginsberg (ginsberg) <
> [email-masked]> wrote:
>
> Mustapha -
>
>
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 22 Dec 2016 22:46:25 +0000

Robert –

You are making progress – but still a ways to go. ☺

Consider the following simple case:

OSPF on Router #1 advertises 1.1.1.1/32 w SID 100
OSPF on Router #2 advertises 2.2.2.2/32 w SID 100

Both routes will get installed in the RIB/FIB on all routers – but we cannot install the same label in the forwarding for both destinations – so we have to decide what to do.

1)We could simply not install a label for either prefix – that is the “simple/Ignore” approach that is being discussed. IP forwarding will then be used.

2)We could use a preference rule to determine which entry is the winner as far as use of the label is concerned – that is the “Ignore Overlap Only” approach is one way of doing this. The winner would have labels installed – the loser would not.

Regardless of conflict resolution strategy both routes will still exist in forwarding.

The debate we are having is whether to use #1 or #2.
But none of this relates to “overlapping prefixes” or same route from multiple sources or any other problem which routing already handles.

HTH

    Les

Sent: Thursday, December 22, 2016 2:29 PM

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) <[email-masked]<mailto:[email-masked]>> wrote:
Robert –

   Les

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Robert Raszuk
Sent: Thursday, December 22, 2016 11:52 AM
To: Les Ginsberg (ginsberg)
Cc: Aissaoui, Mustapha (Nokia - CA); [email-masked]<mailto:[email-masked]>

Hi Les,

Greetings,
Robert.

Hi Les,

   Les

Regards,
Mustapha.

Mustapha -

“

“

   Les

Regards,
Mustapha.

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: Thu, 22 Dec 2016 23:54:45 +0100

Hi Les,

> ​

 > Both routes will get installed in the RIB/FIB on all routers – but we

> cannot install the same label in the forwarding for both destinations –

> so we have to decide what to do.

Why not ? To me this looks like form of basic pure SR anycast ! In fact if
you detach requirement and dependency on IP anycast from SR anycast there
is potential for nice applications with that making SR even more
attractive.

> we  cannot install the same label in the forwarding for both destinations

Really ? Same label can point to N outgoing paths .. this is normal for
ages for ECMP.

With MPLS in fact  - as very few may recall - there is special knob
allowing *unequal cost load balancing UCMP*.  Very nice feature if one
knows what he/she is doing :).

Cheers,
R.

On Thu, Dec 22, 2016 at 11:46 PM, Les Ginsberg (ginsberg) <
[email-masked]> wrote:

> Robert –
>
>
>
> You are making progress – but still a ways to go. J
>
>
>
> Both routes will get installed in the RIB/FIB on all routers – but we
> cannot install the same label in the forwarding for both destinations – so
> we have to decide what to do.
>
>
>
> 1)We could simply not install a label for either prefix – that is the
> “simple/Ignore” approach that is being discussed. IP forwarding will then
> be used.
>
>
>
> 2)We could use a preference rule to determine which entry is the winner as
> far as use of the label is concerned – that is the “Ignore Overlap Only”
> approach is one way of doing this. The winner would have labels installed –
> the loser would not.
>
>
>
> But none of this relates to “overlapping prefixes” or same route from
> multiple sources or any other problem which routing already handles.
>
>
>
> HTH
>
>
>
>     Les
>
>
>
>
>
> *Sent:* Thursday, December 22, 2016 2:29 PM
>
> 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.
>
>
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 22 Dec 2016 23:16:22 +0000

Robert –

Perhaps we should take this offline as we are starting to go over some basics of SR – which doesn’t advance this thread.

Some answers inline.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Thursday, December 22, 2016 2:55 PM
To: Les Ginsberg (ginsberg)
Cc: [email-masked]; Aissaoui, Mustapha (Nokia - CA)
Subject: Re: [spring] SID Conflict Resolution: A Simpler Proposal

Hi Les,

OSPF on Router #1 advertises 1.1.1.1/32<http://1.1.1.1/32> w SID 100
> OSPF on Router #2 advertises 2.2.2.2/32<http://2.2.2.2/32> w SID 100

> so we have to decide what to do.

Why not ? To me this looks like form of basic pure SR anycast ! In fact if you detach requirement and dependency on IP anycast from SR anycast there is potential for nice applications with that making SR even more attractive.

[Les:] WE are looking at two different prefixes here – not the same prefix sourced by multiple nodes.
> we  cannot install the same label in the forwarding for both destinations

Really ? Same label can point to N outgoing paths .. this is normal for ages for ECMP.
[Les:] Again, two different prefixes – not multiple paths for the same prefix.
   Les

With MPLS in fact  - as very few may recall - there is special knob allowing unequal cost load balancing UCMP.  Very nice feature if one knows what he/she is doing :).

Cheers,
R.

On Thu, Dec 22, 2016 at 11:46 PM, Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>> wrote:
Robert –

​​
OSPF on Router #1 advertises 1.1.1.1/32<http://1.1.1.1/32> w SID 100
OSPF on Router #2 advertises 2.2.2.2/32<http://2.2.2.2/32> w SID 100

HTH

    Les

Les,

Cheers,
R.

   Les

Hi Les,

Greetings,
Robert.

Hi Les,

   Les

Regards,
Mustapha.

Mustapha -

“

“

   Les

Regards,
Mustapha.

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: "Aissaoui, Mustapha (Nokia - CA)" <[email-masked]>
Date: Fri, 23 Dec 2016 14:59:15 +0000

Hi Les,
I made some follow-up inline.

Regards,
Mustapha.

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Thursday, December 22, 2016 2:37 PM
To: Aissaoui, Mustapha (Nokia - CA) <[email-masked]>; [email-masked]
Subject: RE: SID Conflict Resolution: A Simpler Proposal

Mustapha -

Hi Les,

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.

MA> I do not believe this is about implementation. It is about what routers do and that is resolution per prefix. It does not matter how the prefix SID information is advertised, individually or part of an SRMS entry, at the end it is associated with a prefix.

MA> The following RFC is specifying an optional attribute (the IPv4/IPv6 Source Router ID TLV) to encode the original advertising router of a prefix. This can be used to perform a simple selection algorithm:
https://tools.ietf.org/html/rfc7794#section-2.2

Otherwise, what is your proposal for this point (3)? I could not find it addressed in the current version of the draft.

   Les

Regards,
Mustapha.

Mustapha -

"

"

   Les

Regards,
Mustapha.

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: "Aissaoui, Mustapha (Nokia - CA)" <[email-masked]>
Date: Fri, 23 Dec 2016 15:24:55 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Thursday, December 22, 2016 5:29 PM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: Aissaoui, Mustapha (Nokia - CA) <[email-masked]>; [email-masked]
Subject: Re: [spring] SID Conflict Resolution: A Simpler Proposal

Les,

Cheers,
R.

   Les

Hi Les,

Greetings,
Robert.

Hi Les,

   Les

Regards,
Mustapha.

Mustapha -

“

“

   Les

Regards,
Mustapha.

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: Marc Binderberger <[email-masked]>
Date: Fri, 30 Dec 2016 23:53:29 -0800

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

> 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 +0000, 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.
>  
> 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). 
> 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.
>  
> On Thu, Dec 22, 2016 at 10:32 PM, Les Ginsberg (ginsberg) 
> <[email-masked]> wrote:
>> Robert –
>>  
>> 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 advertisement.
>>  
>> active prefix from more then one producer ? Is SRMS sort of zombie here 
>> and not treated as real route producer hence we have an issue ? And the 
>> issue is only with conflicts of SRMS + real route producer ? 
>>  
>> On #3 you said that "with redistribution/route leaking the source of an 
>> advertisement may appear to be different on different routers" that is 
>> very true. In fact with simple static route or static label configured on 
>> a router the RIB and FIB on that router will be different then RIB and FIB 
>> on the other routers without such static route. And the point is that such 
>> struggling for data plane consistency deliberately excluding source when 
>> On Thu, Dec 22, 2016 at 8:37 PM, Les Ginsberg (ginsberg) 
>> <[email-masked]> wrote:
>> Mustapha -
>>  
>> 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.
>>  
>> [Les:] You have implemented things in a certain way. Someone else might 
>> because the preference algorithm depends on comparing the underived ranges.
>>  
>> advertised using the prefix SID sub-TLV within a Prefix TLV (IS-IS IP 
>> Reach TLV or OSPF Extended Prefix TLV). A simple rule selecting the 
>> advertising router should also work fine here.
>>  
>> deliberately excluded from the preference algorithm. With 
>> on different routers.
>> [Les:] In order to get consistent conflict resolution on all nodes in the 
>> 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.  
>> below sorting an entry for each individual prefix which advertised a 
>> prefix SID sub-TLV within a prefix TLV. 
>> 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 
>> and you will get the same answer.
>> With “Ignore Overlap Only” one of the issues with trying to use the 
>> for some simple examples of this.
>>  
>>    Les
>>  
>>  
>> Regards,
>> Mustapha.
>>