> It is required because we have a need for more than 255 bytes of data directly used by the protocol.
Seems pretty clear that we have differences of opinion in classification of stuff which went into the protocol in the recent decade to be really needed by routing or perhaps used by various optional optimisations on top of base topology. For example - numerous extensions for TE use purposes (and the list is growing ...) - are those really something which should be flooded to each node domain wide just because flooding is already there so let's use it ? Should elements used for computation of constrained paths be part of base routing protocol ? Same for building constrained topologies ... Each such atomic extension looks small and innocent, but when you have to pack all of them together things get oversized. On Fri, Nov 1, 2024 at 4:12 PM Les Ginsberg (ginsberg) <ginsb...@cisco.com> wrote: > Robert – > > > > The need for more than 255 bytes/TLV in this case has nothing to do with > “non-routing-protocol-data”. It is required because we have a need for more > than 255 bytes of data directly used by the protocol. > > > > Please do not conflate this with issues related to requests for the IGPs > to carry data not used by the protocol itself. > > > > Les > > > > *From:* Robert Raszuk <rob...@raszuk.net> > *Sent:* Friday, November 1, 2024 2:35 AM > *To:* Les Ginsberg (ginsberg) <ginsb...@cisco.com> > *Cc:* Henk Smit <henk.i...@xs4all.nl>; lsr@ietf.org; Hannes Gredler < > han...@gredler.at> > *Subject:* [Lsr] Re: Using RFC 7356 to address TLV size limitations > > > > 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
