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) wrote: > Muthu – > > > > Use of Equal Cost Multipath (ECMP) is commonplace. > > > >Les > > > > *From:* Muthu Arul Mozhi Perumal > *Sent:* Thursday, February 17, 2022 7:51 AM > *To:* Les Ginsberg (ginsberg) > *Cc:* lsr > *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) < > ginsb...@cisco.com> 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 *On Behalf Of *Muthu Arul Mozhi Perumal > *Sent:* Thursday, February 17, 2022 6:49 AM > *To:* lsr > *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. > > > >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 > > > > > RFC5308 however says: > > > >If multiple paths have the same best preference, then selection >occurs based on metric. > > > > > > 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 Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Adoption Question Stub-Link vs RFC5316
Chris, the draft attempt to use the local subnet information for identifying two endpoints of the same link. That seems wrong in itself. In addition: 1) We have link local/remote IDs (and IP addresses) to pair the two endpoints of the link in both OSPF and ISIS. We do not need another mechanism for the same. 2) What is proposed does not work for unnumbered links. thanks, Peter On 18/02/2022 05:45, Christian Hopps wrote: [As WG Chair] Hi LSR-WG, As my co-chair has joined the draft as a co-author making the call on whether we have rough consensus to adopt draft-wang-lsr-stub-link-attributes-02 now falls to me alone. I've reread the numerous emails on this adoption call and I see some support, and a few objections, and most of the objections are not that there is no problem to solve here, but they think this draft isn't the right way to do it and a revision of RFC5316 could be done instead. "A bird in the hand is worth two in the bush" While it might be nice that there is another way to accomplish things by re-using an existing TLV, that work has not been done, whereas we have a written draft in front of us -- that has now been beaten up and reviewed a good deal -- that does seem to provide a solution to an actual problem. So I'd like to give the WG a final chance to comment here, is there a strongly compelling reason to reject the work that is done here. Examples of "strongly compelling" would be something like "This will break the (IS-IS) decision process" or "this will badly affect scaling" or "this will significantly complicate a protocol implementation", but not "this can be done differently" as the latter is work not done (i.e., it's two birds "in the bush") I am *not* looking to rehash the entire discussion we've already had so please restrict your replies to the above question only. Thanks, Chris. [As WG Chair] ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Adoption Question Stub-Link vs RFC5316
[As WG Chair] Hi LSR-WG, As my co-chair has joined the draft as a co-author making the call on whether we have rough consensus to adopt draft-wang-lsr-stub-link-attributes-02 now falls to me alone. I've reread the numerous emails on this adoption call and I see some support, and a few objections, and most of the objections are not that there is no problem to solve here, but they think this draft isn't the right way to do it and a revision of RFC5316 could be done instead. "A bird in the hand is worth two in the bush" While it might be nice that there is another way to accomplish things by re-using an existing TLV, that work has not been done, whereas we have a written draft in front of us -- that has now been beaten up and reviewed a good deal -- that does seem to provide a solution to an actual problem. So I'd like to give the WG a final chance to comment here, is there a strongly compelling reason to reject the work that is done here. Examples of "strongly compelling" would be something like "This will break the (IS-IS) decision process" or "this will badly affect scaling" or "this will significantly complicate a protocol implementation", but not "this can be done differently" as the latter is work not done (i.e., it's two birds "in the bush") I am *not* looking to rehash the entire discussion we've already had so please restrict your replies to the above question only. Thanks, Chris. [As WG Chair] ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Preference among IS-IS IPv6 route types
Muthu – Use of Equal Cost Multipath (ECMP) is commonplace. Les From: Muthu Arul Mozhi Perumal Sent: Thursday, February 17, 2022 7:51 AM To: Les Ginsberg (ginsberg) Cc: lsr 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) mailto:ginsb...@cisco.com>> 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 mailto:lsr-boun...@ietf.org>> On Behalf Of Muthu Arul Mozhi Perumal Sent: Thursday, February 17, 2022 6:49 AM To: lsr mailto:lsr@ietf.org>> 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. 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 RFC5308 however says: If multiple paths have the same best preference, then selection occurs based on metric. 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 Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
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) 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 *On Behalf Of * Muthu Arul Mozhi > Perumal > *Sent:* Thursday, February 17, 2022 6:49 AM > *To:* lsr > *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. > > > >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 > > > > > RFC5308 however says: > > > >If multiple paths have the same best preference, then selection >occurs based on metric. > > > > > > 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 Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Preference among IS-IS IPv6 route types
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. 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 On Behalf Of Muthu Arul Mozhi Perumal Sent: Thursday, February 17, 2022 6:49 AM To: lsr 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. 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 RFC5308 however says: If multiple paths have the same best preference, then selection occurs based on metric. 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 Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[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. 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 RFC5308 however says: If multiple paths have the same best preference, then selection occurs based on metric. 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 Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
