Re: [spring] [Mapping Server] Conflict Resolution

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

Acee -

From: Acee Lindem (acee)
Sent: Saturday, March 18, 2017 8:59 AM
To: Les Ginsberg (ginsberg); Robert Raszuk
Cc: [e-mail]; Peter Psenak (ppsenak); tech_kals Kals; Stefano Previdi (sprevidi); [e-mail]
Subject: Re: [spring] [Mapping Server] Conflict Resolution



From: spring <[e-mail]<mailto:[e-mail]>> on behalf of "Les Ginsberg (ginsberg)" <[e-mail]<mailto:[e-mail]>>
Date: Saturday, March 18, 2017 at 10:59 AM
To: Robert Raszuk <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "Peter Psenak (ppsenak)" <[e-mail]<mailto:[e-mail]>>, tech_kals Kals <[e-mail]<mailto:[e-mail]>>, "Stefano Previdi (sprevidi)" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [spring] [Mapping Server] Conflict Resolution

Robert -

From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of Robert Raszuk
Sent: Saturday, March 18, 2017 1:55 AM
To: Les Ginsberg (ginsberg)
Cc: tech_kals Kals; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; Stefano Previdi (sprevidi); Peter Psenak (ppsenak)
Subject: Re: [spring] [Mapping Server] Conflict Resolution

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 ?

[Les:] It is not the responsibility of the SRMS to validate that what has been configured is installed in any node’s forwarding plane – and it would be a “catch-22” situation if that were required since until a SID is advertised no label can be installed by any node.
If your argument is that there should be a SID advertised by the node which owns a prefix before SRMS advertises a SID, then it becomes impossible to support partial deployment where some prefixes are owned by SR incapable nodes.

Absolutely – this constraint defeats the whole purpose of an SRMS.



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 ?

[Les:] No. Having such a policy would introduce additional convergence issues. To know whether a given label was being used by a downstream node you would have to run conflict resolution from the POV of the downstream node because the output of that node’s conflict resolution calculation could be different than the local node’s output.

I’m not implying that this is even a viable option. However, I’ll point out that this wouldn’t even be possible since you could not guarantee that you had the complete set of mappings for the downstream node.
[Les:] Agreed. One does not use SID advertisements (whether from prefix reachability or from SRMS) from unreachable nodes – which is probably the more useful point to make.
What is also true is that for locally configured SIDs, they MUST NOT be included in conflict resolution unless they are also advertised. Simply configuring a SID locally is not sufficient.

   Les

Thanks,
Acee





   Les


Kind regards,
R.


On Sat, Mar 18, 2017 at 6:49 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.
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]<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__


_______________________________________________
spring mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/spring