Thx Les ! I asked this 2nd time as IMO direction towards growing TLV sizes is not the best solution.
Especially for opaque to routing information which applies to (tiny) subset of link state nodes in the IGP domain. See if you keep bringing larger and larger trucks folks will happily keep loading stuff (not to say junk) on them. I would very much prefer that we consider solutions like DROID (draft-li-lsr-droid) or any other pub-sub message bus for this type of information distribution instead of keep running on existing flooding. Many thx, Robert On Fri, Nov 1, 2024 at 1:28 AM Les Ginsberg (ginsberg) <ginsb...@cisco.com> wrote: > Robert – > > > > The fact that we have a 16 bit length does not mean we can actually send a > single TLV of length 65K bytes – nor do we need to do so. > > > > The protocol is still limited by whatever the lsp-mtu in the deployment is > – which is required to be <= the minimum MTU of all links in the network > enabled for IS-IS. > > > > References to RFC 5311 are in the context of needing more than 256 > LSPs/node/level – not in the context of 16 bit TLVs. > > > > Les > > > > > > *From:* Robert Raszuk <rob...@raszuk.net> > *Sent:* Thursday, October 31, 2024 5:16 PM > *To:* Les Ginsberg (ginsberg) <ginsb...@cisco.com> > *Cc:* Henk Smit <henk.i...@xs4all.nl>; lsr@ietf.org; Hannes Gredler < > han...@gredler.at> > *Subject:* Re: [Lsr] Using RFC 7356 to address TLV size limitations > > > > Dear Les, > > > > Issue #2 is the limited size of a single TLV/sub-TLV. > > This is addressed by using 16 bit type/length fields. > > > > Can you please kindly elaborate how you fit 65K octet TLV into 9K > octets of jumbo frames (max practical MTU) on a link used for flooding > between any two nodes ? > > > > RFC7356 says go and read RFC5311 on how to do that. Well can you pls point > me to a section of RFC5311 which explains how to do it? My reading of it > leads me to believe that it very well describes how to get around the 256 > LSP limit. But not how to fit an elephant into a rope bridge. > > > > Thx, > > Robert >
_______________________________________________ Lsr mailing list -- lsr@ietf.org To unsubscribe send an email to lsr-le...@ietf.org