Re: [spring] [Mapping Server] Conflict Resolution

[Robert Raszuk <[e-mail]>]

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) <[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.*
>
> *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]> 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__
>
>
>
> _______________________________________________
> spring mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spring
>
>