> > 2)Your statements regarding existing flooding limitations of IS-IS are > rather dated. Many years ago implementations varied from the base > specification by allowing much faster flooding and contiguous flooding > bursts on an interface in support of fast convergence. There are existing > and successful deployments of an instance with thousands of neighbors and > thousands of nodes in a network and sub-second convergence is supported. So > the statement that the existing protocol per interface flooding is a > blocking factor in highly meshed topologies is not (IMO) accurate. The more > accurate characterization of the flooding problem in dense topologies is > the amount of redundant flooding (i.e., a node may receive many copies of a > new LSP) - which your proposal does nothing to address (I understand it was > not intended to address this problem which you discuss in a different > draft). > > unsurprisingly +1 here ...
Further, if you start to go that path (i.e. max. flooding transport speed which contrary to Les I think does have value but not necessarily for ISIS) and you _really_ care about max. flooding speed you end up most likely in _go over UDP_ route as people like bitttorent or QUIC guys went. There is a good reason behind that ;-) Moreover, if you form adjacencies that way you'll find that MT/MI problems are fairly trivial to resolve. Problem being though taht the 'well-known port', 'well-known-protocol', 'well-known-ethertype' allowing for policing of the protocol vanishes and you have to be smarter ... two old hands' gave you two cents ;-) --- tony
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
