>BTW, there is another reason for our proposal. With the incoming
drafts about flooding-topology-reduction, there is a new problem.
>All these proposals have situations where non-flooding adjacencies
suddenly change to flooding adjacencies. When that happens, the LSDBs need to
All,
> Again, if people think that LSVR is a good idea, then how can they
> think that ISIS flooding over TCP is not a good idea ? This is
> the base idea for our proposal. A quick look at the LSVR draft
> show people from Cisco, Nokia (and Arrcus). (I'm not sure what
> Juniper or Arista or
Hi Henk,
> - We could make BFD mandatory when flooding over TCP ?
I don't think this would be a good idea.
See especially for p2p fiber links loss of light is a much faster and
better trigger/indicator that your link or adjacent router is down.
Using BFD there which in most cases operates in a
Les Ginsberg (ginsberg) wrote 2018-11-07 17:06:
The problem that RFC6213 tries to solve is a case where one of the
neighbors is thinking that the other does not support BFD. And thus
the lack of BFD is not used as an indication that something is wrong.
Right ?
[Les:] This is not correct.
Jeffrey Haas wrote 2018-11-07 20:56:
I guess my question to those who live in IGP land is how often is this
a
problem? In the case of an IGP, the backpressure means you have
databases
that are out of sync and end up with bad forwarding.
As discussed below, if you have multiple flooding
Henk,
On Wed, Nov 07, 2018 at 03:06:45PM +0100, Henk Smit wrote:
> Jeffrey Haas wrote on 2018-11-06 05:20:
>
> >I'm ambivalent of the transport, but agree that TCP shouldn't be
> >the default
> >answer.
>
> I picked TCP because every router has a working TCP implementation.
Having just done a
Henk -
Thanx for the thoughtful response.
I'll do my best to respond in kind.
Inline.
> -Original Message-
> From: Henk Smit
> Sent: Wednesday, November 07, 2018 5:26 AM
> To: Les Ginsberg (ginsberg)
> Cc: tony...@tony.li; lsr@ietf.org
> Subject: Re: [Lsr] IS-IS over
Hi Jeff,
Jeffrey Haas wrote on 2018-11-06 05:20:
I'm ambivalent of the transport, but agree that TCP shouldn't be the
default
answer.
I picked TCP because every router has a working TCP implementation.
And TCP is good enough for BGP. And thus also considered good enough
for LSVR. If
018 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.
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/
– 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
your proposal is to help other implementations which have not
> optimized their existing implementations. :-)
> Comments?
>
>Les
>
>
> > -Original Message-
> > From: Lsr On Behalf Of Henk Smit
> > Sent: Monday, November 05, 2018 8:22 PM
>
> 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
Les,
> On Nov 7, 2018, at 11:09 AM, Les Ginsberg (ginsberg)
> wrote:
>
> 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
gt; 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 IIH
On Tue, Nov 06, 2018 at 10:51:33AM +0700, tony...@tony.li wrote:
>
> Per the WG meeting, discussing on the list:
>
> This is good work and I support it.
Ditto.
> I would remind folks that TCP is NOT the only transport protocol available
> and that perhaps we should be considering QUIC while
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
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
18 matches
Mail list logo
