Hi Les, I am supporting the "ignore overlap only" policy. The reason I am bringing the "per-prefix resolution" in this discussion is because the SID conflict resolution happens naturally in 2 steps as part of the prefix resolution:
1. First resolve SID conflicts of the same prefix. 2. Then, resolve SID conflicts across prefixes. This way, all the SIDs associated with a given prefix are first evaluated and a value is chosen. Then if multiple prefixes from step (1) have conflicting SIDs then install a single SID only in step (2). We just need simple rules to make the selection within each step. I agree that the "ignore" policy is simpler as it does not have to worry about a selection algorithm but it seems to me it will lead to unnecessary loss of SR forwarding capability. Regards, Mustapha. From: Les Ginsberg (ginsberg) [mailto:[email protected]] Sent: Sunday, January 01, 2017 12:15 PM To: Aissaoui, Mustapha (Nokia - CA) <[email protected]>; [email protected] Subject: RE: SID Conflict Resolution: A Simpler Proposal Mustapha - Some responses inline, but I emphasize again that the most important issue being discussed at the moment is what to do when conflicts are detected. There are two proposals: 1)Do not use the SIDs which are in conflict ("Ignore") 2)Use some conflict resolution algorithm to choose how to use the conflicting SIDs ("Ignore overlap only") I would encourage you and everyone else to comment on that. If we choose #2 above then the specific preference rule (currently defined in Section 3.3.4 of the draft) can be reviewed - but not much point in doing so until we decide whether we are going to use a preference rule at all. From: Aissaoui, Mustapha (Nokia - CA) [mailto:[email protected]] Sent: Friday, December 23, 2016 6:59 AM To: Les Ginsberg (ginsberg); [email protected]<mailto:[email protected]> Subject: RE: SID Conflict Resolution: A Simpler Proposal Hi Les, I made some follow-up inline. Regards, Mustapha. From: Les Ginsberg (ginsberg) [mailto:[email protected]] Sent: Thursday, December 22, 2016 2:37 PM To: Aissaoui, Mustapha (Nokia - CA) <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Subject: RE: SID Conflict Resolution: A Simpler Proposal Mustapha - From: spring [mailto:[email protected]] On Behalf Of Aissaoui, Mustapha (Nokia - CA) Sent: Thursday, December 22, 2016 8:10 AM To: Les Ginsberg (ginsberg); [email protected]<mailto:[email protected]> Subject: Re: [spring] SID Conflict Resolution: A Simpler Proposal Hi Les, I read slides 17-21 of the document you referenced below and I have the following comments: 1. Page 17, "Order Matters - Prefix vs SID Conflict". When you perform resolution on a per prefix basis, prefix conflicts are naturally processed first followed by SID conflicts across different prefixes. So the ordering issue described is only specific if you decided to resolve conflicting SID entries outside of the natural prefix resolution by a router. [Les:] What may seem "natural" to you might not to someone else. I don't care to debate that point. What is being illustrated here is that in order to provide a normative specification that - if followed - guarantees interoperability we have to specify the order in which conflicts are processed otherwise different results may be obtained. MA> I agree on the intent of specifying a procedure which achieves interoperability. However, it seems to me this draft is ignoring the fact that routers do per-prefix resolution and is trying to perform the SID resolution outside of it. [Les2:] Section 3.2 of the draft details the types of conflicts which may occur. These include: 1)Prefix conflicts - different SIDs assigned to the same prefix 2)SID conflicts - multiple prefixes associated with the same SID The term "pre-prefix resolution" suggests to me that you think all we have to do is find all the SID advertisements associated with a given prefix in order to determine whether we have a conflict or not. But that only finds "prefix conflicts" - it does not find SID conflicts - and both have to be dealt with. If you mean something else please clarify. 2. Page 18, "Order Matters: Derived vs non-derived- prefix conflict". It seems to me this issue is an artifact of the specific algorithm used to resolve conflicts. Because the algorithm uses parameters such as "Range (start w smallest)" then obviously derived SRMS entries will lend a different result than original SRMS entries. With the pre-prefix resolution, the only information kept from the original SRMS entry is the preference and the advertising or owner router. Anything else is not used. It seems to me a simple algorithm based on preference first then followed by some rule on selecting the advertising router if conflicts exist within the same preference would work. [Les:] You have implemented things in a certain way. Someone else might choose to implement in a different way. A normative specification does not (and should not) constrain an implementation. What is being illustrated here is that if the implementation does not retain the underived entry (in whatever internal form it chooses) different results will be obtained because the preference algorithm depends on comparing the underived ranges. MA> I do not believe this is about implementation. It is about what routers do and that is resolution per prefix. It does not matter how the prefix SID information is advertised, individually or part of an SRMS entry, at the end it is associated with a prefix. 3. Finally, there is something which has not been addressed in the slides. There is still a possibility of conflicting entries among SIDs advertised using the prefix SID sub-TLV within a Prefix TLV (IS-IS IP Reach TLV or OSPF Extended Prefix TLV). A simple rule selecting the advertising router should also work fine here. [Les:] No - source of an advertisement has been quite deliberately excluded from the preference algorithm. With redistribution/route leaking the source of an advertisement may appear to be different on different routers- this would result in different results on different routers. MA> The following RFC is specifying an optional attribute (the IPv4/IPv6 Source Router ID TLV) to encode the original advertising router of a prefix. This can be used to perform a simple selection algorithm: https://tools.ietf.org/html/rfc7794#section-2.2 Otherwise, what is your proposal for this point (3)? I could not find it addressed in the current version of the draft. [Les2:] The proposal is NOT to use the source of an advertisement as an input to conflict resolution. RFC 7794 only addresses the issue for IS-IS and even then only for SIDs learned via prefix reachability advertisements. Use of source still has consistency issues for SRMS advertisements, OSPF, and cases which involve multiple protocol instances. This choice has been consciously made and is in part based on our experience with existing implementations. That said, this issue is only relevant if you believe it is necessary/desirable to use a preference rule to make a choice when a conflict exists. The proponents of "Ignore" don't want to do this - we want to NOT use SIDs which are in conflict. We believe this is less likely to lead to interoperability problems and is less likely to have undesirable side effects. It also prioritizes detection and reporting of conflicts. Les Regards, Mustapha. From: Les Ginsberg (ginsberg) [mailto:[email protected]] Sent: Friday, December 09, 2016 1:49 PM To: Aissaoui, Mustapha (Nokia - CA) <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Subject: RE: SID Conflict Resolution: A Simpler Proposal Mustapha - From: Aissaoui, Mustapha (Nokia - CA) [mailto:[email protected]] Sent: Friday, December 09, 2016 7:44 AM To: Les Ginsberg (ginsberg); [email protected]<mailto:[email protected]> Subject: RE: SID Conflict Resolution: A Simpler Proposal I have a couple of comments on the below proposal. 1. Regarding the SRMS Preference Sub-TLV in section 3.1 of the draft. In many cases, a configuration on the resolving router can assign a preference to each SRMS in case there is no advertisement of this sub-TLV or to override an advertised value. I propose that this option be allowed. Here is a proposed update to the relevant paragraph: " Advertisement of a preference value is optional. Nodes which do not advertise a preference value are assigned a preference value of 128. A resolving router can override the default or the advertised value by local policy. " [Les:] In order to get consistent conflict resolution on all nodes in the network, it is necessary that they all have the same database - which includes the preference value. If you allow local policy to modify the preference you no longer have consistent databases on all nodes and we can no longer guarantee consistent conflict resolution. So your proposal is not viable IMO. 2. I am trying to understand the concept of sorting SRMS entries which have different prefixes and different range sizes. Since a SID advertised in a prefix SID sub-TLV within a Prefix TLV (IS-IS IP Reach TLV or OSPF Extended Prefix TLV) has higher priority over a SID for the same prefix advertised from a SRMS, then you have to add to the below sorting an entry for each individual prefix which advertised a prefix SID sub-TLV within a prefix TLV. At this point, the concept of an entry with multiple prefixes is moot and you may as well just sort on a per prefix basis which is the most natural thing to do given that the prefix resolution and then the SID resolution are performed on a per prefix basis. SID conflicts can be resolved on a per prefix basis using the below proposed preference algorithm without having to ignore SID values for unrelated prefixes just because it happens that they were advertised in the same SRMS entry. [Les:] The simpler proposal does not require sorting on anything other than preference. After that, you can process entries in any order you want and you will get the same answer. With "Ignore Overlap Only" one of the issues with trying to use the non-conflicting portions of a mapping entry which has a range > 1 is that the order in which you process entries influences the result. Please see slides 17 - 20 from the IETF97 presentation: https://www.ietf.org/proceedings/97/slides/slides-97-spring-1_ietf97_draft-ietf-spring-conflict-resolution-02-00.pptx for some simple examples of this. Les Regards, Mustapha. From: spring [mailto:[email protected]] On Behalf Of Les Ginsberg (ginsberg) Sent: Sunday, December 04, 2016 7:04 PM 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)
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
