Re: [spring] [Mapping Server] Conflict Resolution

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

Kals -

From: tech_kals Kals [mailto:[e-mail]]
Sent: Tuesday, March 21, 2017 9:32 PM
To: Les Ginsberg (ginsberg)
Cc: [e-mail]; 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) <[e-mail]<mailto:[e-mail]>> wrote:
Kals –

Inline…look for “Les2”

From: tech_kals Kals [mailto:[e-mail]<mailto:[e-mail]>]
Sent: Saturday, March 18, 2017 11:40 PM
To: Les Ginsberg (ginsberg)
Cc: [e-mail]<mailto:[e-mail]>; Peter Psenak (ppsenak); Stefano Previdi (sprevidi); [e-mail]<mailto:[e-mail]>
Subject: Re: [Mapping Server] Conflict Resolution

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) <[e-mail]<mailto:[e-mail]>> wrote:
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]<mailto:[e-mail]>]
Sent: Friday, March 17, 2017 1:09 AM
To: Les Ginsberg (ginsberg)
Cc: [e-mail]<mailto:[e-mail]>; Peter Psenak (ppsenak); Stefano Previdi (sprevidi); [e-mail]<mailto:[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<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<http://10.1.2.0/24>,  200, 20>

[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

So, if we examine entries in range order (smallest to highest) we find:
E2 has no conflict w X nor with E1.

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


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.


<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


           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__