Hi Les, I've understood now, so wouldn't bother :) But I like the text in RF5302 that says: "are treated identically for the purpose of the order of preference of routes, and the Dijkstra calculation"
That sounds better than "are treated equally" for someone new to IS-IS like me :) Regards, Muthu On Tue, Feb 22, 2022 at 1:45 PM Les Ginsberg (ginsberg) <[email protected]> wrote: > Muthu – > > > > I am glad we are in sync. > > > > As to your suggested additional text. RFC 7775 (like its predecessor RFC > 5302) is not specifying what “SPF” algorithm is being applied nor how it is > calculated. It is only specifying the route type preference that MUST be > used independent of the type of SPF. > > In that regard, the statement > > > > “Note that all types of routes listed for a given preference are treated > equally.” > > > > is stating exactly what is in scope for the RFC. > > > > So I do not think your suggested additional text should be added to RFC > 7775. > > > > Les > > > > > > *From:* Muthu Arul Mozhi Perumal <[email protected]> > *Sent:* Monday, February 21, 2022 10:16 PM > *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 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
