Subject: Re: [spring] draft-ietf-spring-conflict-resolution - Policy

From: <[email-masked]>
Date: Mon, 4 Jul 2016 12:07:04 +0000

Les,

Please see inline [Bruno]

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Friday, July 01, 2016 3:12 AM
To: DECRAENE Bruno IMT/OLN
Cc: [email-masked]
Subject: RE: draft-ietf-spring-conflict-resolution - Policy

Bruno -

I don't find your representation complete as regards all of the attributes which are proposed to be used by the conflict resolution algorithm - so it is therefore hard for me to use/understand this representation when applying the defined preference rule.
This is true for me even after reading your explanations below.

But it is far more important to have a common understanding of the algorithm proposal than it is to be arguing over whose encoding is "better". If the encoding in the draft is not clear or could use improvement, I welcome your feedback.

As far as your "pseudo-code":

- Find all SIDi advertised for the prefix P1                                                           // identification of Prefix conflicts
                - For each SIDi find all the prefix Pij associated with SIDi              // identification of SID conflicts

Get the best as per the preference algorithm.
If best Pij == P1
                then use SIDij for P1
                else return no SID

The fact that you can represent an algorithm in a few lines does not mean the implementation of the algorithm is just as simple.

[Bruno] Sure. But if we want to compare implementation complexity, we'll need to agree on how much we want to go into details, in order to have meaningful comparison. So far this is not clear to me as you sometimes argue that data structure is implementation specific and you don't want to go into this (which I agree) and sometime you detail the data structure.
There is also the option to consider this as "implementation issue" and let this to implementations.

Coming back to my per FEC algo, all what is required from the data structure, is a way/API to get the data back, though 2 keys: get me the SID matching prefix P1 (for the first line), get me the prefixes matching the SID SIDi for the second line. That seem like a reasonable requirement on the data structure, and any option in your draft also requires this to detect prefix conflict and SID conflict (since this is all my per FEC algo is doing in these 2 first lines).

Going into more details, my per FEC algo only requires to detail that one prefix or SID belong to a range (of prefix or SID) while your per range algo requires to compute range intersection which is harder. So the API to fetch the data can only be easier.

Consider what needs to be done to implement

   "Find all SIDi advertised for the prefix P1"

In its simplest form, we have a list of all SID advertisements (PFX and SRMS) that we have received. One could imagine walking all the entries, looking to see if the prefix of interest is present within the advertised range. But, of course, at large scale such an approach is extremely inefficient - so we immediately start considering ways to improve performance. Inserting received entries into an ordered tree of some kind is an obvious way to improve performance. When one further considers that calculating conflict resolution only needs to be done when a change to the received database occurs (which post startup is infrequent) it becomes very attractive to cache the "winning entries" so that if one wants to retrieve the SID for a given prefix we only have to examine a subset of the total database - ignoring the losers.
[Bruno] I agree that the per range algo (ignore overlap only) will be able to ignore the losers but at the cost of a more complex algo and at the cost of creating new derived entries. It's not clear to me if the net result is positive. Plus I would expect that the number of conflit is small compared to the number of prefix /SID so this looks like a second order optimization.

In this context, we can appreciate the difference between the three proposed algorithms. In particular comparing "Quarantine" with "ignore overlap only", a key difference is that "Quarantine" only needs to determine whether a received entry is a winning entry or a losing entry. "Ignore overlap only" has to be capable of breaking received entries with ranges > 1 into multiple "derived" entries (some winning, some losing), which means we now need to track the "derived entries" against the original received entry so that if the received entry is updated/deleted we can find all the derived entries and delete/regenerate the derived entries as needed. This is what adds complexity.
[Bruno] and that it why the per FEC algo seems easier.
So it would seem useful to add it in the draft so that we can all discuss it.

All proposed algorithms can be implemented, but it does seem prudent to consider implementation complexity as part of our decision process - and the discussion/examples in Section 3 are meant to help in doing this.

It is worthwhile restating that when conflicts are present we cannot guarantee that forwarding will work correctly no matter what algorithm is used.
[Bruno] I'm not sure to see what you have in mind exactly. Can you elaborate? To me consistency seem enough.
 The more complex the implementation the more likely it is that bugs will be present and the more likely it is that interoperability issues will arise. Whether these costs/risks are worth the "value add" when the outcome cannot be guaranteed to be correct - only guaranteed to be consistent - is an important consideration.

Also important to remember that conflicts MUST be eliminated by correcting the misconfigurations that caused them - so conflict resolution is really only an interim measure until the corrections can be made.
[Bruno] By "interim" we are at minimum talking about 10s of minutes, if not more than 1 hour since identifying the root cause may not be obvious. The impact is very significant on the network.
The "Quarantine" algo has the potential to kill 100s PE and 1000s of VPN customers, so a single configuration change on a unrelated router which may not even be in production (i.e. where configuration checks and operations hours may be relaxed)

No one should be lulled into thinking that because we have conflict resolution deployed that correcting the configuration when conflicts are detected is not a priority.
[Bruno] I could not agree more that conflict needs to be identified and fixed. Note that I'm the one having asked for defining YANG notifications to report this.
You are welcomed to state in the draft that conflicts needs to be reported to the network operator, in particular though yang notification, and other existing means. Plus that network operator needs to fixed them ASAP (but still carefully)

Thanks
--Bruno

   Les

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Thursday, June 30, 2016 5:10 AM
To: Les Ginsberg (ginsberg)
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: draft-ietf-spring-conflict-resolution - Policy

Les,

Thanks for the discussion. Please see inline [Bruno]

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Wednesday, June 29, 2016 6:00 PM
To: DECRAENE Bruno IMT/OLN
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: draft-ietf-spring-conflict-resolution - Policy

Bruno -

As the thread below documents, I stated that I did not understand your representation and asked for clarification - suggesting that you use the format defined in the draft.
You stated that you could not do that and we were at a point where no progress could be made.
[Bruno] I could _not_ use your format since your format did not include the information need. This is not a whim but a technical issue. So I asked you to still consider the message. Rather than waiting for a time-out, there was a way to make progress by asking clarification questions on the points which were not clear, or at least explicitly refusing to consider the email.

I also note that what bothered you in my representation was my addition of the type of advertisement (prefix or MS). But you finally have just added in the latest version of the draft "Src- PFX or SRMS" . So there was probably a way to communicate.

Besides the algo did not use any specification representation, just names. So I'll copy/paste it below, please ask clarification questions for the parts which are not clear enough.

The problem that we need to solve, is to find the SID for a prefix (P1).
The algo could be:
- Find all SIDi advertised for the prefix P1                                                           // identification of Prefix conflicts
                - For each SIDi find all the prefix Pij associated with SIDi              // identification of SID conflicts

// as a result, for P1, we get a list of (SIDi, Pij)

Get the best (SIDi, Pij) as per the preference algorithm.
If best Pij == P1
                then use SIDij for P1
                else return no SID                          / no SID available for this prefix P1

To illustrate my confusion, one of your examples is:

For R2, the algo evaluates a conflict between the following advertisments:
   R2 - SID2 - R2 (MS, MS)
   R2 - SID12 - R12 (prefix SID, MS)
   R2 - SID12 - R2  (prefix SID, prefix SID)

Now, what does "R2 - SID2 - R2 (MS, MS)" mean?
[Bruno]
- MS/prefix SID is the type of advertisement. In your new version, you call it SRMS/PFX.
- SID is the SID found in the Mapping Entrie
- Rx is the loopback (prefix) or router Rx

So "R2 - SID2 - R2 (MS, MS)" is the outpout of the algo described above and means: For prefix R2, we found a MS mapping entries advertising SID2 for this prefix, and then I found a MS mapping entries advertising prefix R2 for SID2.

Does it mean  "On R2, SID2 is assigned to prefix R2 from two different mapping server entries?" I really have no idea.

And you conclude the example by saying

Best one is R2 - SID12 - R2 (smaller range (prefix SID),smaller range (prefix SID))
   ==> SID12 is selected for R2.

But since there is no representation of "range" in your examples I really have no idea how you came to this conclusion .
[Bruno] I agree that since the above algo used 2 mapping entries to provides the (SIDi, Pij), the preference algo (§3.2.4) would need to be adapted. That being said, this is not important for this discussion. Let's just considered that their exist a preference algorithm, which takes as input a list of (SIDi, Piij) for P1, and gives as outpout the "best" one. (definition of "best" is not pertinent)

??

As regards "per FEC/Prefix", I believe this is what "ignore overlap only" does.
[Bruno] Indeed, this is my expectation. But I would need someone's review to confirm this.
But the difference is that the proposed algo is simple (2 lines of pseudo code), with very modest resquirement data structure use to store the mapping entries. Indeed, all it needs is a function returning the list of mapping entries associated/matching a given prefix. And function returning the list of mapping entries associated/matching a given SID.
In particular, there is no need for splitting mapping entries which is the main complexity of your proposed "Preference algorithm/ignore overlap only". (according to your own text).

-- Bruno

    Les

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Wednesday, June 29, 2016 7:22 AM
To: Les Ginsberg (ginsberg)
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: draft-ietf-spring-conflict-resolution - Policy

Les,

Thanks for the updated draft.

IINM, you have not answered my below email/proposal. I had waited for the new version of the draft but it also does not touch this subject.

So, could you please consider and answer my comment?

In short, in an implementation-independent sentence:

> I'm wondering if we could address the conflict on a per FEC/Prefix basis rather than on a per IGP advertisement (range) basis.
> If so, this may avoid the discussion between the Quarantine vs ignore policy.

Thanks
Bruno

From: spring [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Wednesday, May 18, 2016 1:57 PM
To: Les Ginsberg (ginsberg); [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] draft-ietf-spring-conflict-resolution - Policy

Les,

Please see inline [Bruno]

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Sunday, May 15, 2016 12:41 AM
To: DECRAENE Bruno IMT/OLN; [email-masked]<mailto:[email-masked]>
Subject: RE: draft-ietf-spring-conflict-resolution - Policy

Bruno -

I am having difficulty parsing the examples you provide below as they seem to incorporate advertisement source into the description whereas the draft deliberately omits source.
[Bruno] My text does not incorporate the source, but the type of source IOW the type of sub-TLV.

So it does not matter if R2 sends an advertisement or R12 sends advertisement or both of them do (which could happen when an advertisement is leaked) - what matters is what unique entries are in the database independent of source.
[Bruno] It may not matter for your algorithm (pending another thread), but it does for the one I proposed.

It would be good if you could present your examples using the format defined in the draft i.e.:
[Bruno] My examples are described in plain text. Then the examples giving intermediate steps of my algo uses the data that are needed i.e. the type of advertisement (Prefix-SID vs MS).
Then finally, my algo runs on a per FEC/IP Prefix basis, and not on a per IGP advertisement basis which your format describe.
So I'm sorry but I don't see how to indulge your request.

    Pi - Initial prefix
     Pe - End prefix
     L -  Prefix length
     Lx - Maximum prefix length (32 for IPv4, 128 for IPv6)
     Si - Initial SID value
     Se - End SID value
     R -  Range value
     T - Topology
     A - Algorithm

     A Mapping Entry is then the tuple: (Pi/L, Si, R, T, A)
     Pe = (Pi + ((R-1) << (Lx-L))
     Se = Si + (R-1)

Example:     (192.0.2.120/32, 200, 1, 0, 0)

As regards your proposal

- Find all SIDi advertised for the prefix P1                                                           // identification of Prefix conflicts
                - For each SIDi find all the prefix Pij associated with SIDi              // identification of SID conflicts

Get the best as per the preference algorithm.
If best Pij == P1
                then use SIDij for P1
                else return no SID

this to me specifies an implementation - which isn't necessary.
[Bruno] Well, _you_ are the one talking about implementation, and more specifically implementation complexity.
Assuming the above algo works, it looks relatively simple to implement, in which case, I would not buy the argument about implementation complexity which is the only argument in favor or the "ignore" or "quarantine" policy.
Bottom line, I would welcome your feedback and comments on this proposed algo/policy.

Thanks,
Regards,
-- Bruno

However, there is one important point which has not been specified in the draft which reading your post has brought to my attention - that is the order in which checks are made.
The draft states:

"Prefix conflicts are specific to mapping entries sharing  the same topology and algorithm."
"SID conflicts are independent of address-family,  independent of prefix len, independent of topology, and independent  of algorithm."

If we consider an example where a network supports two VPNs, the significance of ordering in the evaluation of conflicts will be highlighted:

VPN1:
(192.0.2.1/32, 100, 1, 1, 0)
(192.0.2.1/32, 200, 1, 1, 0)

VPN2:

(192.0.2.100/32, 200, 1, 2, 0)

If we evaluate prefix conflicts first, then the following entries are "active":
(192.0.2.1/32, 100, 1, 1, 0) !VPN1
(192.0.2.100/32, 200, 1, 2, 0) !VPN2

If we evaluate SID conflicts first, then the following entries are "active":
(192.0.2.1/32, 100, 1, 1, 0) !VPN1

The latter choice is suboptimal because it prevents use of the VPN2 entry unnecessarily.

This point needs to be made explicit in the draft.

    Les

From: spring [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Thursday, May 12, 2016 8:23 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [spring] draft-ietf-spring-conflict-resolution - Policy

Hi authors, all

As an individual contributor, please find below some feedback on the policy.

I'm wondering if we could address the conflict on a per FEC/Prefix basis rather than on a per IGP advertisement basis.
If so, this may avoid the discussion between the Quarantine vs ignore policy.

The problem that we need to solve, is to find the SID for a prefix (P1).
The algo could be:
- Find all SIDi advertised for the prefix P1                                                           // identification of Prefix conflicts
                - For each SIDi find all the prefix Pij associated with SIDi              // identification of SID conflicts

// as a result, we get a list of SIDi - Pij for P1

Get the best as per the preference algorithm.
If best Pij == P1
                then use SIDij for P1
                else return no SID                          / no SID available for this prefix P1

   Note that it would probably be better for the preference algo to put the SID tie-brake before the prefix tie-break as with the prefix tie-break, we suffer from the conflict twice (Prefix - SID mapping, then SID- prefix mapping) which increase the diversity and hence the chance of not finding a valid entry.   But for the below examples, I used the preference algo from draft-ietf-*-00

Below are examples, running this policy on typical configuration error cases.
Examples
3.4.4.  Network operation

   Consider the following simple network example:

   1.  100 nodes: R1 to R100;

   2.  IP Loopbacks are from 192.0.2.1 to 192.0.2.100:

   3.  SID are from 1 to 100;

   4.  R1 to R50 are SR capable and advertised their own SID using
       Prefix-SID sub-TLV;

   5.  R51 to R100 are SR non-capable, running LDP and their SID are
       advertised by two redundant Mapping Server MS1 and MS2;

   6.  As the number of nodes which are SR capable are expected to
       increase and as in real deployment their Loopback addresses would
       no the contiguous, the Mapping servers advertisement covers all
       Loopbacks: (192.0.2.1/32, 1, 100);

   Subsequent sections evaluate the consequences of a single
   configuration error, for all conflict resolution options.

3.4.4.1.  Example 1: SID configured on 1 node conflict with SID
          configured on another node

   Following a typo during configuration, R2 is configured with a SID of
   12.  That SID conflicts with the Prefix-SID advertised by R12 and the Mapping Server Advertisement for R12.
   Note: both MS advertisement are the same, so we only consider one in the below analysis.

   All prefix but R2 and R12, a single SID is advertised and hence selected.

   For R2, the algo evaluates a conflict between the following advertisments:
   R2 - SID2 - R2 (MS, MS)
   R2 - SID12 - R12 (prefix SID, MS)
   R2 - SID12 - R2  (prefix SID, prefix SID)

   Best one is R2 - SID12 - R2 (smaller range (prefix SID),smaller range (prefix SID))
   ==> SID12 is selected for R2.

   For R12, the algo evaluates a conflict between the following advertisments:
   R12 - SID12 - R12 (prefix SID, prefix SID)
   R12 - SID12 - R2  (prefix SID, prefix SID)
   R12 - SID12 - R12 (prefix SID, MS)
   R12 - SID12 - R2  (MS, prefix SID)
   R12 - SID12 - R12 (MS, MS)

   Best one is R12 - SID12 - R2 (smaller range (prefix SID),smaller range (prefix SID), smaller starting adresse (R2))
   R12 <> R2 ==> R12 has no SID.

   3.4.4.2.  Example 2: SID configured on 1 node conflict with SID
          configured on the Mapping Server

   Following a typo during configuration, R2 is configured with a SID of
   52.  That SID conflicts with the Mapping Server advertisements of MS1
   and MS2 for the loopback of R52.
   Note: both MS advertisement are the same, so we only consider one in the below analysis.

   All prefix but R2 and R52, a single SID is advertised and hence selected.

   For R2, the algo evaluates a conflict between the following advertisments:
   R2 - SID52 - R2  (prefix SID, prefix SID)
   R2 - SID52 - R52 (prefix SID, MS)
   R2 - SID2  - R2  (MS, MS)

   Best one is R2 - SID52 - R2 (smaller range (prefix SID),smaller range (prefix SID))
   ==> SID52 is selected for R2.

   For R52, the algo evaluates a conflict between the following advertisments:
   R52 - SID52 - R52 (MS, MS)
   R52 - SID52 - R2  (MS, prefix SID)

   Best one is R52 - SID52 - R2 (smaller range (prefix SID))
   R52 <> R2 ==> R52 has no SID.

3.4.4.3.  Example 3: wrong configuration of a MS

   Following a typo during configuration, MS1 is configured
   (192.0.2.0/32, 1, 100). (i.e. 192.0.2.0 instead of 192.0.2.1).  That
   advertisement conflicts with the Mapping Server advertisements of MS2
   and the Prefix-SID advertised by R1...R50.

   We have a conflict for all routers except R100.

   For LDP only routers R51 to R99 we have a conflict between both MS advertisement.
   For R52, the algo evaluates a conflict between the following advertisments:
   R52 - SID52 - R52 (MS2, MS2)
   R52 - SID52 - R51 (MS2, MS1)
   R52 - SID53 - R52 (MS1, MS1)
   R52 - SID53 - R53 (MS1, MS2)

   Best one is R52 - SID52 - R51 (smaller starting address)
   R52 <> R51 ==> R52 has no SID.

   For SR routers, R1 to 50, we have a conflict between both MS advertisement and Prefix SID advertisements.
   For R2, the algo evaluates a conflict between the following advertisments:
   R2 - SID 2 - R2 (Prefix SID, Prefix SID)
   R2 - SID 2 - R2 (Prefix SID, MS2)
   R2 - SID 2 - R1 (Prefix SID, MS1)
   R2 - SID 2 - R2 (MS2, MS2)
   R2 - SID 2 - R2 (MS2, Prefix SID)
   R2 - SID 2 - R1 (MS2, MS1)
   R2 - SID 3 - R2  (MS1, MS1)
   R2 - SID 3 - R3  (MS1, MS2)
   R2 - SID 3 - R3  (MS1, Prefix SID)

   Best one is R2 - SID 2 - R2 (Prefix SID, Prefix SID)
   R2 == R2 hence R2 use SID2.

Regards,
Bruno

_________________________________________________________________________________________________________________________

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.

_________________________________________________________________________________________________________________________

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.

_________________________________________________________________________________________________________________________

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.

_________________________________________________________________________________________________________________________

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.

_________________________________________________________________________________________________________________________

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: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 5 Jul 2016 07:08:23 +0000

Bruno -

Consider the following simple case:

Entry #1: (PFX, 1.1.1.1/32, 100, 1, 0,0)
Entry #2: (SRMS, 1.1.1.1/32, 200, 10, 0,0)
Entry #3: (SRMS, 2.2.2.2/32, 200, 10. 0, 0)

There is a misconfiguration here, but we don't know what was really intended. A few (of many) possibilities:

ERROR #1:   Entry #2 should have been: (SRMS, 1.1.1.1/32, 100, 10, 0,0) !Starting SID error
ERROR #2:  Entry #2 should have been: (SRMS, 2.2.2.2/32, 200, 10, 0,0) !Starting prefix error

The draft defines two candidate preference rules which could be applied:

Quarantine
----------------
As we evaluate prefix conflicts first, we compare Entry #1 and Entry #2 and choose Entry #1 the winner (source is PFX). Entry #2 is then not used (quarantined) and the set of active entries is:

Entry #1: (PFX, 1.1.1.1/32, 100, 1, 0,0)
Entry #3: (SRMS, 2.2.2.2/32, 200, 10. 0, 0)

Ignore Conflict Only
-------------------------
In this case we split Entry #2 into two derived entries:

Entry #2A: (SRMS, 1.1.1.1/32, 200, 1, 0,0)
Entry #2B: (SRMS, 1.1.1.2/32, 201, 9, 0,0)

Entry 2A is then ignored and we then have to evaluate SID conflicts between the derived entry 2B and Entry #3.  For this we have to split Entry 3 into two derived entries:

Entry #3A: (SRMS, 2.2.2.2/32, 200, 1. 0, 0)
Entry #3B: (SRMS, 2.2.2.3/32, 201, 9. 0, 0)

Entry 2B wins over entry 3B since it has a smaller range.

Active entries are then:
Entry #1: (PFX, 1.1.1.1/32, 100, 1, 0,0)
Entry #2B: (SRMS, 1.1.1.2/32, 201, 9, 0,0)
Entry #3A: (SRMS, 2.2.2.2/32, 200, 1. 0, 0)

Note that in this example both preference rules result in 11 destinations having non-conflicting SIDs.  Now, which of these maximizes delivery of traffic? The answer to that depends upon the type of configuration error that was made.
If Error #1 was made, there is no way to differentiate the two preference rules.
However, if Error #2 was made, then Quarantine is clearly better because the destinations 1.1.1.2 - 1.1.1.10 were never intended to have assigned SIDs and may not even exist as destinations in the network, yet "Ignore Conflict Only" favors those prefixes.

The point I am trying to make is that it is incorrect to say "If we maximize the number of advertised entries which we use we will always do a better job of delivering traffic." This example illustrates that this isn't always true.

A few more comments inline.

From: [email-masked] [mailto:[email-masked]]
Sent: Monday, July 04, 2016 5:07 AM
To: Les Ginsberg (ginsberg)
Cc: [email-masked]
Subject: RE: draft-ietf-spring-conflict-resolution - Policy

Les,

Bruno -

[Les:] Range intersection is easy to compute - the algorithm is present in the draft at the end of  Section 3.1.1.

[Les:] Ignore overlap only is the same as per FEC. We may use different words to describe it, but the end behavior is the same.

   Les

Thanks
--Bruno

   Les

Les,

Bruno -

??

-- Bruno

    Les

Les,

Thanks
Bruno

Les,

Bruno -

    Pi - Initial prefix
     Pe - End prefix
     L -  Prefix length

As regards your proposal

Thanks,
Regards,
-- Bruno

VPN1:

VPN2:

    Les

Hi authors, all

Regards,
Bruno

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 5 Jul 2016 17:25:01 +0000

Bruno -

Two comments:

1)As we both can come up with examples where a given  preference algorithm will result in "better" behavior than another, continuing to debate which one is "best" has no end. The answer depends upon what types of errors are introduced in the configuration and that isn't predictable. If it is necessary for us to agree on which algorithm is "best" I doubt that consensus will ever be reached. It therefore is more important to me to focus on implementation complexity and the importance of identifying and correcting misconfigurations ASAP.

2)There are two logical databases that an implementation has to support. One of them is the set of received advertisements which can include entries with a variety of ranges. The second one is the set of mapping entries which are in use for lookups.
Your discussion of your "per FEC algorithm"  below defines the second database as a set of entries all of which have a range of 1. Whether this is good implementation model or not I am not commenting on here. But this does not eliminate the need to maintain the first database - and to be able to associate entries in the second database with the corresponding received entry from which they may have been derived. There is work in maintaining that relationship which does not directly bear on the lookup for a given SID but still has to be done if one uses "per FEC" or "Ignore Overlap Only". This work is not required for the "per range" or "Quarantine" algorithm. It is this additional work that I refer to when I say that "per FEC" has a higher implementation cost/complexity.

   Les

From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, July 05, 2016 1:50 AM
To: Les Ginsberg (ginsberg)
Cc: [email-masked]
Subject: RE: draft-ietf-spring-conflict-resolution - Policy

Les,

Sent: Tuesday, July 05, 2016 9:08 AM

Bruno -

Quarantine
----------------

Ignore Conflict Only

Active entries are then:

Note that in this example both preference rules result in 11 destinations having non-conflicting SIDs.
[Bruno] Yes. The important part is « in this example ». Now do we agree that in average, Quarantine will result in dropping more destinations than Ignore conflict only?

 Now, which of these maximizes delivery of traffic? The answer to that depends upon the type of configuration error that was made.
If Error #1 was made, there is no way to differentiate the two preference rules.
However, if Error #2 was made, then Quarantine is clearly better because the destinations 1.1.1.2 - 1.1.1.10 were never intended to have assigned SIDs and may not even exist as destinations in the network, yet "Ignore Conflict Only" favors those prefixes.

The point I am trying to make is that it is incorrect to say "If we maximize the number of advertised entries which we use we will always do a better job of delivering traffic." This example illustrates that this isn't always true.
[Bruno] OK. Clearly, we can find an example where an algorithm is better than the other. After all, we all agree that there has been a configuration error.
There are 2 points:

a)      how many destination you keep using

b)      in case of conflict which of the entries you select

I agree that "b" is more or less random and hence there are many cases where we'll pick the wrong one. Yet, we try to make reasonable choices. That the point of discussing the preference algorithm (3.2.4). (Although it's very easy to argue that we can make the wrong choice, I don't feel that's a reason not to try discussing it and make choice. e.g. "PFX source wins over SRMS source" is one: we give preference to SR nodes rather than LDP nodes.

Regarding a, I feel that maximizing the number of destinations kept, is likely to give the best result in average. I don't have a proof, but it feel like playing loto: even if each choice is random ("b"), the more you try ("a") the better your chances.

Les,

Bruno -

[Les:] Range intersection is easy to compute - the algorithm is present in the draft at the end of  Section 3.1.1.
[Bruno] In order to have a meaningful discussion, we need to define the level of details that we want to take into account, because you're not using the same one to discuss your algo and mine.
1) As a first level of comparison, using the description at the end of section 3.1.1 as a model, for range prefix conflict your algo is:
   1)(T1 == T2) && (A1 == A2)
   2)P1 <= P2
   3)The prefixes are in the same address family.
   2)L1 == L2
   3)(P1e >= P2) && ((S1 + (P2 - P1)) != S2)

So for (FEC) prefix conflict my algo is:
   1)(T1 == T2) && (A1 == A2)
   2)P1 = P2
   3)The prefixes are in the same address family.
   2)L1 == L2

(BTW, in the draft, there is a typo in the numbering)
It looks clear that FEC comparison is easier than prefix range intersection.

2) Going deeper, at the algo complexity

The FEC algo needs: get_SIDs(Prefix), and all the work is done. So all the algo complexity is coming from the datastructure. It seems pretty reasonable to find a datastructure << o(n) (e.g. a tree, but you will be much better than me in finding one)
For the range algo, it's not clear to me that a data structure can be found to automatically find the result. If not, the algo seems to compare all entries two by two, which would get o(n*(n-1)...(2)) i.e. o(n!)

[Les:] Ignore overlap only is the same as per FEC. We may use different words to describe it, but the end behavior is the same.
[Bruno] good if this get the same result. Yet the algo is different.

-- Bruno

   Les

Thanks
--Bruno

   Les

Les,

Bruno -

??

-- Bruno

    Les

Les,

Thanks
Bruno

Les,

Bruno -

    Pi - Initial prefix
     Pe - End prefix
     L -  Prefix length

As regards your proposal

Thanks,
Regards,
-- Bruno

VPN1:

VPN2:

    Les

Hi authors, all

Regards,
Bruno

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

---

From: Shraddha Hegde <[email-masked]>
Date: Tue, 12 Jul 2016 14:54:19 +0000

Hi Les,

1. Quarantine policy has certain disadvantages. One of the major disadvantage comes from the fact that the preference
rule has "smallest range wins" on top. What this would mean is that whenever a there is a conflict with a smaller and bigger range
Bigger range loses. If it gets quarantined, you would lose connectivity to all the prefixes in the bigger range
so the impact of the policy on operations is huge. In case of "ignore overlap only" policy impact would be on the conflict entries only.

I am not suggesting any change to the preference rules but trying to bring about the fact that quarantine policy has operational disadvantages.
I see that this point has been brought up by other on the thread as well and if you agree this is a disadvantage,
it should be clearly spelt out in the draft to bring it to the notice of wider audience.

Human error is not uncommon. In fact, "human error" features in one of the top 10 common reasons for network failures.
We should have an efficient mechanism to reduce the impact of human error. If 1000 customers loose connectivity
due to one configuration error, I can only see the issue getting escalated and operations, support staff, engineers
having to respond in the middle of the night to root cause and fix the issue.

2. section 3.2.7 mentions "ignore-overlap-only" policy as very complex to implement
   and also gives details of necessity to have two databases one raw and another derived.
While I fully agree that implementing "ignore overlap only" policy is more involved than the "quarantine"
policy, I do not see it as fundamentally different than what IGPs do today.
IGPs have two databases one is LSDB and other routes.
LSDB is from created advertisements and routes is a derived database and there are inter-linkings between them.

3. Having quarantine policy makes the SR deployment harder. In today's world if there is an
   ip address conflict, the traffic gets affected for only that prefix. Consider a case of 1000 prefixes getting
redistributed into IGP from an external source and a prefix range/sids getting assigned on the redistributing node.
If one of those 1000 prefixes get redistributed via another node as well and there is a mistake in SID assignment
to that prefix, Quarantine policy would result in losing connectivity to all 1000 prefixes. If you consider similar
configuration error in non-SR world with LDP in deployment, misconfigured ip address would impact only that particular prefix.

Rgds
Shraddha

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Tuesday, July 5, 2016 10:55 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [spring] draft-ietf-spring-conflict-resolution - Policy

Bruno -

Two comments:

   Les

Les,

Bruno -

Quarantine
----------------

Ignore Conflict Only

Active entries are then:

Les,

Bruno -

-- Bruno

   Les

Thanks
--Bruno

   Les

Les,

Bruno -

??

-- Bruno

    Les

Les,

Thanks
Bruno

Les,

Bruno -

    Pi - Initial prefix
     Pe - End prefix
     L -  Prefix length

As regards your proposal

Thanks,
Regards,
-- Bruno

VPN1:

VPN2:

    Les

Hi authors, all

Regards,
Bruno

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

---

From: Martin Horneffer <[email-masked]>
Date: Fri, 22 Jul 2016 11:01:39 +0200

Hi Les,

commenting rather on your presentation at the Berlin WG session:

In general I don't consider it a big deal whether the Quarantine or the 
Ignore Overlap policy is being used. It's mainly important that _one_ of 
then finally gets chosen and consistently implemented.

 From the operator's point of view I tend to agree with other operators 
that the Ignore Overlap policy looks better for most realistic cases, 
even though less worried about the amount of traffic lost, but more 
about robustness and security aspects.

Complexity of implementation, however, can be a serious argument against 
it, as this also works against robustness and security.

Nobody doubts that the Ignore Overlap policy is more complex. But how 
much complexity it really adds is hard to estimate for me. Is it a minor 
complication or a big one?

So far I have seen one vendor talk against the Ignore Overlap policy and 
two vendors taking a position in favor of it.

Sounds to me like 2:1 for Ignore Overlap so far. But we actually don't 
believe in voting and need more vendor input anyways!

BR,
Martin

Am 05.07.16 um 19:25 schrieb Les Ginsberg (ginsberg):
>
> Bruno –
>
> Two comments:
>
> 1)As we both can come up with examples where a given  preference 
> algorithm will result in “better” behavior than another, continuing to 
> debate which one is “best” has no end. The answer depends upon what 
> types of errors are introduced in the configuration and that isn’t 
> predictable. If it is necessary for us to agree on which algorithm is 
> “best” I doubt that consensus will ever be reached. It therefore is 
> more important to me to focus on implementation complexity and the 
> importance of identifying and correcting misconfigurations ASAP.
>
> 2)There are two logical databases that an implementation has to 
> support. One of them is the set of received advertisements which can 
> include entries with a variety of ranges. The second one is the set of 
> mapping entries which are in use for lookups.
>
> Your discussion of your “per FEC algorithm”  below defines the second 
> database as a set of entries all of which have a range of 1. Whether 
> this is good implementation model or not I am not commenting on here. 
> But this does not eliminate the need to maintain the first database – 
> and to be able to associate entries in the second database with the 
> corresponding received entry from which they may have been derived. 
> There is work in maintaining that relationship which does not directly 
> bear on the lookup for a given SID but still has to be done if one 
> uses “per FEC” or “Ignore Overlap Only”. This work is not required for 
> the “per range” or “Quarantine” algorithm. It is this additional work 
> that I refer to when I say that “per FEC” has a higher implementation 
> cost/complexity.
>
>    Les
>
> *From:[email-masked] [mailto:[email-masked]]
> *Sent:* Tuesday, July 05, 2016 1:50 AM
> *To:* Les Ginsberg (ginsberg)
> *Cc:* [email-masked]
> *Subject:* RE: draft-ietf-spring-conflict-resolution - Policy
>
> Les,
>
> *From:*Les Ginsberg (ginsberg) [mailto:[email-masked]]
> *Sent:* Tuesday, July 05, 2016 9:08 AM
> *To:* DECRAENE Bruno IMT/OLN
> *Cc:* [email-masked] <mailto:[email-masked]>
> *Subject:* RE: draft-ietf-spring-conflict-resolution - Policy
>
> Bruno –
>
> There is a misconfiguration here, but we don’t know what was really 
> intended. A few (of many) possibilities:
>
> As we evaluate prefix conflicts first, we compare Entry #1 and Entry 
> #2 and choose Entry #1 the winner (source is PFX). Entry #2 is then 
> not used (quarantined) and the set of active entries is:
>
> Entry 2A is then ignored and we then have to evaluate SID conflicts 
> between the derived entry 2B and Entry #3.  For this we have to split 
> Entry 3 into two derived entries:
>
> Note that in this example both preference rules result in 11 
> destinations having non-conflicting SIDs.
>
> [Bruno] Yes. The important part is « in this example ». Now do we 
> agree that in average, Quarantine will result in dropping more 
> destinations than Ignore conflict only?
>
>  Now, which of these maximizes delivery of traffic? The answer to that 
> depends upon the type of configuration error that was made.
>
> However, if Error #2 was made, then Quarantine is clearly better 
> because the destinations 1.1.1.2 – 1.1.1.10 were never intended to 
> have assigned SIDs and may not even exist as destinations in the 
> network, yet “Ignore Conflict Only” favors those prefixes.
>
> The point I am trying to make is that it is incorrect to say “If we 
> maximize the number of advertised entries which we use we will always 
> do a better job of delivering traffic.” This example illustrates that 
> this isn’t always true.
>
> [Bruno] OK. Clearly, we can find an example where an algorithm is 
> better than the other. After all, we all agree that there has been a 
> configuration error.
>
> There are 2 points:
>
> a)how many destination you keep using
>
> b)in case of conflict which of the entries you select
>
> I agree that “b” is more or less random and hence there are many cases 
> where we’ll pick the wrong one. Yet, we try to make reasonable 
> choices. That the point of discussing the preference algorithm 
> (3.2.4). (Although it’s very easy to argue that we can make the wrong 
> choice, I don’t feel that’s a reason not to try discussing it and make 
> choice. e.g. “PFX source wins over SRMS source” is one: we give 
> preference to SR nodes rather than LDP nodes.
>
> Regarding a, I feel that maximizing the number of destinations kept, 
> is likely to give the best result in average. I don’t have a proof, 
> but it feel like playing loto: even if each choice is random (“b”), 
> the more you try (“a”) the better your chances.
>
> *From:[email-masked] 
> <mailto:[email-masked]>[mailto:[email-masked]]
> *Sent:* Monday, July 04, 2016 5:07 AM
> *To:* Les Ginsberg (ginsberg)
> *Cc:* [email-masked] <mailto:[email-masked]>
> *Subject:* RE: draft-ietf-spring-conflict-resolution - Policy
>
> Les,
>
> *From:*Les Ginsberg (ginsberg) [mailto:[email-masked]]
> *Sent:* Friday, July 01, 2016 3:12 AM
> *To:* DECRAENE Bruno IMT/OLN
> *Cc:* [email-masked] <mailto:[email-masked]>
> *Subject:* RE: draft-ietf-spring-conflict-resolution - Policy
>
> Bruno –
>
> I don’t find your representation complete as regards all of the 
> attributes which are proposed to be used by the conflict resolution 
> algorithm – so it is therefore hard for me to use/understand this 
> representation when applying the defined preference rule.
>
> But it is far more important to have a common understanding of the 
> algorithm proposal than it is to be arguing over whose encoding is 
> “better”. If the encoding in the draft is not clear or could use 
> improvement, I welcome your feedback.
>
> As far as your “pseudo-code”:
>
> /- Find all SIDi advertised for the prefix P1 // identification of 
> Prefix conflicts/
>
> /                - For each SIDi find all the prefix Pij associated 
> with SIDi              // identification of SID conflicts/
>
> //
>
> /Get the best as per the preference algorithm./
>
> /If best Pij == P1/
>
> /                then use SIDij for P1/
>
> /                else return no SID/
>
> The fact that you can represent an algorithm in a few lines does not 
> mean the implementation of the algorithm is just as simple.
>
> [Bruno] Sure. But if we want to compare implementation complexity, 
> we’ll need to agree on how much we want to go into details, in order 
> to have meaningful comparison. So far this is not clear to me as you 
> sometimes argue that data structure is implementation specific and you 
> don’t want to go into this (which I agree) and sometime you detail the 
> data structure.
>
> There is also the option to consider this as “implementation issue” 
> and let this to implementations.
>
> Coming back to my per FEC algo, all what is required from the data 
> structure, is a way/API to get the data back, though 2 keys: get me 
> the SID matching prefix P1 (for the first line), get me the prefixes 
> matching the SID SIDi for the second line. That seem like a reasonable 
> requirement on the data structure, and any option in your draft also 
> requires this to detect prefix conflict and SID conflict (since this 
> is all my per FEC algo is doing in these 2 first lines).
>
> Going into more details, my per FEC algo only requires to detail that 
> one prefix or SID belong to a range (of prefix or SID) while your per 
> range algo requires to compute range intersection which is harder. So 
> the API to fetch the data can only be easier.
>
> */[Les:] Range intersection is easy to compute – the algorithm is 
> present in the draft at the end of  Section 3.1.1./*
>
> [Bruno] In order to have a meaningful discussion, we need to define 
> the level of details that we want to take into account, because you’re 
> not using the same one to discuss your algo and mine.
>
> 1) As a first level of comparison, using the description at the end of 
> section 3.1.1 as a model, for range prefix conflict your algo is:
>
> The FEC algo needs: get_SIDs(Prefix), and all the work is done. So all 
> the algo complexity is coming from the datastructure. It seems pretty 
> reasonable to find a datastructure << o(n) (e.g. a tree, but you will 
> be much better than me in finding one)
>
> For the range algo, it’s not clear to me that a data structure can be 
> found to automatically find the result. If not, the algo seems to 
> compare all entries two by two, which would get o(n*(n-1)…(2)) i.e. o(n!)
>
> “Find all SIDi advertised for the prefix P1”
>
> In its simplest form, we have a list of all SID advertisements (PFX 
> and SRMS) that we have received. One could imagine walking all the 
> entries, looking to see if the prefix of interest is present within 
> the advertised range. But, of course, at large scale such an approach 
> is extremely inefficient – so we immediately start considering ways to 
> improve performance. Inserting received entries into an ordered tree 
> of some kind is an obvious way to improve performance. When one 
> further considers that calculating conflict resolution only needs to 
> be done when a change to the received database occurs (which post 
> startup is infrequent) it becomes very attractive to cache the 
> “winning entries” so that if one wants to retrieve the SID for a given 
> prefix we only have to examine a subset of the total database – 
> ignoring the losers.
>
> [Bruno] I agree that the per range algo (ignore overlap only) will be 
> able to ignore the losers but at the cost of a more complex algo and 
> at the cost of creating new derived entries. It’s not clear to me if 
> the net result is positive. Plus I would expect that the number of 
> conflit is small compared to the number of prefix /SID so this looks 
> like a second order optimization.
>
> In this context, we can appreciate the difference between the three 
> proposed algorithms. In particular comparing “Quarantine” with “ignore 
> overlap only”, a key difference is that “Quarantine” only needs to 
> determine whether a received entry is a winning entry or a losing 
> entry. “Ignore overlap only” has to be capable of breaking received 
> entries with ranges > 1 into multiple “derived” entries (some winning, 
> some losing), which means we now need to track the “derived entries” 
> against the original received entry so that if the received entry is 
> updated/deleted we can find all the derived entries and 
> delete/regenerate the derived entries as needed. This is what adds 
> complexity.
>
> */[Les:] Ignore overlap only is the same as per FEC. We may use 
> different words to describe it, but the end behavior is the same./*
>
> */Les/*
> *//*
> All proposed algorithms can be implemented, but it does seem prudent 
> to consider implementation complexity as part of our decision process 
> – and the discussion/examples in Section 3 are meant to help in doing 
> this.
>
> It is worthwhile restating that when conflicts are present we cannot 
> guarantee that forwarding will work correctly no matter what algorithm 
> is used.
>
> [Bruno] I’m not sure to see what you have in mind exactly. Can you 
> elaborate? To me consistency seem enough.
>
>  The more complex the implementation the more likely it is that bugs 
> will be present and the more likely it is that interoperability issues 
> will arise. Whether these costs/risks are worth the “value add” when 
> the outcome cannot be guaranteed to be correct – only guaranteed to be 
> consistent – is an important consideration.
>
> Also important to remember that conflicts MUST be eliminated by 
> correcting the misconfigurations that caused them – so conflict 
> resolution is really only an interim measure until the corrections can 
> be made.
>
> [Bruno] By “interim” we are at minimum talking about 10s of minutes, 
> if not more than 1 hour since identifying the root cause may not be 
> obvious. The impact is very significant on the network.
>
> The “Quarantine” algo has the potential to kill 100s PE and 1000s of 
> VPN customers, so a single configuration change on a unrelated router 
> which may not even be in production (i.e. where configuration checks 
> and operations hours may be relaxed)
>
> No one should be lulled into thinking that because we have conflict 
> resolution deployed that correcting the configuration when conflicts 
> are detected is not a priority.
>
> [Bruno] I could not agree more that conflict needs to be identified 
> and fixed. Note that I’m the one having asked for defining YANG 
> notifications to report this.
>
> You are welcomed to state in the draft that conflicts needs to be 
> reported to the network operator, in particular though yang 
> notification, and other existing means. Plus that network operator 
> needs to fixed them ASAP (but still carefully)
>
> Thanks
>
> --Bruno
>
>    Les
>
> *From:[email-masked] 
> <mailto:[email-masked]>[mailto:[email-masked]]
> *Sent:* Thursday, June 30, 2016 5:10 AM
> *To:* Les Ginsberg (ginsberg)
> *Cc:* [email-masked] <mailto:[email-masked]>
> *Subject:* RE: draft-ietf-spring-conflict-resolution - Policy
>
> Les,
>
> *From:*Les Ginsberg (ginsberg) [mailto:[email-masked]]
> *Sent:* Wednesday, June 29, 2016 6:00 PM
> *To:* DECRAENE Bruno IMT/OLN
> *Cc:* [email-masked] <mailto:[email-masked]>
> *Subject:* RE: draft-ietf-spring-conflict-resolution - Policy
>
> Bruno –
>
> As the thread below documents, I stated that I did not understand your 
> representation and asked for clarification – suggesting that you use 
> the format defined in the draft.
>
> [Bruno] I could _/not/_ use your format since your format did not 
> include the information need. This is not a whim but a technical 
> issue. So I asked you to still consider the message. Rather than 
> waiting for a time-out, there was a way to make progress by asking 
> clarification questions on the points which were not clear, or at 
> least explicitly refusing to consider the email.
>
> I also note that what bothered you in my representation was my 
> addition of the type of advertisement (prefix or MS). But you finally 
> have just added in the latest version of the draft “Src- PFX or SRMS”. 
> So there was probably a way to communicate.
>
> Besides the algo did not use any specification representation, just 
> names. So I’ll copy/paste it below, please ask clarification questions 
> for the parts which are not clear enough.
>
> /For R2, the algo evaluates a conflict between the following 
> advertisments:/
>
> /   R2 - SID2 - R2 (MS, MS)/
>
> /   R2 - SID12 - R12 (prefix SID, MS) /
>
> /   R2 - SID12 - R2  (prefix SID, prefix SID)/
>
> //
>
> Now, what does “R2 - SID2 - R2 (MS, MS)” mean?
>
> [Bruno]
>
> So “R2- SID2 - R2 (MS, MS)” is the outpout of the algo described above 
> and means: For prefix R2, we found a MS mapping entries advertising 
> SID2 for this prefix, and then I found a MS mapping entries 
> advertising prefix R2 for SID2.
>
> Does it mean  “On R2, SID2 is assigned to prefix R2 from two different 
> mapping server entries?” I really have no idea.
>
> /Best one is R2 - SID12 - R2 (smaller range (prefix SID),smaller range 
> (prefix SID))/
>
> /   ==> SID12 is selected for R2./
>
> But since there is no representation of “range” in your examples I 
> really have no idea how you came to this conclusion .
>
> [Bruno] I agree that since the above algo used 2 mapping entries to 
> provides the (SIDi, Pij), the preference algo (§3.2.4) would need to 
> be adapted. That being said, this is not important for this 
> discussion. Let’s just considered that their exist a preference 
> algorithm, which takes as input a list of (SIDi, Piij) for P1, and 
> gives as outpout the “best” one. (definition of “best” is not pertinent)
>
> ??
>
> As regards “per FEC/Prefix”, I believe this is what “ignore overlap 
> only” does.
>
> [Bruno] Indeed, this is my expectation. But I would need someone’s 
> review to confirm this.
>
> But the difference is that the proposed algo is simple (2 lines of 
> pseudo code), with very modest resquirement data structure use to 
> store the mapping entries. Indeed, all it needs is a function 
> returning the list of mapping entries associated/matching a given 
> prefix. And function returning the list of mapping entries 
> associated/matching a given SID.
>
> In particular, there is no need for splitting mapping entries which is 
> the main complexity of your proposed “Preference algorithm/ignore 
> overlap only”. (according to your own text).
>
> -- Bruno
>
> Les
>
> *From:[email-masked] 
> <mailto:[email-masked]>[mailto:[email-masked]]
> *Sent:* Wednesday, June 29, 2016 7:22 AM
> *To:* Les Ginsberg (ginsberg)
> *Cc:* [email-masked] <mailto:[email-masked]>
> *Subject:* RE: draft-ietf-spring-conflict-resolution - Policy
>
> Les,
>
> IINM, you have not answered my below email/proposal. I had waited for 
> the new version of the draft but it also does not touch this subject.
>
> > I'm wondering if we could address the conflict on a per FEC/Prefix 
> basis rather than on a per IGP advertisement (range) basis.
>
> *From:*spring [mailto:[email-masked]] *On Behalf Of 
> [email-masked] <mailto:[email-masked]>
> *Sent:* Wednesday, May 18, 2016 1:57 PM
> *To:* Les Ginsberg (ginsberg); [email-masked] <mailto:[email-masked]>
> *Subject:* Re: [spring] draft-ietf-spring-conflict-resolution - Policy
>
> Les,
>
> *From:*Les Ginsberg (ginsberg) [mailto:[email-masked]]
> *Sent:* Sunday, May 15, 2016 12:41 AM
> *To:* DECRAENE Bruno IMT/OLN; [email-masked] <mailto:[email-masked]>
> *Subject:* RE: draft-ietf-spring-conflict-resolution - Policy
>
> Bruno –
>
> I am having difficulty parsing the examples you provide below as they 
> seem to incorporate advertisement source into the description whereas 
> the draft deliberately omits source.
>
> So it does not matter if R2 sends an advertisement or R12 sends 
> advertisement or both of them do (which could happen when an 
> advertisement is leaked) – what matters is what unique entries are in 
> the database independent of source.
>
> [Bruno] My examples are described in plain text. Then the examples 
> giving intermediate steps of my algo uses the data that are needed 
> i.e. the type of advertisement (Prefix-SID vs MS).
>
> Then finally, my algo runs on a per FEC/IP Prefix basis, and not on a 
> per IGP advertisement basis which your format describe.
>
> So I’m sorry but I don’t see how to indulge your request.
>
> /    Pi - Initial prefix/
>
> /     Pe - End prefix/
>
> /     L -  Prefix length/
>
> /     Lx - Maximum prefix length (32 for IPv4, 128 for IPv6)/
>
> /     Si - Initial SID value/
>
> /     Se - End SID value/
>
> /     R -  Range value/
>
> /     T - Topology/
>
> /     A - Algorithm/
>
> //
>
> /     A Mapping Entry is then the tuple: (Pi/L, Si, R, T, A)/
>
> ///Pe = (Pi + ((R-1) << (Lx-L))/
>
> /     Se = Si + (R-1)/
>
> //
>
> /Example:    (192.0.2.120/32, 200, 1, 0, 0)/
>
> As regards your proposal
>
> /- Find all SIDi advertised for the prefix P1 // identification of 
> Prefix conflicts/
>
> /                - For each SIDi find all the prefix Pij associated 
> with SIDi              // identification of SID conflicts/
>
> //
>
> /Get the best as per the preference algorithm./
>
> /If best Pij == P1/
>
> /then use SIDij for P1/
>
> /else return no SID/
>
> this to me specifies an implementation – which isn’t necessary.
>
> [Bruno] Well, _/you/_ are the one talking about implementation, and 
> more specifically implementation complexity.
>
> Assuming the above algo works, it looks relatively simple to 
> implement, in which case, I would not buy the argument about 
> implementation complexity which is the only argument in favor or the 
> “ignore” or “quarantine” policy.
>
> However, there is one important point which has not been specified in 
> the draft which reading your post has brought to my attention – that 
> is the order in which checks are made.
>
> The draft states:
>
> “Prefix conflicts are specific to mapping entries sharing the same 
> topology and algorithm.”
>
> “SID conflicts are independent of address-family, independent of 
> prefix len, independent of topology, and independent  of algorithm.”
>
> If we consider an example where a network supports two VPNs, the 
> significance of ordering in the evaluation of conflicts will be 
> highlighted:
>
> VPN1:
>
> If we evaluate prefix conflicts first, then the following entries are 
> “active”:
>
> If we evaluate SID conflicts first, then the following entries are 
> “active”:
>
> *From:*spring [mailto:[email-masked]] *On Behalf Of 
> [email-masked] <mailto:[email-masked]>
> *Sent:* Thursday, May 12, 2016 8:23 AM
> *To:* [email-masked] <mailto:[email-masked]>
> *Subject:* [spring] draft-ietf-spring-conflict-resolution - Policy
>
> Hi authors, all
>
> I'm wondering if we could address the conflict on a per FEC/Prefix 
> basis rather than on a per IGP advertisement basis.
>
>                 - For each SIDi find all the prefix Pij associated 
> with SIDi              // identification of SID conflicts
>
> // as a result, we get a list of SIDi – Pij for P1
>
>    Note that it would probably be better for the preference algo to 
> put the SID tie-brake before the prefix tie-break as with the prefix 
> tie-break, we suffer from the conflict twice (Prefix - SID mapping, 
> then SID- prefix mapping) which increase the diversity and hence the 
> chance of not finding a valid entry.   But for the below examples, I 
> used the preference algo from draft-ietf-*-00
>
>    12.  That SID conflicts with the Prefix-SID advertised by R12 and 
> the Mapping Server Advertisement for R12.
>
>    Best one is R12 - SID12 - R2 (smaller range (prefix SID),smaller 
> range (prefix SID), smaller starting adresse (R2))
>
>    For SR routers, R1 to 50, we have a conflict between both MS 
> advertisement and Prefix SID advertisements.
>
> 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,
> This message and its attachments may contain confidential or 
> privileged information that may be protected by law;
> 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,
> This message and its attachments may contain confidential or 
> privileged information that may be protected by law;
> 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,
> This message and its attachments may contain confidential or 
> privileged information that may be protected by law;
> 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,
> 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,
> 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,
> This message and its attachments may contain confidential or 
> privileged information that may be protected by law;
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring

---

From: "Henderickx, Wim (Nokia - BE)" <[email-masked]>
Date: Fri, 22 Jul 2016 09:34:32 +0000

As 1 of the vendors implementing this, we prefer the approach of ignore overlap as I said in the meeting in Berlin
The implication from implementation s are not massive and given it is maximising traffic delivery in case of conflict, we prefer this approach.

From: spring <[email-masked]<mailto:[email-masked]>> on behalf of Martin Horneffer <[email-masked]<mailto:[email-masked]>>
Date: Friday 22 July 2016 at 11:01
To: "Les Ginsberg (ginsberg)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Martin Horneffer <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] draft-ietf-spring-conflict-resolution - Policy

Hi Les,

In general I don't consider it a big deal whether the Quarantine or the Ignore Overlap policy is being used. It's mainly important that _one_ of then finally gets chosen and consistently implemented.

From the operator's point of view I tend to agree with other operators that the Ignore Overlap policy looks better for most realistic cases, even though less worried about the amount of traffic lost, but more about robustness and security aspects.

Complexity of implementation, however, can be a serious argument against it, as this also works against robustness and security.

Nobody doubts that the Ignore Overlap policy is more complex. But how much complexity it really adds is hard to estimate for me. Is it a minor complication or a big one?

So far I have seen one vendor talk against the Ignore Overlap policy and two vendors taking a position in favor of it.

Sounds to me like 2:1 for Ignore Overlap so far. But we actually don't believe in voting and need more vendor input anyways!

BR,
Martin

Two comments:

1)As we both can come up with examples where a given  preference algorithm will result in “better” behavior than another, continuing to debate which one is “best” has no end. The answer depends upon what types of errors are introduced in the configuration and that isn’t predictable. If it is necessary for us to agree on which algorithm is “best” I doubt that consensus will ever be reached. It therefore is more important to me to focus on implementation complexity and the importance of identifying and correcting misconfigurations ASAP.

2)There are two logical databases that an implementation has to support. One of them is the set of received advertisements which can include entries with a variety of ranges. The second one is the set of mapping entries which are in use for lookups.
Your discussion of your “per FEC algorithm”  below defines the second database as a set of entries all of which have a range of 1. Whether this is good implementation model or not I am not commenting on here. But this does not eliminate the need to maintain the first database – and to be able to associate entries in the second database with the corresponding received entry from which they may have been derived. There is work in maintaining that relationship which does not directly bear on the lookup for a given SID but still has to be done if one uses “per FEC” or “Ignore Overlap Only”. This work is not required for the “per range” or “Quarantine” algorithm. It is this additional work that I refer to when I say that “per FEC” has a higher implementation cost/complexity.

   Les

From:[email-masked]<mailto:[email-masked]> [mailto:[email-masked]]

Les,

Bruno –

There is a misconfiguration here, but we don’t know what was really intended. A few (of many) possibilities:

Quarantine
----------------

Ignore Conflict Only

Active entries are then:

 Now, which of these maximizes delivery of traffic? The answer to that depends upon the type of configuration error that was made.
If Error #1 was made, there is no way to differentiate the two preference rules.
However, if Error #2 was made, then Quarantine is clearly better because the destinations 1.1.1.2 – 1.1.1.10 were never intended to have assigned SIDs and may not even exist as destinations in the network, yet “Ignore Conflict Only” favors those prefixes.

The point I am trying to make is that it is incorrect to say “If we maximize the number of advertised entries which we use we will always do a better job of delivering traffic.” This example illustrates that this isn’t always true.
[Bruno] OK. Clearly, we can find an example where an algorithm is better than the other. After all, we all agree that there has been a configuration error.
There are 2 points:

I agree that “b” is more or less random and hence there are many cases where we’ll pick the wrong one. Yet, we try to make reasonable choices. That the point of discussing the preference algorithm (3.2.4). (Although it’s very easy to argue that we can make the wrong choice, I don’t feel that’s a reason not to try discussing it and make choice. e.g. “PFX source wins over SRMS source” is one: we give preference to SR nodes rather than LDP nodes.

Regarding a, I feel that maximizing the number of destinations kept, is likely to give the best result in average. I don’t have a proof, but it feel like playing loto: even if each choice is random (“b”), the more you try (“a”) the better your chances.

From:[email-masked]<mailto:[email-masked]> [mailto:[email-masked]]

Les,

Bruno –

I don’t find your representation complete as regards all of the attributes which are proposed to be used by the conflict resolution algorithm – so it is therefore hard for me to use/understand this representation when applying the defined preference rule.
This is true for me even after reading your explanations below.

But it is far more important to have a common understanding of the algorithm proposal than it is to be arguing over whose encoding is “better”. If the encoding in the draft is not clear or could use improvement, I welcome your feedback.

[Bruno] Sure. But if we want to compare implementation complexity, we’ll need to agree on how much we want to go into details, in order to have meaningful comparison. So far this is not clear to me as you sometimes argue that data structure is implementation specific and you don’t want to go into this (which I agree) and sometime you detail the data structure.
There is also the option to consider this as “implementation issue” and let this to implementations.

[Les:] Range intersection is easy to compute – the algorithm is present in the draft at the end of  Section 3.1.1.
[Bruno] In order to have a meaningful discussion, we need to define the level of details that we want to take into account, because you’re not using the same one to discuss your algo and mine.
1) As a first level of comparison, using the description at the end of section 3.1.1 as a model, for range prefix conflict your algo is:
   1)(T1 == T2) && (A1 == A2)
   2)P1 <= P2
   3)The prefixes are in the same address family.
   2)L1 == L2
   3)(P1e >= P2) && ((S1 + (P2 - P1)) != S2)

The FEC algo needs: get_SIDs(Prefix), and all the work is done. So all the algo complexity is coming from the datastructure. It seems pretty reasonable to find a datastructure << o(n) (e.g. a tree, but you will be much better than me in finding one)
For the range algo, it’s not clear to me that a data structure can be found to automatically find the result. If not, the algo seems to compare all entries two by two, which would get o(n*(n-1)…(2)) i.e. o(n!)

In its simplest form, we have a list of all SID advertisements (PFX and SRMS) that we have received. One could imagine walking all the entries, looking to see if the prefix of interest is present within the advertised range. But, of course, at large scale such an approach is extremely inefficient – so we immediately start considering ways to improve performance. Inserting received entries into an ordered tree of some kind is an obvious way to improve performance. When one further considers that calculating conflict resolution only needs to be done when a change to the received database occurs (which post startup is infrequent) it becomes very attractive to cache the “winning entries” so that if one wants to retrieve the SID for a given prefix we only have to examine a subset of the total database – ignoring the losers.
[Bruno] I agree that the per range algo (ignore overlap only) will be able to ignore the losers but at the cost of a more complex algo and at the cost of creating new derived entries. It’s not clear to me if the net result is positive. Plus I would expect that the number of conflit is small compared to the number of prefix /SID so this looks like a second order optimization.

In this context, we can appreciate the difference between the three proposed algorithms. In particular comparing “Quarantine” with “ignore overlap only”, a key difference is that “Quarantine” only needs to determine whether a received entry is a winning entry or a losing entry. “Ignore overlap only” has to be capable of breaking received entries with ranges > 1 into multiple “derived” entries (some winning, some losing), which means we now need to track the “derived entries” against the original received entry so that if the received entry is updated/deleted we can find all the derived entries and delete/regenerate the derived entries as needed. This is what adds complexity.
[Bruno] and that it why the per FEC algo seems easier.
So it would seem useful to add it in the draft so that we can all discuss it.

-- Bruno

   Les

All proposed algorithms can be implemented, but it does seem prudent to consider implementation complexity as part of our decision process – and the discussion/examples in Section 3 are meant to help in doing this.

It is worthwhile restating that when conflicts are present we cannot guarantee that forwarding will work correctly no matter what algorithm is used.
[Bruno] I’m not sure to see what you have in mind exactly. Can you elaborate? To me consistency seem enough.
 The more complex the implementation the more likely it is that bugs will be present and the more likely it is that interoperability issues will arise. Whether these costs/risks are worth the “value add” when the outcome cannot be guaranteed to be correct – only guaranteed to be consistent – is an important consideration.

Also important to remember that conflicts MUST be eliminated by correcting the misconfigurations that caused them – so conflict resolution is really only an interim measure until the corrections can be made.
[Bruno] By “interim” we are at minimum talking about 10s of minutes, if not more than 1 hour since identifying the root cause may not be obvious. The impact is very significant on the network.
The “Quarantine” algo has the potential to kill 100s PE and 1000s of VPN customers, so a single configuration change on a unrelated router which may not even be in production (i.e. where configuration checks and operations hours may be relaxed)

No one should be lulled into thinking that because we have conflict resolution deployed that correcting the configuration when conflicts are detected is not a priority.
[Bruno] I could not agree more that conflict needs to be identified and fixed. Note that I’m the one having asked for defining YANG notifications to report this.
You are welcomed to state in the draft that conflicts needs to be reported to the network operator, in particular though yang notification, and other existing means. Plus that network operator needs to fixed them ASAP (but still carefully)

Thanks
--Bruno

   Les

From:[email-masked]<mailto:[email-masked]> [mailto:[email-masked]]

Les,

Bruno –

As the thread below documents, I stated that I did not understand your representation and asked for clarification – suggesting that you use the format defined in the draft.
You stated that you could not do that and we were at a point where no progress could be made.
[Bruno] I could _not_ use your format since your format did not include the information need. This is not a whim but a technical issue. So I asked you to still consider the message. Rather than waiting for a time-out, there was a way to make progress by asking clarification questions on the points which were not clear, or at least explicitly refusing to consider the email.

I also note that what bothered you in my representation was my addition of the type of advertisement (prefix or MS). But you finally have just added in the latest version of the draft “Src- PFX or SRMS” . So there was probably a way to communicate.

Besides the algo did not use any specification representation, just names. So I’ll copy/paste it below, please ask clarification questions for the parts which are not clear enough.

So “R2 - SID2 - R2 (MS, MS)” is the outpout of the algo described above and means: For prefix R2, we found a MS mapping entries advertising SID2 for this prefix, and then I found a MS mapping entries advertising prefix R2 for SID2.

Does it mean  “On R2, SID2 is assigned to prefix R2 from two different mapping server entries?” I really have no idea.

But since there is no representation of “range” in your examples I really have no idea how you came to this conclusion .
[Bruno] I agree that since the above algo used 2 mapping entries to provides the (SIDi, Pij), the preference algo (§3.2.4) would need to be adapted. That being said, this is not important for this discussion. Let’s just considered that their exist a preference algorithm, which takes as input a list of (SIDi, Piij) for P1, and gives as outpout the “best” one. (definition of “best” is not pertinent)

??

As regards “per FEC/Prefix”, I believe this is what “ignore overlap only” does.
[Bruno] Indeed, this is my expectation. But I would need someone’s review to confirm this.
But the difference is that the proposed algo is simple (2 lines of pseudo code), with very modest resquirement data structure use to store the mapping entries. Indeed, all it needs is a function returning the list of mapping entries associated/matching a given prefix. And function returning the list of mapping entries associated/matching a given SID.
In particular, there is no need for splitting mapping entries which is the main complexity of your proposed “Preference algorithm/ignore overlap only”. (according to your own text).

-- Bruno

    Les

From:[email-masked]<mailto:[email-masked]> [mailto:[email-masked]]

Les,

Thanks
Bruno

Les,

Bruno –

So it does not matter if R2 sends an advertisement or R12 sends advertisement or both of them do (which could happen when an advertisement is leaked) – what matters is what unique entries are in the database independent of source.
[Bruno] It may not matter for your algorithm (pending another thread), but it does for the one I proposed.

    Pi - Initial prefix
     Pe - End prefix
     L -  Prefix length

As regards your proposal

this to me specifies an implementation – which isn’t necessary.
[Bruno] Well, _you_ are the one talking about implementation, and more specifically implementation complexity.
Assuming the above algo works, it looks relatively simple to implement, in which case, I would not buy the argument about implementation complexity which is the only argument in favor or the “ignore” or “quarantine” policy.
Bottom line, I would welcome your feedback and comments on this proposed algo/policy.

Thanks,
Regards,
-- Bruno

However, there is one important point which has not been specified in the draft which reading your post has brought to my attention – that is the order in which checks are made.
The draft states:

“Prefix conflicts are specific to mapping entries sharing  the same topology and algorithm.”
“SID conflicts are independent of address-family,  independent of prefix len, independent of topology, and independent  of algorithm.”

VPN1:

VPN2:

If we evaluate prefix conflicts first, then the following entries are “active”:
(192.0.2.1/32, 100, 1, 1, 0) !VPN1
(192.0.2.100/32, 200, 1, 2, 0) !VPN2

If we evaluate SID conflicts first, then the following entries are “active”:
(192.0.2.1/32, 100, 1, 1, 0) !VPN1

    Les

Hi authors, all

Regards,
Bruno

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

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

---

From: "Aissaoui, Mustapha (Nokia - CA)" <[email-masked]>
Date: Mon, 25 Jul 2016 19:19:01 +0000

Hi Wim and all,
one operational aspect in favor of ignoring only the less preferred entry which actually conflicts is that for a given prefix, a SID value received in a prefix TLV is always preferred over a SID value received in a mapping server prefix range TLV. With the quarantine method, you will more often put the entire mapping server range TLV in quarantine which will be too disruptive.

Mustapha.

From: spring [mailto:[email-masked]] On Behalf Of Henderickx, Wim (Nokia - BE)
Sent: Friday, July 22, 2016 5:35 AM
To: Martin Horneffer; Les Ginsberg (ginsberg); [email-masked]<mailto:[email-masked]>
Cc: Horneffer, Martin
Subject: Re: [spring] draft-ietf-spring-conflict-resolution - Policy

Hi Les,

BR,
Martin

Two comments:

   Les

Les,

Bruno –

Quarantine
----------------

Ignore Conflict Only

Active entries are then:

Les,

Bruno –

-- Bruno

   Les

Thanks
--Bruno

   Les

Les,

Bruno –

??

-- Bruno

    Les

Les,

Thanks
Bruno

Les,

Bruno –

    Pi - Initial prefix
     Pe - End prefix
     L -  Prefix length

As regards your proposal

Thanks,
Regards,
-- Bruno

VPN1:

VPN2:

    Les

Hi authors, all

Regards,
Bruno

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

spring mailing list

---

From: <[email-masked]>
Date: Thu, 28 Jul 2016 12:36:00 +0000

Hi Les, all

As an individual contributor.

As a network operator, I have a significant preference for the per FEC/Ignore overlap only policy as it constrains the conflict (resolution) to only the prefix/SID in conflict; compared to the per advertisement/quarantine policy which increase it to a full advertisement. As a consequence, the quarantine policy starts the conflict resolution procedure by increasing (the scope of) the problem, which is not the right direction.
More specifically, with per FEC, the conflict is constrained to the intersection of both mapping entries, while with quarantine the conflict is increased to one full mapping entry. (quantitative difference will be example specific, and typically dependent on the size of the mapping server advertisement)

Additionally, but much less importantly to me, the quarantine policy has probably a high risk of constraining the Preference rule to the revised preference rule (i.e. selecting the winning entry based on its larger range). More on this in the next email. (as Martin (*) has initiated 2 threads on those 2 subjects).

Thanks,
Regards
--Bruno

(*) Looks like we'll also have to handle conflict on names. Here I meant Martin Horneffer.

From: spring [mailto:[email-masked]] On Behalf Of Martin Horneffer
Sent: Friday, July 22, 2016 11:02 AM
To: Les Ginsberg (ginsberg); [email-masked]
Cc: Horneffer, Martin
Subject: Re: [spring] draft-ietf-spring-conflict-resolution - Policy

Hi Les,

BR,
Martin

Two comments:

   Les

Les,

Bruno -

Quarantine
----------------

Ignore Conflict Only

Active entries are then:

Les,

Bruno -

-- Bruno

   Les

Thanks
--Bruno

   Les

Les,

Bruno -

??

-- Bruno

    Les

Les,

Thanks
Bruno

Les,

Bruno -

    Pi - Initial prefix
     Pe - End prefix
     L -  Prefix length

As regards your proposal

Thanks,
Regards,
-- Bruno

VPN1:

VPN2:

    Les

Hi authors, all

Regards,
Bruno

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

spring mailing list

[email-masked]<mailto:[email-masked]>