Les, > But that argument doesn’t apply here.
It does. How UPA or TE link delays are needed on any other node then TE headends ? > Your comments are many years late. 😊 Well they are not late .. but got successfully ignored. And I am not saying block new innovation and close the shop. But I am questioning the way it is being done. To conclude I want to (re)state two main points: * IMO IGP should have a stable protocols for *base* topology calculation with separate LSDB and separate flooding (including flooding scopes) * Then each fancy extension is welcome to reuse parts from the base but should be independent of it and modular. Growth of one such module should have zero impact on the base protocol and other modules. Today you keep just putting stuff into one big bag. Sure it is divided into LSPs and then TLVs including sub-TLVs) encoding wise, but operationally you are just growing code base and operation of a single protocol. Rgs, R. On Fri, Nov 1, 2024 at 5:12 PM Les Ginsberg (ginsberg) <[email protected]> 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 <[email protected]> > *Sent:* Friday, November 1, 2024 8:44 AM > *To:* Les Ginsberg (ginsberg) <[email protected]> > *Cc:* Henk Smit <[email protected]>; [email protected]; Hannes Gredler < > [email protected]> > *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) <[email protected]> > 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 <[email protected]> > *Sent:* Friday, November 1, 2024 2:35 AM > *To:* Les Ginsberg (ginsberg) <[email protected]> > *Cc:* Henk Smit <[email protected]>; [email protected]; Hannes Gredler < > [email protected]> > *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) <[email protected]> > 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 <[email protected]> > *Sent:* Thursday, October 31, 2024 5:16 PM > *To:* Les Ginsberg (ginsberg) <[email protected]> > *Cc:* Henk Smit <[email protected]>; [email protected]; Hannes Gredler < > [email protected]> > *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 -- [email protected] To unsubscribe send an email to [email protected]
