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

From: <[email-masked]>
Date: Thu, 12 May 2016 15:22:38 +0000

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.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sat, 14 May 2016 22:40:32 +0000

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.

It would be good if you could present your examples using the format defined in the draft i.e.:

    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

                else return no SID

this to me specifies an implementation - which isn't necessary.

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]
Sent: Thursday, May 12, 2016 8:23 AM
To: [email-masked]
Subject: [spring] draft-ietf-spring-conflict-resolution - Policy

Hi authors, all

Regards,
Bruno

Thank you.

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 15 May 2016 05:08:07 +0200

Hi Les

Please notice that in general we have no notion of term "VPN" in protocol
nor implementation. (Let's put aside vpn_id for radius authentication).
What determines a VPN is intersection of import and export RTs for specific
L2/3VPN case.

So if you want to start relaxing the rules they must map to some protocol
values or at least be scoped to given RIB ... which for L2/3VPNs again may
be tricky ... example hub and spoke topologies where even same VPN does not
share one RIB ;).

Then there is pool of other VPNs like IPSec based or LISP or xyz ...

Perhaps easiest for you at this point would be to actually narrow your
draft to domain's underlay transport layer and move on.

My original comment was more asking to just avoid in the text referencing
to "node" or a router as one entity from perspective of SR conflicts.

Best,
Robert.
On May 14, 2016 15:40, "Les Ginsberg (ginsberg)" <[email-masked]> wrote:

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.

It would be good if you could present your examples using the format
defined in the draft i.e.:

*    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 <http://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.

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:

VPN2:

If we evaluate prefix conflicts first, then the following entries are
“active”:

If we evaluate SID conflicts first, then the following entries are “active”:

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

    Les

*From:* spring [mailto:[email-masked]] *On Behalf Of *
[email-masked]
*Sent:* Thursday, May 12, 2016 8:23 AM
*To:* [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.

If so, this may avoid the discussion between the Quarantine vs ignore
policy.

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

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

       Prefix-SID sub-TLV;

   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.

   For R2, the algo evaluates a conflict between the following
advertisments:

   R2 - SID2 - R2 (MS, MS)

   Best one is R2 - SID12 - R2 (smaller range (prefix SID),smaller range
(prefix SID))

   For R12, the algo evaluates a conflict between the following
advertisments:

   Best one is R12 - SID12 - R2 (smaller range (prefix SID),smaller range
(prefix SID), smaller starting adresse (R2))

   Note: both MS advertisement are the same, so we only consider one in the
below analysis.

   For R2, the algo evaluates a conflict between the following
advertisments:

   R2 - SID2  - R2  (MS, MS)

   Best one is R2 - SID52 - R2 (smaller range (prefix SID),smaller range
(prefix SID))

   For R52, the algo evaluates a conflict between the following
advertisments:

   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:

   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:

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;

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.

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

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 16 May 2016 00:40:32 +0000

Bruno -

After rereading your post, I think I missed part of what you were trying to say.

Topology was introduced because it is expected (indeed even REQUIRED) that the same prefix would have a different SID in different topologies. This is why for the purposes of determining "prefix conflict" (different SIDs for the same prefix) only entries for the same topology (and algorithm) are compared.  However, for the purposes of determining "SID conflicts" (different entries in the database using the same SID) we MUST compare entries in all topologies since the label database on a router is a shared resource. This leads to the following case:

VPN1:

VPN2:
(192.0.2.1/32, 100, 1, 2, 0)

Under the current preference rule defined in the draft these two entries are considered "identical" - but in fact they are not since they are different topologies (i.e. different FECs). However, since (as I think Robert was pointing out in his recent email) topology ids/VPN IDs are not global in scope they cannot be used as a tie breaker (nor does the draft suggest that should be). This leads to the following amendment to the preference rule (including some of your suggested changes):

1.  Smaller range wins
2.  IPv6 entry wins over IPv4 entry
3.  Longer prefix length wins
4. Smaller algorithm wins
5.  Smaller starting address (considered as an unsigned integer
       value) wins
6.  Smaller starting SID wins
7. If topology IDs are NOT identical both entries MUST be ignored

The additional rule (#7) is applied only when doing SID conflicts as prefix conflicts are limited to the entries  in a single topology. And since we cannot use the topology ID as a tie-breaker because the identifier has only local scope both entries MUST be ignored.

As to your statement below that:

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

I disagree. Prefix conflicts MUST be determined first - otherwise we risk ignoring an entry in another topology because it has a SID conflict with an entry in another topology which will be ignored based on prefix conflict - as the example I presented below demonstrates.

Are we closer to agreement now?

   Les

From: spring [mailto:[email-masked]] On Behalf Of Les Ginsberg (ginsberg)
Sent: Saturday, May 14, 2016 3:41 PM
To: [email-masked]; [email-masked]
Subject: Re: [spring] draft-ietf-spring-conflict-resolution - Policy

Bruno -

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

As regards your proposal

VPN1:

VPN2:

    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

Regards,
Bruno

Thank you.

---

From: <[email-masked]>
Date: Wed, 18 May 2016 11:57:23 +0000

Regarding VPN, I will defer my comments for a next version of the draft which handles VPN/multiple FIB. In particular,
- I'm not sure about using the same term "topology" for both VPN and IGP topology.
- I disagree that "label database on a router is a shared resource". It is a per forwarding table resource. You can use the same label multiple times for different meaning, if they are in a different forwarding table e.g. Carrier's Carrier VRF, context forwarding label.

--Bruno

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

Bruno -

VPN1:

VPN2:

1.  Smaller range wins

   Les

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

Bruno -

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

As regards your proposal

VPN1:

VPN2:

    Les

Hi authors, all

Regards,
Bruno

Thank you.

---

From: <[email-masked]>
Date: Wed, 18 May 2016 11:57:20 +0000

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

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

VPN1:

VPN2:

    Les

Hi authors, all

Regards,
Bruno

Thank you.