Re: [Lsr] Question on RFC-8667 section 2.1.1.2 and 2.1.2 related PrefixSID Propagation and L1L2 leaks ...

["Les Ginsberg (ginsberg)" <[e-mail]>]

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 <[e-mail]>
Sent: Monday, August 8, 2022 6:53 PM
To: Les Ginsberg (ginsberg) <[e-mail]>
Cc: [e-mail]
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) <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> On Behalf Of Waman Nawathe
Sent: Monday, August 8, 2022 3:57 PM
To: [e-mail]<mailto:[e-mail]>
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

------------------------------------------------------------------------------------------