And given that there are multiple LSPs per node, the IS-IS MTU limit is only for a single top-level TLV. Should this become a problem, we already have some experience with TLV/sub-TLV concatenation 😉
> On Nov 1, 2024, at 12:12 PM, Les Ginsberg (ginsberg) > <ginsberg=40cisco....@dmarc.ietf.org> wrote: > > Robert – > Your comments are many years late. 😊 > Things like TE, Segment Routing, flex-algo were incorporated into the > protocol years ago. > Critiquing the transport because it is being extended to meet the requirement > of functionalities that have been standardized is not sensible. > If you want to argue these functionalities should be removed from the > protocol – well, that’s at least a logical approach – though I don’t think > the WG or the industry is interested in such a change. > One of the legitimate criticisms of having the IGP carry information not > used by the protocol itself is that it is present on all nodes when it only > needs to be used for a subset of the nodes. > But that argument doesn’t apply here. > Les > From: Robert Raszuk <rob...@raszuk.net> > Sent: Friday, November 1, 2024 8:44 AM > 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] Re: Using RFC 7356 to address TLV size limitations > > 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 _______________________________________________ Lsr mailing list -- lsr@ietf.org To unsubscribe send an email to lsr-le...@ietf.org
