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) <ginsb...@cisco.com> 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 <lsr-boun...@ietf.org> On Behalf Of Henk Smit > > Sent: Monday, November 05, 2018 8:22 PM > > To: tony...@tony.li > > Cc: lsr@ietf.org > > 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. > > > > > > > > tony...@tony.li 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 > > > Lsr@ietf.org > > > https://www.ietf.org/mailman/listinfo/lsr > > > > _______________________________________________ > > Lsr mailing list > > Lsr@ietf.org > > https://www.ietf.org/mailman/listinfo/lsr > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr >
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
