Re: [Lsr] Methods to label the passive interfaces within ISIS

[[e-mail]]

Hi Aijun,


> For the link attributes that defined in RFC5029, as that stated in https://tools.ietf.org/html/rfc5029#section-2 <https://tools.ietf.org/html/rfc5029#section-2>, this sub-TLV is included in the TLV 22(Extended IS Reachability). 
> As I read the IANA code point https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-22-23-25-141-222-223 <https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-22-23-25-141-222-223>, it notes this sub-TLV can be included in all of these TLVs (22,23,25,141,222,223). 
>  
> But, when the interface is configured as passive/stub, it seems that the above TLVs will not be advertised, because there is no IS neighbor on this passive link.  


Fair point. Given that there is an IP address and prefix on that link, it would be very reasonable to advertise the Extended IP Reachability TLV (135). We would then need to make the link attributes sub-TLV applicable to this TLV (and it’s MT brother).


> TLV 141 “Inter-AS reachability information” seems be one appropriate TLV to include this sub-TLV, but it requires the IS-IS TE deployment, and is not suitable for describing the passive/stub link on edge router.
>  
> In summary, it seems put this attribute into the “Prefix Attribute Flags” sub-TLV which can be included in TLV 135,235,236 and 237 (Extended IP reachability, MT IP. Reach, IPv6 IP. Reach, and MT IPv6 IP. Reach TLVs) is more applicable?


It would seem to me that what you’re describing is an attribute of a link, not of a prefix, thus I would favor it remaining a link attribute.

But that’s just me.  :-)

Tony