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]>]

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

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