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]> 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: > > > > *“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
