Re: [spring] [Mapping Server] Conflict Resolution

[tech_kals Kals <[e-mail]>]

*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) <[e-mail]
> wrote:

> Kals –
>
>
>
> Inline…look for “Les2”
>
>
>
> *From:* tech_kals Kals [mailto:[e-mail]]
> *Sent:* Saturday, March 18, 2017 11:40 PM
> *To:* Les Ginsberg (ginsberg)
> *Cc:* [e-mail]; Peter Psenak (ppsenak); Stefano Previdi
> (sprevidi); [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]> 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]]
> *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 <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
> <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]> 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]]
> *Sent:* Thursday, March 16, 2017 7:22 PM
> *To:* [e-mail]; Les Ginsberg (ginsberg); Peter Psenak (ppsenak);
> Stefano Previdi (sprevidi); [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__
>
>
>
>
>