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
