Subject: Re: [spring] [Mapping Server] Conflict Resolution

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 17 Mar 2017 07:11:11 +0000

It is not possible to answer your query because the way you have presented your entries (X, E1, E2, E3) does not tell us what conflicts you have.
Do you have two SIDs assigned to the same prefix? (Prefix conflict)
Do you have the same SID assigned to two different prefixes? (SID conflict)

This matters – see Section 3.3.6 of the draft for an example as to why.

Please present your example in the form defined in Section 3:

       Prf - Preference Value (See Section 3.1)
       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 (See Note 1)
       T  - Topology
       A  - Algorithm

       A Mapping Entry is then the tuple: (Prf, Src, Pi/L, Si, R, T, A)

Thanx.

   Les

From: tech_kals Kals [mailto:[email-masked]]
Sent: Thursday, March 16, 2017 7:22 PM
To: [email-masked]; Les Ginsberg (ginsberg); Peter Psenak (ppsenak); Stefano Previdi (sprevidi); [email-masked]
Subject: [Mapping Server] Conflict Resolution

Hi Experts,

  Could you please explain me what would be the expected behavior in the following scenario in Quarantine approach.

  Mapping entries E1, E2, E3 are Active entries.

  In case, if incoming new entry say X which has conflict with E1, E2 and E3.

  Assume, X is better than E1 but not better than E2.  ( E1 < X < E2)

  1] X is better than E1 so E1 will become excluded entry and X will become an active entry

  2] Now, X is compared with E2. E2 is better than X. So, X will become excluded entry and E2 is an active entry as it was.

So, X and E1 will become "excluded entry".

I couldn't find any info as shown above in the RFC. Can you please clarify ?

My doubts:
1) Will the entry become active only if it wins with all entries which are conflicted with this ?
2) When doing conflict resolution with other entries, it can win with some entries and can lose to some? What could be the behavior ?
     - This is the case which I explained above.
     - In this case, X can become active by winning to E1 and lose E2 which leads X and E1 to become inactive/excluded entry.

can you please clarify ?

Regards,
__tech.kals__

---

From: tech_kals Kals <[email-masked]>
Date: Fri, 17 Mar 2017 07:51:54 +0530

Hi Experts,

  Could you please explain me what would be the expected behavior in the
following scenario in *Quarantine approach*.

  Mapping entries *E1, E2, E3 *are Active entries.

  In case, if incoming new entry say *X *which has conflict with *E1, E2
and E3.*

  Assume, *X is better than E1 but not better than E2.  ( E1 < X < E2)*

*  1] X is better than E1 so E1 will become excluded entry and X will
become an active entry*

*  2] Now, X is compared with E2. E2 is better than X. So, X will become
excluded entry and E2 is an active entry as it was.*

*So, X and E1 will become "excluded entry".*

*I couldn't find any info as shown above in the RFC. Can you please clarify
?*

*My doubts:*
*1) Will the entry become active only if it wins with all entries which are
conflicted with this ?*
*2) When doing conflict resolution with other entries, it can win with some
entries and can lose to some? What could be the behavior ? *
*     - This is the case which I explained above.*
*     - In this case, X can become active by winning to E1 and lose E2
which leads X and E1 to become inactive/excluded entry.*

can you please clarify ?

Regards,
__tech.kals__

---

From: tech_kals Kals <[email-masked]>
Date: Fri, 17 Mar 2017 12:31:28 +0530

Hi Experts,

  Can someone reply please.

Rgds,
Kaliyaperumal K

On Fri, Mar 17, 2017 at 7:51 AM, tech_kals Kals <[email-masked]> wrote:

> *I couldn't find any info as shown above in the RFC. Can you please
> clarify ?*
>
>
> *My doubts:*
> *1) Will the entry become active only if it wins with all entries which
> are conflicted with this ?*
> *2) When doing conflict resolution with other entries, it can win with
> some entries and can lose to some? What could be the behavior ? *

---

From: tech_kals Kals <[email-masked]>
Date: Fri, 17 Mar 2017 13:39:26 +0530

Hi Les,

 Sorry, I have not included my mapping entries in the previous mail. Please
see the example here below.

 I am working with the RFC which doesn't support *Preference Value, *so
please ignore it. And, my mapping entries would looks like.
Topology will be a single topology, not a Multi-topology and algorithm
would be SPF not CSPF.

 Please read my entry the below order:  *<Prefix-start/ prefix-len,
 starting SID,  range>*
* E1 and E2 already configured Active entries. X is the newly incoming
entry.*

*Scenario 1:   (Entries are conflicting with prefix)*
                         Entry *E1:      <10.1.10.0/24
<http://10.1.10.0/24>, 300, 22>*
                         Entry *E2:      <10.1.1.0/24 <http://10.1.1.0/24>,
  150, 5>*

*                         incoming entry is X:*
*                         Entry X:        <10.1.2.0/24
<http://10.1.2.0/24>,  200, 20>*

*           Step1: Conflict would be validated between E1 and X.*

*           Step2: Conflict would be validated between E2 and X.*

   *       # what are the entries would be active and what will become
inactive/**excluded entry ?*

*Scenario 2:   **(Entries are conflicting with SID)*
                         Entry *E1:      <10.1.10.0/24
<http://10.1.10.0/24>, 300, 22>*
                         Entry *E2:      <7.1.1.0/24 <http://7.1.1.0/24>,
  280, 10>*

*                         incoming entry is X:*
*                         Entry X:        <3.1.1.0/24 <http://3.1.1.0/24>,
  285, 20>*

*           Step1: Conflict would be validated between E1 and X.*

*           Step2: Conflict would be validated between E2 and X.*

        *  # what are the entries would be active and what will become
inactive/**excluded entry ?*

*Scenario 3:    **(Entries are conflicting with prefix and SID)*

                         Entry *E1:      <10.1.10.0/24
<http://10.1.10.0/24>, 300, 22>*
                         Entry *E2:      <5.1.1.0/24 <http://5.1.1.0/24>,
  190, 15>*

*                         incoming entry is X:*
*                         Entry X:        <10.1.1.0/24
<http://10.1.1.0/24>,  200, 20>*

*           Step1: Conflict would be validated between E1 and X.*

*           Step2: Conflict would be validated between E2 and X.*

          *# what are the entries would be active and what will become
inactive/**excluded entry ?*

*Regards,*
*__tech.kals__*

On Fri, Mar 17, 2017 at 12:41 PM, Les Ginsberg (ginsberg) <
[email-masked]> wrote:

> It is not possible to answer your query because the way you have presented
> your entries (X, E1, E2, E3) does not tell us what conflicts you have.
>
> *From:* tech_kals Kals [mailto:[email-masked]]
> *Sent:* Thursday, March 16, 2017 7:22 PM
> *To:* [email-masked]; Les Ginsberg (ginsberg); Peter Psenak (ppsenak);
> Stefano Previdi (sprevidi); [email-masked]
> *Subject:* [Mapping Server] Conflict Resolution
>
>
>
> Hi Experts,
>
>
>

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 17 Mar 2017 09:23:26 +0100

Hi,

Scenario 1 - I do not see any prefix conflict. Those are independent /24
prefixes.

Scenario 2 - X IP prefix will be installed in RIB but SR labels (entire
range) will be blocked for X.

Scenario 3 - I do not see any prefix conflict. SR labels (entire range)
will be blocked for X.

Cheers,
R.

On Fri, Mar 17, 2017 at 9:09 AM, tech_kals Kals <[email-masked]> wrote:

> Hi Les,
>
>  Sorry, I have not included my mapping entries in the previous mail.
> Please see the example here below.
>
>                          Entry *E2:      <10.1.1.0/24
> <http://10.1.1.0/24>,   150, 5>*
>
> *                         incoming entry is X:*
> *                         Entry X:        <10.1.2.0/24
>> It is not possible to answer your query because the way you have
>> presented your entries (X, E1, E2, E3) does not tell us what conflicts you
>> have.
>>
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>
>

---

From: tech_kals Kals <[email-masked]>
Date: Fri, 17 Mar 2017 15:57:08 +0530

Hi Robert,

  As I have mentioned on the previous mail, there is a conflict on each
scenario.

*Scenario 1:   (Entries are conflicting with prefix)*
                         Entry *E1:      <10.1.10.0/24
<http://10.1.10.0/24>, 300, 22>  *can be expanded up to *<10.1.31.0/24
<http://10.1.31.0/24>, 321>*
                         Entry *E2:      <10.1.1.0/24 <http://10.1.1.0/24>,
  150, 5>  *can be expanded up to *<10.1.5.0/24 <http://10.1.5.0/24>, 154>*

*                         incoming entry is X:*
*                         Entry X:        <10.1.2.0/24
<http://10.1.2.0/24>,  200, 20> *can be expanded up to *<10.1.21.0/24
<http://10.1.21.0/24>, 221>*

                     entry-X prefix range *10.1.10.0 to 10.1.21.0 *would
conflict with entry *E1 *and *10.1.2.0 to 10.1.5.0* would conflict with *E2*
.

                     *So, there is a prefix conflict.*

*Scenario 2:   **(Entries are conflicting with SID)*
                         Entry *E1:      <10.1.10.0/24
<http://10.1.10.0/24>, 300, 22>  *can be expanded up to *<10.1.31.0/24
<http://10.1.31.0/24>, 321>*
                         Entry *E2:      <7.1.1.0/24 <http://7.1.1.0/24>,
  280, 10>  *can be expanded up to *<7.1.10.0/24 <http://7.1.10.0/24>, 289>*

*                         incoming entry is X:*
*                         Entry X:        <3.1.1.0/24 <http://3.1.1.0/24>,
  285, 20>  *can be expanded up to *<3.1.19.0/24 <http://3.1.19.0/24>, 304>*

                     entry-X SID *300 *to *304 *would conflict with entry
*E1 *and *SID 285 to 289* would conflict with *E2*.

                     *So, there is a SID conflict.*

                         Entry *E1:      <10.1.10.0/24
<http://10.1.10.0/24>, 300, 22>  *can be expanded up to *<10.1.31.0/24
<http://10.1.31.0/24>, 321>*
                         Entry *E2:      <5.1.1.0/24 <http://5.1.1.0/24>,
  190, 15>  *can be expanded up to *<5.1.15.0/24 <http://5.1.15.0/24>, 204>*

*                         incoming entry is X:*
*                         Entry X:        <10.1.1.0/24
<http://10.1.1.0/24>,  200, 20> *can be expanded up to *<10.1.20.0/24
<http://10.1.20.0/24>, 219>*

                    entry-X prefix range *10.1.10.0 to 10.1.20.0 *would
conflict with entry *E1 and **SID 200 to 219* would conflict with *E2*.

                    *So, there is a Prefix and SID conflict.*

Regards,
_tech.kals_

On Fri, Mar 17, 2017 at 1:53 PM, Robert Raszuk <[email-masked]> wrote:

>>                          Entry *E2:      <7.1.1.0/24
>> <http://7.1.1.0/24>,     280, 10>*
>>
>> *                         incoming entry is X:*
>> *                         Entry X:        <3.1.1.0/24
>> <http://3.1.1.0/24>,   285, 20>*
>>
>>                          Entry *E2:      <5.1.1.0/24
>> <http://5.1.1.0/24>,     190, 15>*
>>
>> *                         incoming entry is X:*
>> *                         Entry X:        <10.1.1.0/24
>>>   In case, if incoming new entry say *X *which has conflict with *E1,
>>> E2 and E3.*
>>>
>>>
>>>

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 17 Mar 2017 11:31:43 +0100

Kals,

> *Entry X:        <10.1.2.0/24 <http://10.1.2.0/24>,  200, 20> *can be
expanded up to *<10.1.21.0/24 <http://10.1.21.0/24>, 221>*

I think you are confusing SID with prefix. Those have nothing in common
other then SID being "attached" to a prefix.

In IP routing prefix with mask is usually NOT EXPANDABLE.

When you advertise 10.1.2.0/24 it will better remain 10.1.2.0/24.

Cheers,
R.

On Fri, Mar 17, 2017 at 11:27 AM, tech_kals Kals <[email-masked]>
wrote:

> <http://10.1.1.0/24>,   150, 5>  *can be expanded up to *<10.1.5.0/24
> <http://10.1.5.0/24>, 154>*
>
> *                         incoming entry is X:*
> *                         Entry X:        <10.1.2.0/24
> conflict with entry *E1 *and *10.1.2.0 to 10.1.5.0* would conflict with
> *E2*.
>
>>>> *To:* [email-masked]; Les Ginsberg (ginsberg); Peter Psenak
>>>> (ppsenak); Stefano Previdi (sprevidi); [email-masked]
>>>>   Could you please explain me what would be the expected behavior in
>>>> the following scenario in *Quarantine approach*.
>>>>
>>>>
>>>>
>>>> *  2] Now, X is compared with E2. E2 is better than X. So, X will
>>>> become excluded entry and E2 is an active entry as it was.*
>>>>
>>>>
>>>>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sat, 18 Mar 2017 05:49:54 +0000

Kals –

Please look closely at how to determine if there is a conflict.
From Section 3:

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

And Section 3.2.1

  Given two mapping entries:

   (Prf, P1/L1, S1, R1, T1, A1) and
   (Prf, P2/L2, S2, R2, T2, A2)

   where P1 <= P2

   a prefix conflict exists if all of the following are true:

   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 preference rule as defined in the latest version of the draft (02):

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

Comments inline

From: tech_kals Kals [mailto:[email-masked]]
Sent: Friday, March 17, 2017 1:09 AM
To: Les Ginsberg (ginsberg)
Cc: [email-masked]; Peter Psenak (ppsenak); Stefano Previdi (sprevidi); [email-masked]
Subject: Re: [Mapping Server] Conflict Resolution

Hi Les,

 Sorry, I have not included my mapping entries in the previous mail. Please see the example here below.

 I am working with the RFC which doesn't support Preference Value, so please ignore it. And, my mapping entries would looks like.
Topology will be a single topology, not a Multi-topology and algorithm would be SPF not CSPF.

 Please read my entry the below order:  <Prefix-start/ prefix-len,  starting SID,  range>
 E1 and E2 already configured Active entries. X is the newly incoming entry.

Scenario 1:   (Entries are conflicting with prefix)
                         Entry E1:      <10.1.10.0/24<http://10.1.10.0/24>, 300, 22>
                         Entry E2:      <10.1.1.0/24<http://10.1.1.0/24>,   150, 5>

[Les:] E1 expands to (10.1.10.0/24 through 10.1.31.0/24) using SIDs 300-321
E2 expands to (10.1.1.0/24 through 10.1.5.0/24) using SIDs 150 -154

There is no conflict – both entries are used.

                         incoming entry is X:
                         Entry X:        <10.1.2.0/24<http://10.1.2.0/24>,  200, 20>

[Les:] X expands to (10.1.2.0/24 – 10.1.21.0/24) using SIDs 200-219.
There is a prefix conflict with E1.
Preference rule #2 (smaller range) is applied – but the answer one gets depends on the order in which the entries are processed – a point which I discussed in my presentation at IETF 96. See Slides 17-20 in
https://www.ietf.org/proceedings/97/slides/slides-97-spring-1_ietf97_draft-ietf-spring-conflict-resolution-02-00.pptx

So, if we examine entries in range order (smallest to highest) we find:
E2 has no conflict w X nor with E1.
X has a conflict with E1 – E1 is ignored.
E2 and X are used.

           Step1: Conflict would be validated between E1 and X.

           Step2: Conflict would be validated between E2 and X.

          # what are the entries would be active and what will become inactive/excluded entry ?

Scenario 2:   (Entries are conflicting with SID)
                         Entry E1:      <10.1.10.0/24<http://10.1.10.0/24>, 300, 22>
                         Entry E2:      <7.1.1.0/24<http://7.1.1.0/24>,     280, 10>

[Les:] Again, there is no conflict, both entries are used.

                         incoming entry is X:
                         Entry X:        <3.1.1.0/24<http://3.1.1.0/24>,   285, 20>

[Les:] There is no prefix conflict but there is a SID conflict.
E1 300 – 321
E2 280 – 289
X 285 – 304

Again applying Preference Rule #2 (smallest range wins)
E2 wins over X – X is ignored
E2 has no conflict with E1 – both entries are used.
So E1 and E2 are used and X is ignored.

           Step1: Conflict would be validated between E1 and X.

           Step2: Conflict would be validated between E2 and X.

          # what are the entries would be active and what will become inactive/excluded entry ?

Scenario 3:    (Entries are conflicting with prefix and SID)

                         Entry E1:      <10.1.10.0/24<http://10.1.10.0/24>, 300, 22>
                         Entry E2:      <5.1.1.0/24<http://5.1.1.0/24>,     190, 15>

[Les:] Again, no conflict – both entries are used.

                         incoming entry is X:
                         Entry X:        <10.1.1.0/24<http://10.1.1.0/24>,  200, 20>

[Les:] X has a prefix conflict with E1 – because it has smaller range X is the winner and E1 is ignored.
X has a SID conflict with E2. E2 has smaller range so X is ignored.
Only E2 is used.
Note that we evaluate  prefix conflicts before sid conflicts. Different results might ensue if we did sid conflicts before prefix conflicts (though not in this example)

The subtleties of ordering in achieving interoperability have not yet been incorporated into the draft – in part because there is still discussion about what policy should be used (Ignore, Quarantine, Ignore Overlap Only). If the WG were to select Ignore as the policy then ordering would not matter.

HTH

   Les

           Step1: Conflict would be validated between E1 and X.

           Step2: Conflict would be validated between E2 and X.

          # what are the entries would be active and what will become inactive/excluded entry ?

Regards,
__tech.kals__

On Fri, Mar 17, 2017 at 12:41 PM, Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>> wrote:
It is not possible to answer your query because the way you have presented your entries (X, E1, E2, E3) does not tell us what conflicts you have.
Do you have two SIDs assigned to the same prefix? (Prefix conflict)
Do you have the same SID assigned to two different prefixes? (SID conflict)

Thanx.

   Les

From: tech_kals Kals [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, March 16, 2017 7:22 PM
To: [email-masked]<mailto:[email-masked]>; Les Ginsberg (ginsberg); Peter Psenak (ppsenak); Stefano Previdi (sprevidi); [email-masked]<mailto:[email-masked]>
Subject: [Mapping Server] Conflict Resolution

Hi Experts,

My doubts:

can you please clarify ?

Regards,
__tech.kals__

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 18 Mar 2017 09:54:49 +0100

Hi Kals,

Sorry for missing the concept of "range" in mapping server TLV. Apologies -
my omission !

Hi Les,

Two related questions while we are at this:

1. How can a mapping server advertise SID label on behalf of node which is
not capable of its own advertisement without validation that such SID label
is actually installed in the data plane of that "incapable" node ? If he
does validate it .. how ?

2. When you are making conflict resolution is there a check if the given
prefix has actually been advertised as valid IP reachability and is
installed in local RIB/FIB ?

Kind regards,
R.

On Sat, Mar 18, 2017 at 6:49 AM, Les Ginsberg (ginsberg) <[email-masked]

> *Sent:* Friday, March 17, 2017 1:09 AM
> *To:* Les Ginsberg (ginsberg)
> *Cc:* [email-masked]; Peter Psenak (ppsenak); Stefano Previdi
> (sprevidi); [email-masked]
> *Subject:* Re: [Mapping Server] Conflict Resolution
>
>
>
> Hi Les,
>
>
>
>  *E1 and E2 already configured Active entries.** X is the newly incoming
> entry.*
>
>
>
>
>
> *Scenario 1:**   (Entries are conflicting with prefix)*
>
>                          Entry *E1:      <10.1.10.0/24
> *[Les:] E1 expands to (10.1.10.0/24 <http://10.1.10.0/24> through
> 10.1.31.0/24 <http://10.1.31.0/24>) using SIDs 300-321*
>
> *E2 expands to (10.1.1.0/24 <http://10.1.1.0/24> through 10.1.5.0/24
> <http://10.1.5.0/24>) using SIDs 150 -154*
>
>
>
> *There is no conflict – both entries are used.*
>
>
>
> *                         incoming entry is X:*
>
> *                         Entry X:        <10.1.2.0/24
> *[Les:] X expands to (10.1.2.0/24 <http://10.1.2.0/24> – 10.1.21.0/24
> <http://10.1.21.0/24>) using SIDs 200-219.*
>
> *There is a prefix conflict with E1.*
>
> *Preference rule #2 (smaller range) is applied – but the answer one gets
> depends on the order in which the entries are processed – a point which I
> discussed in my presentation at IETF 96. See Slides 17-20 in*
>
> *https://www.ietf.org/proceedings/97/slides/slides-97-spring-1_ietf97_draft-ietf-spring-conflict-resolution-02-00.pptx
> <https://www.ietf.org/proceedings/97/slides/slides-97-spring-1_ietf97_draft-ietf-spring-conflict-resolution-02-00.pptx>*
>
>
>
> *So, if we examine entries in range order (smallest to highest) we find:*
>
> *E2 has no conflict w X nor with E1.*
>
> *X has a conflict with E1 – E1 is ignored.*
>
> *E2 and X are used.*
>
>
>
> *Scenario 2: **  (Entries are conflicting with SID)*
>
>                          Entry *E1:      <10.1.10.0/24
> *[Les:] Again, there is no conflict, both entries are used.*
>
>
>
> *                         incoming entry is X:*
>
> *[Les:] There is no prefix conflict but there is a SID conflict.*
>
> *E1 300 – 321*
>
> *E2 280 – 289*
>
> *X 285 – 304*
>
>
>
> *Again applying Preference Rule #2 (smallest range wins)*
>
> *E2 wins over X – X is ignored*
>
> *E2 has no conflict with E1 – both entries are used.*
>
> *So E1 and E2 are used and X is ignored.*
>
>
>
> *Scenario 3: **   (Entries are conflicting with prefix and SID)*
>
>
>
>                          Entry *E1:      <10.1.10.0/24
> *[Les:] Again, no conflict – both entries are used.*
>
>
>
> *                         incoming entry is X:*
>
> *                         Entry X:        <10.1.1.0/24
> *[Les:] X has a prefix conflict with E1 – because it has smaller range X
> is the winner and E1 is ignored.*
>
> *X has a SID conflict with E2. E2 has smaller range so X is ignored.*
>
> *Only E2 is used.*
>
> *Note that we evaluate  prefix conflicts before sid conflicts. Different
> results might ensue if we did sid conflicts before prefix conflicts (though
> not in this example)*
>
>
>
> *The subtleties of ordering in achieving interoperability have not yet
> been incorporated into the draft – in part because there is still
> discussion about what policy should be used (Ignore, Quarantine, Ignore
> Overlap Only). If the WG were to select Ignore as the policy then ordering
> would not matter.*
>
>
>
> *HTH*
>
>
>
> *   Les*
>
>
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sat, 18 Mar 2017 14:59:10 +0000

Robert -

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Saturday, March 18, 2017 1:55 AM
To: Les Ginsberg (ginsberg)
Cc: tech_kals Kals; [email-masked]; [email-masked]; Stefano Previdi (sprevidi); Peter Psenak (ppsenak)
Subject: Re: [spring] [Mapping Server] Conflict Resolution

Hi Kals,

Sorry for missing the concept of "range" in mapping server TLV. Apologies - my omission !

Hi Les,

1. How can a mapping server advertise SID label on behalf of node which is not capable of its own advertisement without validation that such SID label is actually installed in the data plane of that "incapable" node ? If he does validate it .. how ?

[Les:] It is not the responsibility of the SRMS to validate that what has been configured is installed in any node’s forwarding plane – and it would be a “catch-22” situation if that were required since until a SID is advertised no label can be installed by any node.
If your argument is that there should be a SID advertised by the node which owns a prefix before SRMS advertises a SID, then it becomes impossible to support partial deployment where some prefixes are owned by SR incapable nodes.

2. When you are making conflict resolution is there a check if the given prefix has actually been advertised as valid IP reachability and is installed in local RIB/FIB ?

[Les:] No. Having such a policy would introduce additional convergence issues. To know whether a given label was being used by a downstream node you would have to run conflict resolution from the POV of the downstream node because the output of that node’s conflict resolution calculation could be different than the local node’s output.

   Les

Kind regards,
R.

On Sat, Mar 18, 2017 at 6:49 AM, Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>> wrote:
Kals –

And Section 3.2.1

   where P1 <= P2

Comments inline

Cc: [email-masked]<mailto:[email-masked]>; Peter Psenak (ppsenak); Stefano Previdi (sprevidi); [email-masked]<mailto:[email-masked]>

Hi Les,

[Les:] E1 expands to (10.1.10.0/24<http://10.1.10.0/24> through 10.1.31.0/24<http://10.1.31.0/24>) using SIDs 300-321
E2 expands to (10.1.1.0/24<http://10.1.1.0/24> through 10.1.5.0/24<http://10.1.5.0/24>) using SIDs 150 -154

                         incoming entry is X:

[Les:] X expands to (10.1.2.0/24<http://10.1.2.0/24> – 10.1.21.0/24<http://10.1.21.0/24>) using SIDs 200-219.
There is a prefix conflict with E1.
Preference rule #2 (smaller range) is applied – but the answer one gets depends on the order in which the entries are processed – a point which I discussed in my presentation at IETF 96. See Slides 17-20 in
https://www.ietf.org/proceedings/97/slides/slides-97-spring-1_ietf97_draft-ietf-spring-conflict-resolution-02-00.pptx

                         incoming entry is X:

                         incoming entry is X:

HTH

   Les

Regards,
__tech.kals__

Thanx.

   Les

Hi Experts,

My doubts:

can you please clarify ?

Regards,
__tech.kals__

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

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sat, 18 Mar 2017 15:58:35 +0000

From: spring <[email-masked]<mailto:[email-masked]>> on behalf of "Les Ginsberg (ginsberg)" <[email-masked]<mailto:[email-masked]>>
Date: Saturday, March 18, 2017 at 10:59 AM
To: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Peter Psenak (ppsenak)" <[email-masked]<mailto:[email-masked]>>, tech_kals Kals <[email-masked]<mailto:[email-masked]>>, "Stefano Previdi (sprevidi)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] [Mapping Server] Conflict Resolution

Robert -

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Saturday, March 18, 2017 1:55 AM
To: Les Ginsberg (ginsberg)
Cc: tech_kals Kals; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Stefano Previdi (sprevidi); Peter Psenak (ppsenak)
Subject: Re: [spring] [Mapping Server] Conflict Resolution

Hi Kals,

Hi Les,

Absolutely – this constraint defeats the whole purpose of an SRMS.

I’m not implying that this is even a viable option. However, I’ll point out that this wouldn’t even be possible since you could not guarantee that you had the complete set of mappings for the downstream node.

Thanks,
Acee

   Les

Kind regards,
R.

And Section 3.2.1

   where P1 <= P2

Comments inline

Hi Les,

                         incoming entry is X:

                         incoming entry is X:

                         incoming entry is X:

HTH

   Les

Regards,
__tech.kals__

Thanx.

   Les

Hi Experts,

My doubts:

can you please clarify ?

Regards,
__tech.kals__

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sat, 18 Mar 2017 16:06:34 +0000

Acee -

From: Acee Lindem (acee)
Sent: Saturday, March 18, 2017 8:59 AM
To: Les Ginsberg (ginsberg); Robert Raszuk
Cc: [email-masked]; Peter Psenak (ppsenak); tech_kals Kals; Stefano Previdi (sprevidi); [email-masked]
Subject: Re: [spring] [Mapping Server] Conflict Resolution

Robert -

Hi Kals,

Hi Les,

I’m not implying that this is even a viable option. However, I’ll point out that this wouldn’t even be possible since you could not guarantee that you had the complete set of mappings for the downstream node.
[Les:] Agreed. One does not use SID advertisements (whether from prefix reachability or from SRMS) from unreachable nodes – which is probably the more useful point to make.
What is also true is that for locally configured SIDs, they MUST NOT be included in conflict resolution unless they are also advertised. Simply configuring a SID locally is not sufficient.

   Les

Thanks,
Acee

   Les

Kind regards,
R.

And Section 3.2.1

   where P1 <= P2

Comments inline

Hi Les,

                         incoming entry is X:

                         incoming entry is X:

                         incoming entry is X:

HTH

   Les

Regards,
__tech.kals__

Thanx.

   Les

Hi Experts,

My doubts:

can you please clarify ?

Regards,
__tech.kals__

---

From: tech_kals Kals <[email-masked]>
Date: Sun, 19 Mar 2017 12:09:36 +0530

*Hi Les,*

*Thank you so much for your clarification.*

*I have one more question here...*

*1) the newly incoming entry would do conflict resolution validation with
all existing entries and will be programmed only if it doesn't have any
conflict with any entries or if it wins in conflict resolution with all of
them? *

*In this case, the entry will be programmed only if it wins over all
entries, even if it fails with any one of the entry, it would not be added.
But, the entry which fails to win with the new entry also would exists in
the database. It would have not got removed.*

*Is my understanding right ?*

*2) Or when new entry X do conflict resolution validation with each entry
and assume, all entries are having a conflict resolution with this new
entry and the new entry wins over all entries. So, in this case, all of
them gets removed; only new entry would be added.*

*3) In cisco routers, I observed the below behavior. *
*    Whenever there is any conflict (prefix/SID) with entries, the entry
which wins if it has lower system-id ( system-id is in the context of ISIS
protocol) though it has higher prefix/SID values. i.e. it seems,
"system-ID" is treated as "preference value". *
*Why system-ID is being treated as preference value ?  Can you please
clarify ?*

*Coming back to our discussion, I thinks, there is a conflict with all 3
entries in all 3 scenarios.*

*Please see my reply inline with <KALS>*

*Regards,*
*_tech.kals_*

> *E2 has no conflict w X nor with E1.*

*<KALS> *

*There is a conflict between X and E2 also.*

*E2 expands to (10.1.1.0/24 <http://10.1.1.0/24> through 10.1.5.0/24
<http://10.1.5.0/24>) using SIDs 150 -154*
*X expands to (10.1.2.0/24 <http://10.1.2.0/24> – 10.1.21.0/24
<http://10.1.21.0/24>) using SIDs 200-219.*

*Prefix 10.1.2.0 to 10.1.5.0 are conflicting between entry-X and entry-E2.*
*Will E2 win as they have lower range ?*

*So, **only **E2 will exist in this case. *
*E1 will be removed due to conflict with X and X would be removed due to
conflict with E2.*

*Assume, if I have some more entries in the table say E3 to E100, they will
not be participating in the conflict resolution validation as X is lost to
E2 itself. Isn't it ?*

*Is there any criteria that all entries such as E1, E2 and so on should be
in sorted order ? Otherwise, performing validation with all mapping entries
will be difficult if they have not been sorted. Isnt it ?*

*Could you please let me know whether am I right ?*

> *So E1 and E2 are used and X is ignored.*

*<KALS> *

*So, X will be added only if it is not having any conflict with all
existing entries.*

*X will not be validated with other entries once it loses to someone ? Am i
rght ?*

*What will happen if,*

*  - the new entry wins with some entries and*
*  - losing to some ?*

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sun, 19 Mar 2017 15:22:17 +0000

Kals –

Inline…look for “Les2”

Sent: Saturday, March 18, 2017 11:40 PM

Hi Les,

Thank you so much for your clarification.

I have one more question here...

1) the newly incoming entry would do conflict resolution validation with all existing entries and will be programmed only if it doesn't have any conflict with any entries or if it wins in conflict resolution with all of them?

In this case, the entry will be programmed only if it wins over all entries, even if it fails with any one of the entry, it would not be added. But, the entry which fails to win with the new entry also would exists in the database. It would have not got removed.

Is my understanding right ?

2) Or when new entry X do conflict resolution validation with each entry and assume, all entries are having a conflict resolution with this new entry and the new entry wins over all entries. So, in this case, all of them gets removed; only new entry would be added.

[Les2:] When an entry arrives has no bearing on the application of the preference rule. Conceptually (I am not talking about actual implementation details) when the database changes (new entry added, existing entry modified or deleted) the algorithm must be re-executed on the complete contents of the database – not just on the changed entries..

3) In cisco routers, I observed the below behavior.

[Les2:] There currently is no standard. Individual vendors have implemented whatever seemed best to them at the time. When there is WG agreement on a standard behavior then it should be expected that implementations will be modified to conform to the standard.

    Whenever there is any conflict (prefix/SID) with entries, the entry which wins if it has lower system-id ( system-id is in the context of ISIS protocol) though it has higher prefix/SID values. i.e. it seems, "system-ID" is treated as "preference value".
Why system-ID is being treated as preference value ?  Can you please clarify ?

Coming back to our discussion, I thinks, there is a conflict with all 3 entries in all 3 scenarios.

Please see my reply inline with <KALS>

Regards,
_tech.kals_

On Sat, Mar 18, 2017 at 11:19 AM, Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>> wrote:
Kals –

And Section 3.2.1

   where P1 <= P2

Comments inline

Hi Les,

                         incoming entry is X:

<KALS>

There is a conflict between X and E2 also.

[Les2:] You are correct – my error.
So, processing entries in range order (smallest to highest)

E2 has a conflict with X. X is ignored.
E2 has no conflict with E1.
E1 and E2 are used – X is ignored.

Apologies for the confusion.

E2 expands to (10.1.1.0/24<http://10.1.1.0/24> through 10.1.5.0/24<http://10.1.5.0/24>) using SIDs 150 -154
X expands to (10.1.2.0/24<http://10.1.2.0/24> – 10.1.21.0/24<http://10.1.21.0/24>) using SIDs 200-219.

Prefix 10.1.2.0 to 10.1.5.0 are conflicting between entry-X and entry-E2.
Will E2 win as they have lower range ?

So, only E2 will exist in this case.
E1 will be removed due to conflict with X and X would be removed due to conflict with E2.

Assume, if I have some more entries in the table say E3 to E100, they will not be participating in the conflict resolution validation as X is lost to E2 itself. Isn't it ?

Is there any criteria that all entries such as E1, E2 and so on should be in sorted order ? Otherwise, performing validation with all mapping entries will be difficult if they have not been sorted. Isnt it ?

Could you please let me know whether am I right ?

                         incoming entry is X:

<KALS>

So, X will be added only if it is not having any conflict with all existing entries.

X will not be validated with other entries once it loses to someone ? Am i rght ?

What will happen if,

  - the new entry wins with some entries and
  - losing to some ?

[Les2:] We apply the comparison based on the order of the preference rules. Once an entry loses it is no longer a candidate for comparison using any of the lower priority preference rule.

   Les

                         incoming entry is X:

HTH

   Les

Regards,
__tech.kals__

Thanx.

   Les

Hi Experts,

My doubts:

can you please clarify ?

Regards,
__tech.kals__

---

From: tech_kals Kals <[email-masked]>
Date: Wed, 22 Mar 2017 10:02:23 +0530

*Hi Les,*

* Thanks for your clarification. It was really helpful.*

* I have few more questions.*

* 1) How would you handle identical entries has been populated by more than
one Mapping Server at the same time ?*
*     For example, assume the below mapping entry is populated by Say,
Mapping-Server-1 and Mapping-Server-2*

*     MS-1 entry:   10.1.1.0/24 <http://10.1.1.0/24>, 200, 2*
*     MS-2 entry:   10.1.1.0/24 <http://10.1.1.0/24>, 200, 2*

*     I don't think, the draft talks about this case.*

*2) If there is sub-set of identical entries populated by two different
mapping servers.*

*     MS-1 entry:   10.1.3.0/24 <http://10.1.3.0/24>, 200, 2*
*     MS-2 entry:   10.1.1.0/24 <http://10.1.1.0/24>, 198, 5*

*     In this case, 10.1.3.0, 200; 10.1.4.0, 201 are identical entries. How
to handle this scenario ?*

*3) Is preference values are configurable per mapping server or per-mapping
entry ? *

*I mean, once preference value is configured per mapping server then it
would be applicable for all mapping entries which are triggered from the
mapping server ? Isn't it ?*

*I see, All SIDs advertised in prefix reachability advertisements
implicitly **have a preference value of 192. It means, preference
configured for the node will not applicable for "**prefix reachability
advertisements" ? Isn't it ? *

*So, the main purpose of preference is to give preference for a specific
mapping server ?*

*4) One very basic question...*

*In case of LDP-SR inter-working, mapping entries are stitched by intersect
node. *

*Where as in SR-LDP **inter-working, stitching can't be done. Why do we
need to use mapping server ? Why cant we use stitching?*

*Thanks in adv Les,*

*Regards,*
*_tech.kals_*

On Sun, Mar 19, 2017 at 8:52 PM, Les Ginsberg (ginsberg) <[email-masked]

> *Sent:* Saturday, March 18, 2017 11:40 PM
> *[Les2:] When an entry arrives has no bearing on the application of the
> preference rule. Conceptually (I am not talking about actual implementation
> details) when the database changes (new entry added, existing entry
> modified or deleted) the algorithm must be re-executed on the complete
> contents of the database – not just on the changed entries..*
>
>
>
> *[Les2:] There currently is no standard. Individual vendors have
> implemented whatever seemed best to them at the time. When there is WG
> agreement on a standard behavior then it should be expected that
> implementations will be modified to conform to the standard. *
>
>
>
> *[Les2:] You are correct – my error.*
>
> *So, processing entries in range order (smallest to highest)*
>
>
>
> *E2 has a conflict with X. X is ignored.*
>
> *E2 has no conflict with E1.*
>
> *E1 and E2 are used – X is ignored.*
>
>
>
> *Apologies for the confusion.*
>
>
>
>
>
> *So, only E2 will exist in this case. *
>
> *Assume, if I have some more entries in the table say E3 to E100, they
> will not be participating in the conflict resolution validation as X is
> lost to E2 itself. Isn't it ?*
>
>
>
> *X will not be validated with other entries once it loses to someone ? Am
> i rght ?*
>
>
>
> *What will happen if,*
>
>
>
> *[Les2:] We apply the comparison based on the order of the preference
> rules. Once an entry loses it is no longer a candidate for comparison using
> any of the lower priority preference rule.*
>
>
>
> *   Les*
>
>
>
>
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 22 Mar 2017 06:28:09 +0000

Kals -

From: tech_kals Kals [mailto:[email-masked]]
Sent: Tuesday, March 21, 2017 9:32 PM
To: Les Ginsberg (ginsberg)
Cc: [email-masked]; Peter Psenak (ppsenak); Stefano Previdi (sprevidi)
Subject: Re: [Mapping Server] Conflict Resolution

Hi Les,

 Thanks for your clarification. It was really helpful.

 I have few more questions.

 1) How would you handle identical entries has been populated by more than one Mapping Server at the same time ?
     For example, assume the below mapping entry is populated by Say, Mapping-Server-1 and Mapping-Server-2

     MS-1 entry:   10.1.1.0/24<http://10.1.1.0/24>, 200, 2
     MS-2 entry:   10.1.1.0/24<http://10.1.1.0/24>, 200, 2

[Les:] There is no conflict – entries are identical – it does not matter which entry is used.
This is actually what I would expect to see. If one has multiple SRMSs in a network they are expected to advertise the same information.
Primary purpose of multiple SRMSs is to provide redundancy.

     I don't think, the draft talks about this case.

2) If there is sub-set of identical entries populated by two different mapping servers.

     MS-1 entry:   10.1.3.0/24<http://10.1.3.0/24>, 200, 2
     MS-2 entry:   10.1.1.0/24<http://10.1.1.0/24>, 198, 5

[Les:] Again, there is no conflict. Both entries can be used.
The definition of a prefix conflict is explicitly defined at the end of  Section 3.2.1 of the draft. Apply the logic to your example.

     In this case, 10.1.3.0, 200; 10.1.4.0, 201 are identical entries. How to handle this scenario ?

3) Is preference values are configurable per mapping server or per-mapping entry ?

[Les:] Preference is per mapping server- NOT per mapping entry. This is stated in Section 3.1 of the draft:

“If a node acts as an SRMS, it MAY advertise a preference to be
   associated with all SRMS SID advertisements sent by that node.”

I mean, once preference value is configured per mapping server then it would be applicable for all mapping entries which are triggered from the mapping server ? Isn't it ?

I see, All SIDs advertised in prefix reachability advertisements implicitly have a preference value of 192. It means, preference configured for the node will not applicable for "prefix reachability advertisements" ? Isn't it ?

[Les:] Correct.

So, the main purpose of preference is to give preference for a specific mapping server ?

[Les:] Yes. SRMS preference provides a way to provision a new mapping server, have its advertisements validated but not actually used. This provides a non-disruptive way to bring a new server online.

4) One very basic question...

In case of LDP-SR inter-working, mapping entries are stitched by intersect node.

Where as in SR-LDP inter-working, stitching can't be done. Why do we need to use mapping server ? Why cant we use stitching?

[Les:] I am not sure what you mean by “stitching”.
Nodes which do not support SR clearly will not advertise SIDs for the prefixes they originate. SRMS can be configured to advertise SIDs on behalf of the non-SR-capable nodes – thus allowing SR labels to be used in the SR enabled portion of the network even for destinations on nodes which are NOT SR-capable.

It is also possible to use SRMS as a central provisioning tool – eliminating the need to configure SIDs locally on each SR capable router.

   Les

Thanks in adv Les,

Regards,
_tech.kals_

On Sun, Mar 19, 2017 at 8:52 PM, Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>> wrote:
Kals –

Inline…look for “Les2”

Hi Les,

Regards,
_tech.kals_

And Section 3.2.1

   where P1 <= P2

Comments inline

Hi Les,

                         incoming entry is X:

<KALS>

                         incoming entry is X:

<KALS>

What will happen if,

   Les

                         incoming entry is X:

HTH

   Les

Regards,
__tech.kals__

Thanx.

   Les

Hi Experts,

My doubts:

can you please clarify ?

Regards,
__tech.kals__