Bruno - From: bruno.decra...@orange.com [mailto:bruno.decra...@orange.com] Sent: Wednesday, December 21, 2016 6:40 AM To: Les Ginsberg (ginsberg) Cc: spring@ietf.org Subject: RE: SID Conflict Resolution: A Simpler Proposal
Les, Still as an individual contributor, SID conflict resolution is about a trade-off between implementation complexity and network availability. Hence evaluating the consequences on network availability is at least as important as evaluating the implementation complexity; especially as the former is easier to quantify while the latter may be implementation specific. So on this FEC/network availability standpoint, please find below three comments. 1) The slides presented might IMHO slightly mislead a reader: - the discussion on network availability compares "Quarantine" vs "Ignore Overlap" - the conclusion discuss "Ignore Overlap" vs "Ignore" So they are comparing different things, while a quick reader may assume that apples were compared to apples. Note that I'm not saying (and not thinking) that this is misleading on purpose. I'm expressing the way I read it. [Les:] Please remember the history here. Prior to Seoul the input we had was: "Ignore" is least desirable - evaluate between "Quarantine" and "Ignore Overlap". The discussion over the previous few months therefore was comparing the latter two. Slides for both Berlin and Seoul were therefore prepared with that in mind. Significant feedback at Seoul and since has made "Ignore" a candidate again - so the email thread has now focused on "Ignore" vs "Ignore Overlap Only". If I had received this feedback before Seoul I would have prepared different slides. My apologies for not being clairvoyant. :) 2) Regarding the new proposal, post Seoul, it is vocal on the complexity side, but not on the network availability side which is not evaluated. This does not helps the WG understanding of the trade-off involved and the making of an informed decision. I'm even wondering if the network availability has been considered since by default, this proposal seems to kill, by design, the SRMS and SR-LDP inter-working. SRMS has been designed in order to allow for the inter-working with LDP, in a brown-field scenario where SR is introduced in a LDP MPLS network. e.g. a typical set of advertisements would be 1. PrefixSID: (192, 1.1.1.1/32 100 range 1) 2. MS: (128, 1.1.1.1/32 100 range 255) With this simple example, not even having a configuration error but using a nominal configuration, the MS advertisement would be ignored with the ignore policy, hence the LDP interwork would not work, and all LDP/non-SR nodes would loose SID hence loose SR connectivity. Eventually, you may change the algorithm, to look beyond the most preferred entry, and check whether the SIDs are really different or not. And if not, change the algo to pick the largest range rather than the highest preference. But this is adding complexity to cover a specific case, while keeping the solution weak in term of network availability, in the general case. e.g. if we do have a different SID, many prefix (99%) would lose their SID. [Les:] Your interpretation is incorrect. There is no conflict in the example you provide - therefore no entries will be ignored (this is true no matter what conflict resolution strategy is chosen). The definition of conflicts can be found in Section 3.2 of the draft. Nothing in this discussion proposes changes to that- and the definition of a conflict has never been under debate. What we have discussed over the last 6 months or more has been what to do when conflicts exist- this is Section 3.3 of the draft. 3) Finally, when discussing "Ignore Overlap", a typical quote from the authors is "maximize forwarding" or "operate optimally", as if we were trying to optimize for the last bit. But note that "Ignore Overlap" is _not_ maximizing forwarding. Maximizing forwarding would be much more complex, and nobody on the list has even tried for this, including draft-ietf-spring-conflict-resolution. e.g. with following advertisements with a misconfiguration 1. PrefixSID: (192, 1.1.1.1/32 101 range 1) 2. MS: (128, 1.1.1.1/32 100 range 255) During prefix conflict, for 1.1.1.1/32 Ignore Overlap selects the SID from prefixSID entry, which will latter have a SID conflict with the MS entry (SID 101, prefixes 1.1.1.1 vs 1.1.1.2). As a result, 1.1.1.2 won't get a SID. In this specific case, a solution "maximizing the forwarding" would have ignored the PrefixSID. But in the general case, "maximizing the forwarding" may require evaluating all options, and then pick the best one based on all results. So please let's keep evaluating the impact on the network availability. Berlin presentation was a good example on this. [Les:] Well, the Berlin slides (see Slide 25) use the term "Maximize SR Forwarding". https://www.ietf.org/proceedings/96/slides/slides-96-spring-4.pdf One of the problems with making a choice when conflicts exist is that there is no way of knowing what prefixes are the most important in a particular network deployment. "Ignore overlap only" aimed to maximize the number of prefixes which had SIDs in the hope that we would have a greater chance of including the more important prefixes - but since all of our tie-breakers are simply arbitrary choices there is no guarantee. From Section 3.3.4 of the draft: 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 If you were to seriously try to focus on "network availability" we would need to incorporate additional information which might include: · Is a prefix reachable? · How much traffic depends on each prefix · What class of traffic depends on each prefix This can only increase the complexity of the implementation - and I have no doubt the debate about the best heuristics could go on without end. I return again to the priorities which the authors stated from the beginning: 1)Detect the problem 2)Report the problem 3)Define consistent behavior 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 For some of us, the resolution behavior is the least important. For you it seems it is the most important. That is what the debate is really about. Les --Bruno From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] Sent: Friday, December 09, 2016 7:31 PM To: DECRAENE Bruno IMT/OLN Cc: spring@ietf.org<mailto:spring@ietf.org> Subject: RE: SID Conflict Resolution: A Simpler Proposal Bruno - Welcome back to the discussion. :) Inline. From: bruno.decra...@orange.com<mailto:bruno.decra...@orange.com> [mailto:bruno.decra...@orange.com] Sent: Friday, December 09, 2016 2:07 AM To: Les Ginsberg (ginsberg) Cc: spring@ietf.org<mailto:spring@ietf.org> Subject: RE: SID Conflict Resolution: A Simpler Proposal Hi Les, As a individual contributor, please find below some clarification questions [Bruno] From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Les Ginsberg (ginsberg) Sent: Monday, December 05, 2016 1:04 AM To: spring@ietf.org<mailto:spring@ietf.org> 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. [Bruno] In the draft, the "Ignore" policy (§3.3.1) ignores all conflicting entries. In your below proposition, the policy seems to pick the most preferred entry. This looks like more similar to the "Quarantine" policy proposed in the draft (§3.3.2) Am I missing something? [Les:] At the time "Ignore" was introduced (over a year ago) the notion of "SRMS preference" did not exist - that was only added in the most recent version of the draft. We (the authors) feel that this is a useful construct because: 1)It provides an explicit basis on which to choose between conflicting entries. 2)It is particularly useful when bringing up a new SRMS as it allows the advertised values to be verified before they are used. So, your comment is correct in that there is now a preference algorithm in use - whereas with the original definition of "Ignore" there was no preference algorithm. But the sole criteria of the preference rule is the explicitly configured preference - none of the other criteria proposed for Quarantine are used - and in particular we do not make partial use of a mapping entry as is the case with "Ignore Overlap Only". I am happy to modify the nomenclature - but the point of this thread is not to replace a new draft revision - it is to get the sense of the WG before we publish a new revision as to whether we should continue down the "Ignore Overlap only" path or move to a simpler strategy - so let's not be too picky about the naming. 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 [Bruno] I'm not sure what you are refering to by "preference". Is this the IGP "SRMS Preference sub-TLV" or is this the preference defined in the draft (§3.3.4)? [Les:] It is the former. Assuming you meant the SRMS preference, why limiting to this field, rather than including all fields defined in the draft preference algo? Using the latter would reduce the risk of ignoring all entries (i.e. having no entry in output of this algo). Also a priori, a sort would not be required as a single pass could select the most preferred entry. [Les:] The point of the alternative proposal is a simplification. The presentation in Seoul (check out the slides) highlighted complexities in the implementation of "ignore-overlap-only" - in particular subtleties in the order in which an implementation looks at entries which could produce interoperability issues even though implementations are using the same preference rule. The alternative reduces the chances of these interoperability issues occurring because the algorithm used is simpler and less subject to subtle implementation differences. If you want to argue that these are solvable problems I won't disagree with you - it is a question of where we want to put our time and effort. A number of folks are commenting that they prefer to focus on fixing the configuration and not invest time in validating that conflict resolution is implemented in an interoperable way. As we (the authors) have stated from the beginning, we believe the emphasis should be on detecting and reporting the conflicts - not spending cycles implementing the most robust means of trying to operate optimally while the misconfiguration exists. I know you disagree on this point - but that is exactly what the WG is debating - not whether it is possible to make "ignore overlap only" work. Les Thanks -- Bruno 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. _________________________________________________________________________________________________________________________ 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 spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
