Re: [spring] [Mapping Server] Conflict Resolution

["Les Ginsberg (ginsberg)" <[e-mail]>]

Kals –

Please look closely at how to determine if there is a conflict.
From 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)
       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:[e-mail]]
Sent: Friday, March 17, 2017 1:09 AM
To: Les Ginsberg (ginsberg)
Cc: [e-mail]; Peter Psenak (ppsenak); Stefano Previdi (sprevidi); [e-mail]
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) <[e-mail]<mailto:[e-mail]>> 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)

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:[e-mail]<mailto:[e-mail]>]
Sent: Thursday, March 16, 2017 7:22 PM
To: [e-mail]<mailto:[e-mail]>; Les Ginsberg (ginsberg); Peter Psenak (ppsenak); Stefano Previdi (sprevidi); [e-mail]<mailto:[e-mail]>
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__