Hi Les, Thanks for your explanation -- quite helpful. Please see inline..
On Fri, Feb 18, 2022 at 7:38 PM Les Ginsberg (ginsberg) <[email protected]> wrote: > Muthu – > > > > Let me try to be more complete in my response. > > > > What RFC 7775 is addressing is defining the route preference between > different route types. It is necessary for interoperability that all > implementations use the same preference rules in this regard. > > (One of the motivations for the RFC was a real world interoperability > issue that occurred because of inconsistency in this regard – see Appendix > A.) > Understood.. Within the preference groups defined in Sections 3.3 and 3.4, an > implementation has to apply the criteria used in the SPF algorithm. If this > is the well known Dijkstra lowest cost algorithm described in Annex C.2 of > ISO 10589, then within the set of routes with highest preference we choose > the path(s) with lowest cost. > Makes sense and that's why I pasted a part of the foll. text from RFC5308 in my original mail: <snip> If multiple paths have the same best preference, then selection occurs based on metric. Any remaining multiple paths SHOULD be considered for equal-cost multi-path routing if the router supports this; otherwise, the router can select any one of the multiple paths. </snip> Since RFC7775 only updates RFC5308 (and not replaces it), I believe the rule also applies to RFC7775. The text in RFC7775 that is slightly confusing (at least for me) is: <snip> Note that all types of routes listed for a given preference are treated equally. </snip> Would sound better to replace it with what you said: "Within the preference groups defined in Sections 3.3 and 3.4, an implementation has to apply the criteria used in the SPF algorithm." If there are multiple paths with the same cost, an implementation may > install any or all of them in forwarding even if all routes are NOT of the > same type. > > In your example, so long as the cost to reach the destination using the L1 > intra-area route is the same as the cost to reach the destination via the > L1 External route, use of either path will NOT result in looping. > > And one node could install both paths – another could install only one > path – and still no looping would occur. > > > > Lack of use of ECMP might result in link utilization that is not to the > liking of a customer, but no interoperability issue will occur. > > > > So the prioritization you mention below is NOT required to avoid looping. > Fully agree.. Regards, Muthu > > > Les > > > > *From:* Muthu Arul Mozhi Perumal <[email protected]> > *Sent:* Thursday, February 17, 2022 11:59 PM > *To:* Les Ginsberg (ginsberg) <[email protected]> > *Cc:* lsr <[email protected]> > *Subject:* Re: [Lsr] Preference among IS-IS IPv6 route types > > > > Hi Les, > > > > If we do ECMP, we'll have a traffic loop in the topology described in > Appendix A of RFC7775 b/w R1 and R2, assuming all routes are L1, right? > > > > Seems prioritizing one of the routes (intra-area vs external) or honouring > the metric is required for avoiding this loop.. > > > > Regards, > > Muthu > > > > On Thu, Feb 17, 2022 at 9:46 PM Les Ginsberg (ginsberg) < > [email protected]> wrote: > > Muthu – > > > > Use of Equal Cost Multipath (ECMP) is commonplace. > > > > Les > > > > *From:* Muthu Arul Mozhi Perumal <[email protected]> > *Sent:* Thursday, February 17, 2022 7:51 AM > *To:* Les Ginsberg (ginsberg) <[email protected]> > *Cc:* lsr <[email protected]> > *Subject:* Re: [Lsr] Preference among IS-IS IPv6 route types > > > > Hi Les, > > > > Thanks for your response. Please see inline.. > > > > On Thu, Feb 17, 2022 at 8:56 PM Les Ginsberg (ginsberg) < > [email protected]> wrote: > > Muthu – > > > > RFC 7775 is defining preference rules between routes of different types – > it is NOT discussing preference rules within a (set of) route types that > have the same preference. > > Ok, but RFC7775 says "Note that all types of routes listed for a given > preference are treated equally". How is that to be interpreted when there > is an L1 intra-area route of metric a and an L1 external route of metric b > for the same IPv6 prefix during comparison? > > > > Regards, > > Muthu > > > > Such a discussion is out of scope. > > > > Use of “lowest cost” is part of the well known Dijkstra Shortest Path > First (SPF) algorithm – though there are many example of constrained SPF > calculations that incorporate attributes other than cost in the choice of > “best path”. > > All of this is out of scope for RFC 7775. > > > > Les > > > > *From:* Lsr <[email protected]> *On Behalf Of *Muthu Arul Mozhi Perumal > *Sent:* Thursday, February 17, 2022 6:49 AM > *To:* lsr <[email protected]> > *Subject:* [Lsr] Preference among IS-IS IPv6 route types > > > > Hi, > > > > Need some clarification on the preference among IS-IS IPv6 route types > described in RFC7775 section 3.4 and RFC5308 section 5. > > > > RFC7775 places L1 intra-area routes and L1 external routes at the same > preference level and says that all types of routes listed for a given > preference are treated equally. There is no mention of metric. > > <snip> > > This document defines the following route preferences for IPv6 routes > advertised in TLVs 236 or 237. Note that all types of routes listed > for a given preference are treated equally. > > 1. L1 intra-area routes; L1 external routes > > 2. L2 intra-area routes; L2 external routes; L1->L2 inter-area > routes; L1-L2 external routes; L2-L2 inter-area routes > > 3. L2->L1 inter-area routes; L2->L1 external routes; L1->L1 inter- > area routes > </snip> > > > > RFC5308 however says: > > <snip> > > If multiple paths have the same best preference, then selection > occurs based on metric. > > </snip> > > > > It is not clear whether metric is to be used for selection among L1 > intra-area and external routes or is to be used for selection only with a > given route type. Can someone please clarify? > > > > Regards, > > Muthu > >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
