Hi Les, I am very well aware about different scopes of both drafts. Actually I read them all.
But just wanted to make sure your point about ISIS working fine today with 1000s node networks is really a prove that flooding optimisation is still *practically* needed/required. Btw ... Henk has a second proposal - a companion document to flooding over TCP on flooding reduction too. Perhaps you missed it :) https://datatracker.ietf.org/doc/draft-hsmit-lsr-isis-dnfm/ Thx, R. On Wed, Nov 7, 2018 at 9:54 AM Les Ginsberg (ginsberg) <[email protected]> wrote: > Robert – > > > > The comment being discussed here is in regards to the potential benefits > of altering IS-IS to use a different way of flooding over an interface. > > Whether we agree/disagree on this does not have any bearing on the high > amount of redundant flooding which occurs in a highly meshed network – > which I think all of us agree is a problem worth addressing. > > > > The latter is addressed in a number of drafts – including Henk/Gunter’s > https://datatracker.ietf.org/doc/draft-hsmit-lsr-isis-dnfm/ . > > > > But this thread is about > https://datatracker.ietf.org/doc/draft-hsmit-lsr-isis-flooding-over-tcp/ .. > > > > Please do not confuse the two. > > > > Les > > > > > > *From:* Robert Raszuk <[email protected]> > *Sent:* Wednesday, November 07, 2018 12:39 AM > *To:* Les Ginsberg (ginsberg) <[email protected]> > *Cc:* [email protected]; Tony Li <[email protected]>; [email protected] > *Subject:* Re: [Lsr] IS-IS over TCP > > > > Hi Les, > > > > > 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. > > > > While I completely agree with your above observation (and as a matter of > fact first person to tell me that was actually Henk around year 2000) may I > ask what problem are we solving with vast majority of the proposals in > space of "IGP scaling" for data center deployments currently on the table ? > Are we perfecting the perfect ? > > > > It sounds that what is really needed is a deployment guide (perhaps in the > form of informational RFC) documenting that use of ISIS in 1000(s) node DC > cluster is fine provided features X, Y, Z are enabled. > > > > Otherwise folks out there in the field no matter what is done here will > keep using BGP for huge 50 node DC clusters because RFC7938 says so. > > > > Cheers, > Robert. > > > > > > On Wed, Nov 7, 2018 at 5:09 AM Les Ginsberg (ginsberg) <[email protected]> > wrote: > > Henk/Gunter - > > Couple of points. > > 1)IS-IS PDUs are sent directly over layer 2 - whereas TCP (or other > transport) are sent over Layer3. > This means we have a potential fate sharing issue where IIHs (which > continue to be sent over Layer 2 in your proposal (as I understand it) may > be successfully exchanged but the transport session set up to send > LSPs/SNPs may fail. This is the exact issue RFC 6213 has addressed. > > What should happen if IIHs are being successfully exchanged, the neighbors > both indicate support for the extension, but the transport session fails to > come up or goes down? > Would you follow similar behavior to RFC 6213 i.e., bring the adjacency > down? If so, how would you determine when you can bring the adjacency up? > > I appreciate you have indicated this as TBD in Section 7.6 of the draft, > but you also say in Section 7.5 that adjacency should NOT go down when > transport session fails - which implies we can have an ongoing condition > where an adjacency is up but > flooding cannot be done- which is a pathological condition. > > 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). > > My point here is that there are existing implementations which would get > no benefit from your proposal. It might be argued that someone writing a > new implementation may find it simpler to make use of a transport mechanism > like TCP - but I do not think there is compelling data that demonstrates > that the scalability of an implementation using your proposal is better > than that of many existing implementations. > > This then suggests that for existing implementations the main motivation > to support your proposal is to help other implementations which have not > optimized their existing implementations. :-) > Comments? > > Les > > > > -----Original Message----- > > From: Lsr <[email protected]> On Behalf Of Henk Smit > > Sent: Monday, November 05, 2018 8:22 PM > > To: [email protected] > > Cc: [email protected] > > Subject: Re: [Lsr] IS-IS over TCP > > > > > > Thanks, Tony. > > > > We picked TCP because every router on the planet already has a TCP stack > > in it. > > That made it the obvious choice. > > > > Our draft described a TVL in the IIHs to indicate a router's > > ability to use TCP for flooding. > > That TLV has several sub-TVLs. > > 1) the TCP port-number > > 2) an IPv4 address > > 3) and/or an IPv6 address > > > > We can change the first sub-TVL so that it indicates: > > 1) 1 or 2 bytes indicating what protocol to use > > 2) the remainder of the sub-TLV is an indicator what port-number > > or other identifier to use to connect over that protocol. > > > > This way we can start improving IS-IS with TCP today. > > And add/replace it with other protocols in the future. > > > > henk. > > > > > > > > [email protected] schreef op 2018-11-06 04:51: > > > Per the WG meeting, discussing on the list: > > > > > > This is good work and I support it. > > > > > > I would remind folks that TCP is NOT the only transport protocol > > > available and that perhaps we should be considering QUIC while we’re > > > at it. In particular, flooding is a (relatively) low bandwidth > > > operation in the modern network and we could avoid slow-start issues > > > by using QUIC. > > > > > > Tony > > > > > > _______________________________________________ > > > Lsr mailing list > > > [email protected] > > > https://www.ietf.org/mailman/listinfo/lsr > > > > _______________________________________________ > > Lsr mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/lsr > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr > >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
