Bruno -
I don't find your representation complete as regards all of the attributes
which are proposed to be used by the conflict resolution algorithm - so it is
therefore hard for me to use/understand this representation when applying the
defined preference rule.
This is true for me even after reading your explanations below.
But it is far more important to have a common understanding of the algorithm
proposal than it is to be arguing over whose encoding is "better". If the
encoding in the draft is not clear or could use improvement, I welcome your
feedback.
As far as your "pseudo-code":
- Find all SIDi advertised for the prefix P1
// identification of Prefix conflicts
- For each SIDi find all the prefix Pij associated with SIDi
// identification of SID conflicts
Get the best as per the preference algorithm.
If best Pij == P1
then use SIDij for P1
else return no SID
The fact that you can represent an algorithm in a few lines does not mean the
implementation of the algorithm is just as simple. Consider what needs to be
done to implement
"Find all SIDi advertised for the prefix P1"
In its simplest form, we have a list of all SID advertisements (PFX and SRMS)
that we have received. One could imagine walking all the entries, looking to
see if the prefix of interest is present within the advertised range. But, of
course, at large scale such an approach is extremely inefficient - so we
immediately start considering ways to improve performance. Inserting received
entries into an ordered tree of some kind is an obvious way to improve
performance. When one further considers that calculating conflict resolution
only needs to be done when a change to the received database occurs (which post
startup is infrequent) it becomes very attractive to cache the "winning
entries" so that if one wants to retrieve the SID for a given prefix we only
have to examine a subset of the total database - ignoring the losers.
In this context, we can appreciate the difference between the three proposed
algorithms. In particular comparing "Quarantine" with "ignore overlap only", a
key difference is that "Quarantine" only needs to determine whether a received
entry is a winning entry or a losing entry. "Ignore overlap only" has to be
capable of breaking received entries with ranges > 1 into multiple "derived"
entries (some winning, some losing), which means we now need to track the
"derived entries" against the original received entry so that if the received
entry is updated/deleted we can find all the derived entries and
delete/regenerate the derived entries as needed. This is what adds complexity.
All proposed algorithms can be implemented, but it does seem prudent to
consider implementation complexity as part of our decision process - and the
discussion/examples in Section 3 are meant to help in doing this.
It is worthwhile restating that when conflicts are present we cannot guarantee
that forwarding will work correctly no matter what algorithm is used. The more
complex the implementation the more likely it is that bugs will be present and
the more likely it is that interoperability issues will arise. Whether these
costs/risks are worth the "value add" when the outcome cannot be guaranteed to
be correct - only guaranteed to be consistent - is an important consideration.
Also important to remember that conflicts MUST be eliminated by correcting the
misconfigurations that caused them - so conflict resolution is really only an
interim measure until the corrections can be made. No one should be lulled into
thinking that because we have conflict resolution deployed that correcting the
configuration when conflicts are detected is not a priority.
Les
From: [email protected] [mailto:[email protected]]
Sent: Thursday, June 30, 2016 5:10 AM
To: Les Ginsberg (ginsberg)
Cc: [email protected]
Subject: RE: draft-ietf-spring-conflict-resolution - Policy
Les,
Thanks for the discussion. Please see inline [Bruno]
From: Les Ginsberg (ginsberg) [mailto:[email protected]]
Sent: Wednesday, June 29, 2016 6:00 PM
To: DECRAENE Bruno IMT/OLN
Cc: [email protected]<mailto:[email protected]>
Subject: RE: draft-ietf-spring-conflict-resolution - Policy
Bruno -
As the thread below documents, I stated that I did not understand your
representation and asked for clarification - suggesting that you use the format
defined in the draft.
You stated that you could not do that and we were at a point where no progress
could be made.
[Bruno] I could _not_ use your format since your format did not include the
information need. This is not a whim but a technical issue. So I asked you to
still consider the message. Rather than waiting for a time-out, there was a way
to make progress by asking clarification questions on the points which were not
clear, or at least explicitly refusing to consider the email.
I also note that what bothered you in my representation was my addition of the
type of advertisement (prefix or MS). But you finally have just added in the
latest version of the draft "Src- PFX or SRMS" . So there was probably a way to
communicate.
Besides the algo did not use any specification representation, just names. So
I'll copy/paste it below, please ask clarification questions for the parts
which are not clear enough.
The problem that we need to solve, is to find the SID for a prefix (P1).
The algo could be:
- Find all SIDi advertised for the prefix P1
// identification of Prefix conflicts
- For each SIDi find all the prefix Pij associated with SIDi
// identification of SID conflicts
// as a result, for P1, we get a list of (SIDi, Pij)
Get the best (SIDi, Pij) as per the preference algorithm.
If best Pij == P1
then use SIDij for P1
else return no SID / no SID available
for this prefix P1
To illustrate my confusion, one of your examples is:
For R2, the algo evaluates a conflict between the following advertisments:
R2 - SID2 - R2 (MS, MS)
R2 - SID12 - R12 (prefix SID, MS)
R2 - SID12 - R2 (prefix SID, prefix SID)
Now, what does "R2 - SID2 - R2 (MS, MS)" mean?
[Bruno]
- MS/prefix SID is the type of advertisement. In your new version, you call it
SRMS/PFX.
- SID is the SID found in the Mapping Entrie
- Rx is the loopback (prefix) or router Rx
So "R2 - SID2 - R2 (MS, MS)" is the outpout of the algo described above and
means: For prefix R2, we found a MS mapping entries advertising SID2 for this
prefix, and then I found a MS mapping entries advertising prefix R2 for SID2.
Does it mean "On R2, SID2 is assigned to prefix R2 from two different mapping
server entries?" I really have no idea.
And you conclude the example by saying
Best one is R2 - SID12 - R2 (smaller range (prefix SID),smaller range (prefix
SID))
==> SID12 is selected for R2.
But since there is no representation of "range" in your examples I really have
no idea how you came to this conclusion .
[Bruno] I agree that since the above algo used 2 mapping entries to provides
the (SIDi, Pij), the preference algo (ยง3.2.4) would need to be adapted. That
being said, this is not important for this discussion. Let's just considered
that their exist a preference algorithm, which takes as input a list of (SIDi,
Piij) for P1, and gives as outpout the "best" one. (definition of "best" is not
pertinent)
??
As regards "per FEC/Prefix", I believe this is what "ignore overlap only" does.
[Bruno] Indeed, this is my expectation. But I would need someone's review to
confirm this.
But the difference is that the proposed algo is simple (2 lines of pseudo
code), with very modest resquirement data structure use to store the mapping
entries. Indeed, all it needs is a function returning the list of mapping
entries associated/matching a given prefix. And function returning the list of
mapping entries associated/matching a given SID.
In particular, there is no need for splitting mapping entries which is the main
complexity of your proposed "Preference algorithm/ignore overlap only".
(according to your own text).
-- Bruno
Les
From: [email protected]<mailto:[email protected]>
[mailto:[email protected]]
Sent: Wednesday, June 29, 2016 7:22 AM
To: Les Ginsberg (ginsberg)
Cc: [email protected]<mailto:[email protected]>
Subject: RE: draft-ietf-spring-conflict-resolution - Policy
Les,
Thanks for the updated draft.
IINM, you have not answered my below email/proposal. I had waited for the new
version of the draft but it also does not touch this subject.
So, could you please consider and answer my comment?
In short, in an implementation-independent sentence:
> I'm wondering if we could address the conflict on a per FEC/Prefix basis
> rather than on a per IGP advertisement (range) basis.
> If so, this may avoid the discussion between the Quarantine vs ignore policy.
Thanks
Bruno
From: spring [mailto:[email protected]] On Behalf Of
[email protected]<mailto:[email protected]>
Sent: Wednesday, May 18, 2016 1:57 PM
To: Les Ginsberg (ginsberg); [email protected]<mailto:[email protected]>
Subject: Re: [spring] draft-ietf-spring-conflict-resolution - Policy
Les,
Please see inline [Bruno]
From: Les Ginsberg (ginsberg) [mailto:[email protected]]
Sent: Sunday, May 15, 2016 12:41 AM
To: DECRAENE Bruno IMT/OLN; [email protected]<mailto:[email protected]>
Subject: RE: draft-ietf-spring-conflict-resolution - Policy
Bruno -
I am having difficulty parsing the examples you provide below as they seem to
incorporate advertisement source into the description whereas the draft
deliberately omits source.
[Bruno] My text does not incorporate the source, but the type of source IOW the
type of sub-TLV.
So it does not matter if R2 sends an advertisement or R12 sends advertisement
or both of them do (which could happen when an advertisement is leaked) - what
matters is what unique entries are in the database independent of source.
[Bruno] It may not matter for your algorithm (pending another thread), but it
does for the one I proposed.
It would be good if you could present your examples using the format defined in
the draft i.e.:
[Bruno] My examples are described in plain text. Then the examples giving
intermediate steps of my algo uses the data that are needed i.e. the type of
advertisement (Prefix-SID vs MS).
Then finally, my algo runs on a per FEC/IP Prefix basis, and not on a per IGP
advertisement basis which your format describe.
So I'm sorry but I don't see how to indulge your request.
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
T - Topology
A - Algorithm
A Mapping Entry is then the tuple: (Pi/L, Si, R, T, A)
Pe = (Pi + ((R-1) << (Lx-L))
Se = Si + (R-1)
Example: (192.0.2.120/32, 200, 1, 0, 0)
As regards your proposal
- Find all SIDi advertised for the prefix P1
// identification of Prefix conflicts
- For each SIDi find all the prefix Pij associated with SIDi
// identification of SID conflicts
Get the best as per the preference algorithm.
If best Pij == P1
then use SIDij for P1
else return no SID
this to me specifies an implementation - which isn't necessary.
[Bruno] Well, _you_ are the one talking about implementation, and more
specifically implementation complexity.
Assuming the above algo works, it looks relatively simple to implement, in
which case, I would not buy the argument about implementation complexity which
is the only argument in favor or the "ignore" or "quarantine" policy.
Bottom line, I would welcome your feedback and comments on this proposed
algo/policy.
Thanks,
Regards,
-- Bruno
However, there is one important point which has not been specified in the draft
which reading your post has brought to my attention - that is the order in
which checks are made.
The draft states:
"Prefix conflicts are specific to mapping entries sharing the same topology
and algorithm."
"SID conflicts are independent of address-family, independent of prefix len,
independent of topology, and independent of algorithm."
If we consider an example where a network supports two VPNs, the significance
of ordering in the evaluation of conflicts will be highlighted:
VPN1:
(192.0.2.1/32, 100, 1, 1, 0)
(192.0.2.1/32, 200, 1, 1, 0)
VPN2:
(192.0.2.100/32, 200, 1, 2, 0)
If we evaluate prefix conflicts first, then the following entries are "active":
(192.0.2.1/32, 100, 1, 1, 0) !VPN1
(192.0.2.100/32, 200, 1, 2, 0) !VPN2
If we evaluate SID conflicts first, then the following entries are "active":
(192.0.2.1/32, 100, 1, 1, 0) !VPN1
The latter choice is suboptimal because it prevents use of the VPN2 entry
unnecessarily.
This point needs to be made explicit in the draft.
Les
From: spring [mailto:[email protected]] On Behalf Of
[email protected]<mailto:[email protected]>
Sent: Thursday, May 12, 2016 8:23 AM
To: [email protected]<mailto:[email protected]>
Subject: [spring] draft-ietf-spring-conflict-resolution - Policy
Hi authors, all
As an individual contributor, please find below some feedback on the policy.
I'm wondering if we could address the conflict on a per FEC/Prefix basis rather
than on a per IGP advertisement basis.
If so, this may avoid the discussion between the Quarantine vs ignore policy.
The problem that we need to solve, is to find the SID for a prefix (P1).
The algo could be:
- Find all SIDi advertised for the prefix P1
// identification of Prefix conflicts
- For each SIDi find all the prefix Pij associated with SIDi
// identification of SID conflicts
// as a result, we get a list of SIDi - Pij for P1
Get the best as per the preference algorithm.
If best Pij == P1
then use SIDij for P1
else return no SID / no SID available
for this prefix P1
Note that it would probably be better for the preference algo to put the SID
tie-brake before the prefix tie-break as with the prefix tie-break, we suffer
from the conflict twice (Prefix - SID mapping, then SID- prefix mapping) which
increase the diversity and hence the chance of not finding a valid entry. But
for the below examples, I used the preference algo from draft-ietf-*-00
Below are examples, running this policy on typical configuration error cases.
Examples
3.4.4. Network operation
Consider the following simple network example:
1. 100 nodes: R1 to R100;
2. IP Loopbacks are from 192.0.2.1 to 192.0.2.100:
3. SID are from 1 to 100;
4. R1 to R50 are SR capable and advertised their own SID using
Prefix-SID sub-TLV;
5. R51 to R100 are SR non-capable, running LDP and their SID are
advertised by two redundant Mapping Server MS1 and MS2;
6. As the number of nodes which are SR capable are expected to
increase and as in real deployment their Loopback addresses would
no the contiguous, the Mapping servers advertisement covers all
Loopbacks: (192.0.2.1/32, 1, 100);
Subsequent sections evaluate the consequences of a single
configuration error, for all conflict resolution options.
3.4.4.1. Example 1: SID configured on 1 node conflict with SID
configured on another node
Following a typo during configuration, R2 is configured with a SID of
12. That SID conflicts with the Prefix-SID advertised by R12 and the
Mapping Server Advertisement for R12.
Note: both MS advertisement are the same, so we only consider one in the
below analysis.
All prefix but R2 and R12, a single SID is advertised and hence selected.
For R2, the algo evaluates a conflict between the following advertisments:
R2 - SID2 - R2 (MS, MS)
R2 - SID12 - R12 (prefix SID, MS)
R2 - SID12 - R2 (prefix SID, prefix SID)
Best one is R2 - SID12 - R2 (smaller range (prefix SID),smaller range
(prefix SID))
==> SID12 is selected for R2.
For R12, the algo evaluates a conflict between the following advertisments:
R12 - SID12 - R12 (prefix SID, prefix SID)
R12 - SID12 - R2 (prefix SID, prefix SID)
R12 - SID12 - R12 (prefix SID, MS)
R12 - SID12 - R2 (MS, prefix SID)
R12 - SID12 - R12 (MS, MS)
Best one is R12 - SID12 - R2 (smaller range (prefix SID),smaller range
(prefix SID), smaller starting adresse (R2))
R12 <> R2 ==> R12 has no SID.
3.4.4.2. Example 2: SID configured on 1 node conflict with SID
configured on the Mapping Server
Following a typo during configuration, R2 is configured with a SID of
52. That SID conflicts with the Mapping Server advertisements of MS1
and MS2 for the loopback of R52.
Note: both MS advertisement are the same, so we only consider one in the
below analysis.
All prefix but R2 and R52, a single SID is advertised and hence selected.
For R2, the algo evaluates a conflict between the following advertisments:
R2 - SID52 - R2 (prefix SID, prefix SID)
R2 - SID52 - R52 (prefix SID, MS)
R2 - SID2 - R2 (MS, MS)
Best one is R2 - SID52 - R2 (smaller range (prefix SID),smaller range
(prefix SID))
==> SID52 is selected for R2.
For R52, the algo evaluates a conflict between the following advertisments:
R52 - SID52 - R52 (MS, MS)
R52 - SID52 - R2 (MS, prefix SID)
Best one is R52 - SID52 - R2 (smaller range (prefix SID))
R52 <> R2 ==> R52 has no SID.
3.4.4.3. Example 3: wrong configuration of a MS
Following a typo during configuration, MS1 is configured
(192.0.2.0/32, 1, 100). (i.e. 192.0.2.0 instead of 192.0.2.1). That
advertisement conflicts with the Mapping Server advertisements of MS2
and the Prefix-SID advertised by R1...R50.
We have a conflict for all routers except R100.
For LDP only routers R51 to R99 we have a conflict between both MS
advertisement.
For R52, the algo evaluates a conflict between the following advertisments:
R52 - SID52 - R52 (MS2, MS2)
R52 - SID52 - R51 (MS2, MS1)
R52 - SID53 - R52 (MS1, MS1)
R52 - SID53 - R53 (MS1, MS2)
Best one is R52 - SID52 - R51 (smaller starting address)
R52 <> R51 ==> R52 has no SID.
For SR routers, R1 to 50, we have a conflict between both MS advertisement
and Prefix SID advertisements.
For R2, the algo evaluates a conflict between the following advertisments:
R2 - SID 2 - R2 (Prefix SID, Prefix SID)
R2 - SID 2 - R2 (Prefix SID, MS2)
R2 - SID 2 - R1 (Prefix SID, MS1)
R2 - SID 2 - R2 (MS2, MS2)
R2 - SID 2 - R2 (MS2, Prefix SID)
R2 - SID 2 - R1 (MS2, MS1)
R2 - SID 3 - R2 (MS1, MS1)
R2 - SID 3 - R3 (MS1, MS2)
R2 - SID 3 - R3 (MS1, Prefix SID)
Best one is R2 - SID 2 - R2 (Prefix SID, Prefix SID)
R2 == R2 hence R2 use SID2.
Regards,
Bruno
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
