Re: [spring] [Mapping Server] Conflict Resolution

[Robert Raszuk <[e-mail]>]

Kals,

> *Entry X:        <10.1.2.0/24 <http://10.1.2.0/24>,  200, 20> *can be
expanded up to *<10.1.21.0/24 <http://10.1.21.0/24>, 221>*

I think you are confusing SID with prefix. Those have nothing in common
other then SID being "attached" to a prefix.

In IP routing prefix with mask is usually NOT EXPANDABLE.

When you advertise 10.1.2.0/24 it will better remain 10.1.2.0/24.

Cheers,
R.


On Fri, Mar 17, 2017 at 11:27 AM, tech_kals Kals <[e-mail]>
wrote:

> Hi Robert,
>
>   As I have mentioned on the previous mail, there is a conflict on each
> scenario.
>
> *Scenario 1:   (Entries are conflicting with prefix)*
>                          Entry *E1:      <10.1.10.0/24
> <http://10.1.10.0/24>, 300, 22>  *can be expanded up to *<10.1.31.0/24
> <http://10.1.31.0/24>, 321>*
>                          Entry *E2:      <10.1.1.0/24
> <http://10.1.1.0/24>,   150, 5>  *can be expanded up to *<10.1.5.0/24
> <http://10.1.5.0/24>, 154>*
>
> *                         incoming entry is X:*
> *                         Entry X:        <10.1.2.0/24
> <http://10.1.2.0/24>,  200, 20> *can be expanded up to *<10.1.21.0/24
> <http://10.1.21.0/24>, 221>*
>
>                      entry-X prefix range *10.1.10.0 to 10.1.21.0 *would
> conflict with entry *E1 *and *10.1.2.0 to 10.1.5.0* would conflict with
> *E2*.
>
>                      *So, there is a prefix conflict.*
>
>
> *Scenario 2:   **(Entries are conflicting with SID)*
>                          Entry *E1:      <10.1.10.0/24
> <http://10.1.10.0/24>, 300, 22>  *can be expanded up to *<10.1.31.0/24
> <http://10.1.31.0/24>, 321>*
>                          Entry *E2:      <7.1.1.0/24 <http://7.1.1.0/24>,
>     280, 10>  *can be expanded up to *<7.1.10.0/24 <http://7.1.10.0/24>,
> 289>*
>
> *                         incoming entry is X:*
> *                         Entry X:        <3.1.1.0/24 <http://3.1.1.0/24>,
>   285, 20>  *can be expanded up to *<3.1.19.0/24 <http://3.1.19.0/24>,
> 304>*
>
>                      entry-X SID *300 *to *304 *would conflict with entry
> *E1 *and *SID 285 to 289* would conflict with *E2*.
>
>                      *So, there is a SID conflict.*
>
> *Scenario 3:    **(Entries are conflicting with prefix and SID)*
>
>                          Entry *E1:      <10.1.10.0/24
> <http://10.1.10.0/24>, 300, 22>  *can be expanded up to *<10.1.31.0/24
> <http://10.1.31.0/24>, 321>*
>                          Entry *E2:      <5.1.1.0/24 <http://5.1.1.0/24>,
>     190, 15>  *can be expanded up to *<5.1.15.0/24 <http://5.1.15.0/24>,
> 204>*
>
> *                         incoming entry is X:*
> *                         Entry X:        <10.1.1.0/24
> <http://10.1.1.0/24>,  200, 20> *can be expanded up to *<10.1.20.0/24
> <http://10.1.20.0/24>, 219>*
>
>                     entry-X prefix range *10.1.10.0 to 10.1.20.0 *would
> conflict with entry *E1 and **SID 200 to 219* would conflict with *E2*.
>
>                     *So, there is a Prefix and SID conflict.*
>
> Regards,
> _tech.kals_
>
> On Fri, Mar 17, 2017 at 1:53 PM, Robert Raszuk <[e-mail]> wrote:
>
>> Hi,
>>
>> Scenario 1 - I do not see any prefix conflict. Those are independent /24
>> prefixes.
>>
>> Scenario 2 - X IP prefix will be installed in RIB but SR labels (entire
>> range) will be blocked for X.
>>
>> Scenario 3 - I do not see any prefix conflict. SR labels (entire range)
>> will be blocked for X.
>>
>> Cheers,
>> R.
>>
>>
>> On Fri, Mar 17, 2017 at 9:09 AM, tech_kals Kals <[e-mail]>
>> wrote:
>>
>>> 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>*
>>>
>>> *                         incoming entry is X:*
>>> *                         Entry X:        <10.1.2.0/24
>>> <http://10.1.2.0/24>,  200, 20>*
>>>
>>> *           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>*
>>>
>>> *                         incoming entry is X:*
>>> *                         Entry X:        <3.1.1.0/24
>>> <http://3.1.1.0/24>,   285, 20>*
>>>
>>> *           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>*
>>>
>>> *                         incoming entry is X:*
>>> *                         Entry X:        <10.1.1.0/24
>>> <http://10.1.1.0/24>,  200, 20>*
>>>
>>> *           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
>>>
>>>
>>
>