An even simpler proposal for the prefix conflict:
- if a SID is attached to the prefix (Prefix-SID Sub-TLV) use it.
- IOW, prefix-SID have precedence over Mapping Server advertisements. (note
that this was the original text, a few years back in the IGP drafts)
- This looks pretty simple as this is about disregarding (in
fact not even looking at) MS entries.
- otherwise looks for MS entries
- there should be few since they are compressed using the
"range" field, so there should not be "scalability issues"
- if this is still too complex to look for MS entries and pick
one, I suppose that the Quarantine algo could be used on the MS entries (at
least SR capable nodes would not suffer from the conflict, and their proportion
should increase over time).
This would clearly simplify the draft, which is what you are calling for: no
need to introduce the following complexities: "Generalized Mapping entry",
"derived mapping entries" and their associated complexity. As a consequence,
this would also simplify the discussion in the WG.
Additional advantages are:
- implementations would not be mandated to support the Mapping Server at all
(neither server nor client side). This is interesting for vendors not having
deployment case mandating LDP interworking. (e.g. greenfield deployment,
possibly DC environment, mono-vendor networks)
- advertisement from SR nodes are always used and do not conflict. As time
goes, we should expect that the proportion of SR compatible nodes increase,
which in the long run favor the simple rule (don't even consider SRMS) and the
absence of conflict (while with SRMS, we have, by design, multiple
advertisements covering the same prefix: 2 SRMS advertisements for redundancy,
plus Prefix SID for SR nodes. Hence chance to have conflict in case not all
configurations are equals)
- in the long run, we could deprecate MS entries and SR-LDP interworking, with
no impact on the selection rules/selected entries.
Regards,
--Bruno
From: spring [mailto:[email protected]] On Behalf Of Les Ginsberg
(ginsberg)
Sent: Monday, December 05, 2016 1:04 AM
To: [email protected]<mailto:[email protected]>
Subject: [spring] SID Conflict Resolution: A Simpler Proposal
When the problem addressed by draft-ietf-spring-conflict-resolution was first
presented at IETF 94, the authors defined the following priorities:
1)Detect the problem
2)Report the problem
This alerts the network operator to the existence of a conflict so that
the configuration error can be corrected.
3)Define consistent behavior
This avoids mis-forwarding while the conflict exists.
4)Don't overengineer the solution
Given that it is impossible to know which of the conflicting entries
is the correct one, we should apply a simple algorithm to resolve the conflict.
5)Agree on the resolution behavior
The resolution behavior was deliberately the last point because it was
considered the least important.
Input was received over the past year which emphasized the importance of
trying to "maximize forwarding" in the presence of conflicts. Subsequent
revisions of the draft have tried to address this concern. However the authors
have repeatedly stressed that the solution being proposed
("ignore overlap only") was more complex than other offered alternatives and
would be more difficult to guarantee interoperability because subtle
differences in an implementation could produce different results.
At IETF97 significant feedback was received preferring a simpler solution to
the problem. The authors are very sympathetic to this feedback and therefore
are proposing a solution based on what the draft defines as the "Ignore"
policy - where all entries which are in conflict are ignored. We believe this
is far more desirable and aligns with the priorities listed above.
We outline the proposed solution below and would like to receive feedback from
the WG before publishing the next revision of the draft.
Les (on behalf of the authors)
New Proposal
In the latest revision of the draft "SRMS Preference" was introduced. This
provides a way for a numerical preference to be explicitly associated with an
SRMS advertisement. Using this an operator can indicate which advertisement is
to be preferred when a conflict is present. The authors think this is a useful
addition and we therefore want to include this in the new solution.
The new preference rule used to resolve conflicts is defined as follows:
A given mapping entry is compared against all mapping entries in the database
with a preference greater than or equal to its own. If there is a conflict,
the mapping entry with lower preference is ignored. If two mapping entries are
in conflict and have equal preference then both entries are ignored.
Implementation of this policy is defined as follows:
Step 1: Within a single address-family/algorithm/topology sort entries
based on preference
Step 2: Starting with the lowest preference entries, resolve prefix conflicts
using the above preference rule. The output is an active policy per topology.
Step 3: Take the outputs from Step 2 and again sort them by preference
Step 4: Starting with the lowest preference entries, resolve SID conflicts
using the above preference rule
The output from Step 4 is then the current Active Policy.
Here are a few examples. Each mapping entry is represented by the tuple:
(Preference, Prefix/mask Index range <#>)
Example 1:
1. (150, 1.1.1.1/32 100 range 100)
2. (149, 1.1.1.10/32 200 range 200)
3. (148, 1.1.1.101/32 500 range 10)
Entry 3 conflicts with entry 2, it is ignored.
Entry 2 conflicts with entry 1, it is ignored.
Active policy:
(150, 1.1.1.1/32 100 range 100)
Example 2:
1. (150, 1.1.1.1/32 100 range 100)
2. (150, 1.1.1.10/32 200 range 200)
3. (150, 1.1.1.101/32 500 range 10)
4. (150, 2.2.2.1/32 1000 range 1)
Entry 1 conflicts with entry 2, both are marked as ignore.
Entry 3 conflicts with entry 2. It is marked as ignore.
Entry 4 has no conflicts with any entries
Active policy:
(150, 2.2.2.1/32 1000 range 1)
Example 3:
1. (150, 1.1.1.1/32 100 range 500)
2. (150, 1.1.1.10/32 200 range 200)
3. (150, 1.1.1.101/32 500 range 10)
4. (150, 2.2.2.1/32 1000 range 1)
Entry 1 conflicts with entries 2, 3, and 4. All entries are marked ignore.
Active policy:
Empty
Example 4:
1. (150, 1.1.1.1/32 100 range 10)
2. (149, 1.1.1.10/32 200 range 300)
3. (149, 1.1.1.101/32 500 range 10)
4. (148, 2.2.2.1/32 1000 range 1)
Entry 4 conflicts with entry 2. It is marked ignore.
Entry 2 conflicts with entry 3. Entries 2 and 3 are marked ignore.
Active policy:
(150, 1.1.1.1/32 100 range 10)
_________________________________________________________________________________________________________________________
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
