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:[email protected]]
Sent: Friday, March 17, 2017 1:09 AM
To: Les Ginsberg (ginsberg)
Cc: [email protected]; Peter Psenak (ppsenak); Stefano Previdi (sprevidi);
[email protected]
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 through 10.1.31.0/24) using SIDs 300-321
E2 expands to (10.1.1.0/24 through 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 – 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)
<[email protected]<mailto:[email protected]>> 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:[email protected]<mailto:[email protected]>]
Sent: Thursday, March 16, 2017 7:22 PM
To: [email protected]<mailto:[email protected]>; Les Ginsberg (ginsberg); Peter
Psenak (ppsenak); Stefano Previdi (sprevidi);
[email protected]<mailto:[email protected]>
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
[email protected]
https://www.ietf.org/mailman/listinfo/spring
