Re: [Lsr] IS-IS over TCP

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) <ginsberg@cisco.com>
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 <robert@raszuk.net>
> *Sent:* Wednesday, November 07, 2018 12:39 AM
> *To:* Les Ginsberg (ginsberg) <ginsberg@cisco.com>
> *Cc:* hhwsmit@xs4all.nl; Tony Li <tony.li@tony.li>; lsr@ietf.org
> *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) <ginsberg@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-bounces@ietf.org> On Behalf Of Henk Smit
> > Sent: Monday, November 05, 2018 8:22 PM
> > To: tony.li@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.li@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
>
>