Waman – OK – I thought you had some questions regarding how prefix-sid leaking works – but it seems that may not be the case. Your concern is about scale. I am not going to try to address such a broad topic here – other than to say this is something which has been on our collective minds for many years. Some solutions have been defined, some have been implemented/deployed, some are still waiting for a compelling deployment case, and no doubt there are other solutions yet to be defined. It is part of the journey we are on. I encourage you to listen/participate as you feel appropriate.
As regards redistribution, the need for including the prefix-sid when redistributing a route is not significantly different than the need when leaking – just having the prefix-sid of the ABR sending the redistributed advertisement is not always enough. Les From: Waman Nawathe <[email protected]> Sent: Monday, August 8, 2022 6:53 PM To: Les Ginsberg (ginsberg) <[email protected]> Cc: [email protected] Subject: Re: [Lsr] Question on RFC-8667 section 2.1.1.2 and 2.1.2 related PrefixSID Propagation and L1L2 leaks ... Hello Les, Thank you for the response .. L1L2 route leaks are fine by me but not route redistribution on non-ABR (for Prefix-SID subtlvs). Your last comment is the one that I have issues with as it will reduce the LSP space by 40% of more because of additional Prefix-SID sub-tlvs (10/18 bytes)... and I mentioned it is not needed as there is ISIS node reference associated to the route of origin which is remotely redistributed. With ABR that ISIS node association to route path is lost and that I understand and important to add Prefix-SID subTLV but NOT in flat L1 or only L2 network as it is an expensive operation i.e. 40% LSP space impact, when there is no need for it. I can get that prefix-SID from the route path association. Route Space in LSP is limited and important. Only 255 LSPs and most networks use 1500 bytes per lsp. Not all vendors support jumbo ethernet frames. So LSP space is important. thanks, -Waman ------------------------>>>>> As far as redistribution, while this is commonly configured (if at all) on ABRs, there is no restriction against doing so on any router. Clearly the inclusion of the prefix-sid for the redistributed route would have to be introduced on the router where IS-IS learns of the redistributed route. Whether that router is an ABR or not isn’t relevant. On Mon, Aug 8, 2022 at 9:11 PM Les Ginsberg (ginsberg) <[email protected]<mailto:[email protected]>> wrote: Hi Waman! Not sure I completely understand your concerns/questions, but let me make a few comments and see if that helps. The language in RFC 8667 Section 2.1.2 is to say that if the prefix which is being leaked/redistributed has a prefix-SID associated with the source advertisement (be that L1 for L1->l2 leaking or L2 for L2->L1 leaking or some other protocol in the case of redistribution) then the prefix-SID must be included in the leaked/redistributed advertisement. It is NOT suggesting that in the absence of a SID one should be introduced when leaking/redistributing. Also, please do not be confused by the referenced slides which highlight the “R” and “N” flags in the prefix-SID advertisement. At the time SR was first defined, the prefix attribute advertisement (RFC 7794) did not exist. However, we quickly realized that R/N flags have use cases beyond SR and so the prefix attributes sub-TLV was defined. The R/N flags in the prefix-SID sub-TLV have been retained to allow interoperation with early deployments of SR, but note the text in RFC 8667 Section 2.1.1.2<http://2.1.1.2>: “The Prefix Attribute Flags sub-TLV [RFC7794] also defines the N-Flag and R-Flag and with the same semantics of the equivalent flags defined in this document. Whenever the Prefix Attribute Flags sub-TLV is present for a given prefix, the values of the N-Flag and R-Flag advertised in that sub-TLV MUST be used, and the values in a corresponding Prefix-SID sub-TLV (if present) MUST be ignored. Unfortunately, the slides you reference do not emphasize this point. So there is no reason to introduce a prefix-sid advertisement simply to advertise R-bit. As far as redistribution, while this is commonly configured (if at all) on ABRs, there is no restriction against doing so on any router. Clearly the inclusion of the prefix-sid for the redistributed route would have to be introduced on the router where IS-IS learns of the redistributed route. Whether that router is an ABR or not isn’t relevant. HTH Les From: Lsr <[email protected]<mailto:[email protected]>> On Behalf Of Waman Nawathe Sent: Monday, August 8, 2022 3:57 PM To: [email protected]<mailto:[email protected]> Subject: [Lsr] Question on RFC-8667 section 2.1.1.2 and 2.1.2 related PrefixSID Propagation and L1L2 leaks ... Hello All, New to this IETF list and posting .. Regarding this section RFC-8667 2.1.1.2, It should ONLY apply to ISIS L1L2 (or ABR) router and not L1 only or L2 only and here is my reasoning .... ----------------------------------------------------------------------------------------- Reference Diagram (A): ----------------------- L1L2 (ABR) Grunt-54 (L1) -------------- (L1) Grunt-104 (L2) ------------- (L2) Grunt 106 L1 --> L2 Route Leaks or L1 <-- L2 ----------------------- Reference Diagram (B): Showing Flat L1 or Flat L2 not using any ABRs: ----------------------- Grunt-54 --- G100 --- G101 --- G103 Grunt-104 Grunt-106 ---- G200 ---- G201 ----- G201 L1 L1 L1 L1 L1L2 L2 L2 L2 L2 *NOT* Connected to L1 OR L2 Please refer to RFC-8667 Section 2.1.1.2 Page 7 and Section 2.1.2 Page 8 wrt ISIS ISIS route/prefix leaks. It mentioned 3 types: (a) L1L2 (b) L2L1 and (c) redistribution from another protocol. Cases (a) and (b) are fine wrt to my understanding ... but (c) is NOT clear. NOTE: each prefix space (tlv-135) in LSP is approx 10 bytes (prefix length based) and this Prefix-SID TLV is an additional 8 bytes. So if we do this for ALL Leaked routes then we reduce the total route capacity in LSP by 40-50% which is "not" needed really as these routes are associated with Prefix-SID from the same ISIS node. 1) I can understand if this adding of prefix-sid "sub-tlv" is is done "only" at the L1L2 (ABR). as that would maintain correct Prefix-SID association with the route accross ABR when it could have been lost. I do understand this is not for local routes ie static/connected BUT only for ospf/bgp into ISIS, no issues with that - on the L1L2 (ABR). This part is fine by me. 2) Consider reference diagram (B) where L1 or L2 are flat networks with no L1L2 (ABR) but have redistributed ospf/bgp under router isis, so why should each leaked route be EXPLICITLY associated with Prefix-SID sub-tlv when there is ISIS node based Prefix-SID association which is available for all Flat network members ? The only advantage to this is to reset Prefix-SID flags but we would reduce LSP space by 40% wrt leaked routes., which is not clear why such an expensive penalty for leaked redistributed routes. 4) I could not see ANY good examples of leaks on the web to clarify this issue. This is the ONLY reference I could see ... check Slide #14 https://www.ciscolive.com/c/dam/r/ciscolive/us/docs/2019/pdf/BRKRST-3009.pdf Side #64 https://www.segment-routing.net/tutorials/2016-09-27-segment-routing-igp-control-plane/ Comments and feedback welcome, Thanks, -Waman Nawathe Boston Area, SR Learner ------------------------------------------------------------------------------------------
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
