Re: [spring] [Mapping Server] Conflict Resolution

[tech_kals Kals <[e-mail]>]

*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_*


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

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



> *           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__
>
>
>