Makes sense. Thanks for the detailed explanation!
Gyan On Fri, Feb 18, 2022 at 10:51 PM Les Ginsberg (ginsberg) <[email protected]> wrote: > Gyan – > > > > As RFC 5302 and RFC 7775 clearly state, IS-IS also has “a pecking order > for route preference before the equal cost time breaker comes into play”. > > > > The differences between IS-IS and OSPF largely derive from the fact that a > single OSPF instance may include multiple areas – whereas a single IS-IS > instance only supports a single area – with the option of participating in > an L2 backbone. > > So, the set of route types available in the two protocols differ – but the > notion of route type preference first and cost second is consistent. > > > > The reason it makes sense for (as an example) an L1 intra-area route to be > treated the same as an L1 external route is because the path calculations > for the two route types are performed over the same topology. > > > > A historical note: The sharing of preference for internal/external routes > at the same level can be traced back to RFC 1195 (circa 1990). See the NOTE > in Section 3.10.2: > > > > “NOTE: Internal routes (routes to destinations announced > > in the "IP Internal Reachability Information" field), > > and external routes using internal metrics (routes to > > destinations announced in the "IP External Reachability > > Information" field, with a metric of type "internal") > > are treated identically for the purpose of the order of > > preference of routes, and the Dijkstra calculation.” > > > > RFC 5302 (circa 2000 in its original form RFC 2966) carefully maintained > this route type preference when defining preference for route types > advertised using TLVs 128 and 130. > > > > RFC 7775 owes a great deal to RFC 5302. We simply updated the rules based > on the different set of route types available when using TLVs 135/236 et al. > > > > HTH > > > > Les > > > > *From:* Gyan Mishra <[email protected]> > *Sent:* Friday, February 18, 2022 6:52 PM > *To:* Les Ginsberg (ginsberg) <[email protected]> > *Cc:* Muthu Arul Mozhi Perumal <[email protected]>; lsr <[email protected]> > *Subject:* Re: [Lsr] Preference among IS-IS IPv6 route types > > > > Les > > > > Just as a comparison and I believe that maybe what Muthu is alluding to is > that OSPF on the other hand does have a pecking order for route preference > before the equal cost time breaker comes into play. > > > > intra-area, inter-area followed by external > > > > So the result is not an ECMP with two different route types as the route > has to be the same type. > > > > With ISIS that is one of the many differences between OSPF and ISIS. > > > > I agree with your point that no loops would exist as the L1 route would be > advertised by the same or set of router(s) to get to the destination thus > no loops. > > > > So the use of either path is valid and does not result in any loops as you > stated. > > > > > > Kind Regards > > > > Gyan > > > > On Fri, Feb 18, 2022 at 9:09 AM Les Ginsberg (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.) > > > > 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. > > 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. > > > > 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 > > -- > > [image: Image removed by sender.] <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions Architect * > > *Email [email protected] <[email protected]>* > > *M 301 502-1347* > > > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email [email protected] <[email protected]>* *M 301 502-1347*
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
