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: “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]> On Behalf Of Waman Nawathe Sent: Monday, August 8, 2022 3:57 PM To: [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
