Kals -
From: tech_kals Kals [mailto:[email protected]]
Sent: Tuesday, March 21, 2017 9:32 PM
To: Les Ginsberg (ginsberg)
Cc: [email protected]; Peter Psenak (ppsenak); Stefano Previdi (sprevidi)
Subject: Re: [Mapping Server] Conflict Resolution
Hi Les,
Thanks for your clarification. It was really helpful.
I have few more questions.
1) How would you handle identical entries has been populated by more than one
Mapping Server at the same time ?
For example, assume the below mapping entry is populated by Say,
Mapping-Server-1 and Mapping-Server-2
MS-1 entry: 10.1.1.0/24<http://10.1.1.0/24>, 200, 2
MS-2 entry: 10.1.1.0/24<http://10.1.1.0/24>, 200, 2
[Les:] There is no conflict – entries are identical – it does not matter which
entry is used.
This is actually what I would expect to see. If one has multiple SRMSs in a
network they are expected to advertise the same information.
Primary purpose of multiple SRMSs is to provide redundancy.
I don't think, the draft talks about this case.
2) If there is sub-set of identical entries populated by two different mapping
servers.
MS-1 entry: 10.1.3.0/24<http://10.1.3.0/24>, 200, 2
MS-2 entry: 10.1.1.0/24<http://10.1.1.0/24>, 198, 5
[Les:] Again, there is no conflict. Both entries can be used.
The definition of a prefix conflict is explicitly defined at the end of
Section 3.2.1 of the draft. Apply the logic to your example.
In this case, 10.1.3.0, 200; 10.1.4.0, 201 are identical entries. How to
handle this scenario ?
3) Is preference values are configurable per mapping server or per-mapping
entry ?
[Les:] Preference is per mapping server- NOT per mapping entry. This is stated
in Section 3.1 of the draft:
“If a node acts as an SRMS, it MAY advertise a preference to be
associated with all SRMS SID advertisements sent by that node.”
I mean, once preference value is configured per mapping server then it would be
applicable for all mapping entries which are triggered from the mapping server
? Isn't it ?
I see, All SIDs advertised in prefix reachability advertisements implicitly
have a preference value of 192. It means, preference configured for the node
will not applicable for "prefix reachability advertisements" ? Isn't it ?
[Les:] Correct.
So, the main purpose of preference is to give preference for a specific mapping
server ?
[Les:] Yes. SRMS preference provides a way to provision a new mapping server,
have its advertisements validated but not actually used. This provides a
non-disruptive way to bring a new server online.
4) One very basic question...
In case of LDP-SR inter-working, mapping entries are stitched by intersect node.
Where as in SR-LDP inter-working, stitching can't be done. Why do we need to
use mapping server ? Why cant we use stitching?
[Les:] I am not sure what you mean by “stitching”.
Nodes which do not support SR clearly will not advertise SIDs for the prefixes
they originate. SRMS can be configured to advertise SIDs on behalf of the
non-SR-capable nodes – thus allowing SR labels to be used in the SR enabled
portion of the network even for destinations on nodes which are NOT SR-capable.
It is also possible to use SRMS as a central provisioning tool – eliminating
the need to configure SIDs locally on each SR capable router.
Les
Thanks in adv Les,
Regards,
_tech.kals_
On Sun, Mar 19, 2017 at 8:52 PM, Les Ginsberg (ginsberg)
<[email protected]<mailto:[email protected]>> wrote:
Kals –
Inline…look for “Les2”
From: tech_kals Kals [mailto:[email protected]<mailto:[email protected]>]
Sent: Saturday, March 18, 2017 11:40 PM
To: Les Ginsberg (ginsberg)
Cc: [email protected]<mailto:[email protected]>; Peter Psenak (ppsenak); Stefano
Previdi (sprevidi);
[email protected]<mailto:[email protected]>
Subject: Re: [Mapping Server] Conflict Resolution
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.
[Les2:] When an entry arrives has no bearing on the application of the
preference rule. Conceptually (I am not talking about actual implementation
details) when the database changes (new entry added, existing entry modified or
deleted) the algorithm must be re-executed on the complete contents of the
database – not just on the changed entries..
3) In cisco routers, I observed the below behavior.
[Les2:] There currently is no standard. Individual vendors have implemented
whatever seemed best to them at the time. When there is WG agreement on a
standard behavior then it should be expected that implementations will be
modified to conform to the standard.
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)
<[email protected]<mailto:[email protected]>> 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:[email protected]<mailto:[email protected]>]
Sent: Friday, March 17, 2017 1:09 AM
To: Les Ginsberg (ginsberg)
Cc: [email protected]<mailto:[email protected]>; Peter Psenak (ppsenak); Stefano
Previdi (sprevidi);
[email protected]<mailto:[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<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.
<KALS>
There is a conflict between X and E2 also.
[Les2:] You are correct – my error.
So, processing entries in range order (smallest to highest)
E2 has a conflict with X. X is ignored.
E2 has no conflict with E1.
E1 and E2 are used – X is ignored.
Apologies for the confusion.
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 ?
[Les2:] We apply the comparison based on the order of the preference rules.
Once an entry loses it is no longer a candidate for comparison using any of the
lower priority preference rule.
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 ?
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
