Les, After mental reset I conclude that perhaps even the introduction of the draft is questionable as in real life it applies to be quite an unrealistic scenario to have a situation where more then one protocol is used *in the same time* as active in forwarding for an exact same IP prefix.
Last time I checked SIDs are meaningless without a prefix they are attached to and it is a prefix they accompany to indicate which SID should be used on a given node. Therefor if you consider that today most implementations pretty well can handle overlapping prefixes from multiple sources what real problem is this draft solving ? Are you trying to create a forwarding graph by SIDs only detaching them from IP prefixes all together ? Cheers, R. On Thu, Dec 22, 2016 at 10:32 PM, Les Ginsberg (ginsberg) < ginsb...@cisco.com> wrote: > Robert – > > > > You have a complete misunderstanding of roles here. > > > > How the owner of a route may be represented in the RIB isn’t impacted by > SRMS or conflict resolution. Nor is the determination of which route is the > best route. We are only determining whether to use or not use a SID which > was associated with the prefix by some advertisement. > > > > The Introduction to the draft states: > > > > “The problem to be addressed is protocol independent i.e., segment > > related advertisements may be originated by multiple nodes using > > different protocols and yet the conflict resolution MUST be the same > > on all nodes regardless of the protocol used to transport the > > advertisements.” > > > > Please do a mental reset. J > > > > Les > > > > > > *From:* rras...@gmail.com [mailto:rras...@gmail.com] *On Behalf Of *Robert > Raszuk > *Sent:* Thursday, December 22, 2016 11:52 AM > *To:* Les Ginsberg (ginsberg) > *Cc:* Aissaoui, Mustapha (Nokia - CA); spring@ietf.org > > *Subject:* Re: [spring] SID Conflict Resolution: A Simpler Proposal > > > > Hi Les, > > > > On #1 I am also with Mustapha here. For clarity of this discussion can you > enumerate when from RIB to FIB/LFIB you are installing the exact same > active prefix from more then one producer ? Is SRMS sort of zombie here and > not treated as real route producer hence we have an issue ? And the issue > is only with conflicts of SRMS + real route producer ? > > > > On #3 you said that *"with redistribution/route leaking the source of an > advertisement may appear to be different on different routers"* that is > very true. In fact with simple static route or static label configured on a > router the RIB and FIB on that router will be different then RIB and FIB on > the other routers without such static route. And the point is that such > static route or label is there for a reason you may not know about. So > struggling for data plane consistency deliberately excluding source when > operational needs require otherwise is not really that much helpful I am > afraid. > > > > Greetings, > > Robert. > > > > > > On Thu, Dec 22, 2016 at 8:37 PM, Les Ginsberg (ginsberg) < > ginsb...@cisco.com> wrote: > > Mustapha - > > > > *From:* spring [mailto:spring-boun...@ietf.org] *On Behalf Of *Aissaoui, > Mustapha (Nokia - CA) > *Sent:* Thursday, December 22, 2016 8:10 AM > *To:* Les Ginsberg (ginsberg); spring@ietf.org > *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.* > > > > 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.* > > > > 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.* > > > > * Les* > > > > Regards, > > Mustapha. > > > > *From:* Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com > <ginsb...@cisco.com>] > *Sent:* Friday, December 09, 2016 1:49 PM > *To:* Aissaoui, Mustapha (Nokia - CA) <mustapha.aissa...@nokia.com>; > spring@ietf.org > *Subject:* RE: SID Conflict Resolution: A Simpler Proposal > > > > Mustapha - > > > > *From:* Aissaoui, Mustapha (Nokia - CA) [mailto:mustapha.aissaoui@ > nokia.com <mustapha.aissa...@nokia.com>] > *Sent:* Friday, December 09, 2016 7:44 AM > *To:* Les Ginsberg (ginsberg); spring@ietf.org > *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 > <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:spring-boun...@ietf.org <spring-boun...@ietf.org>] *On > Behalf Of *Les Ginsberg (ginsberg) > *Sent:* Sunday, December 04, 2016 7:04 PM > *To:* 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. > > > > 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 > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
