Stephane –
There is much we agree on.
There is something to be said for simply “flooding fast” and not worrying about
flow control at all (regardless of whether TX or RX mechanisms would be used).
Some packets would be dropped, but retransmission timers will insure that the
flooding
Hi Robert,
> Are you working on the assumption that there is no data link layer flow
> control already which could signal the OS congestion on the receiving end ?
I am assuming that there is no link layer flow control. I can’t recall working
on a system that supports X.25 since about
Hi Les,
I agree that flooding is a global thing and not a local mechanism if we
consider that the ultimate goal is to get the LSDB in-sync as fast as we can on
all the nodes.
I just want to highlight three things:
- Link delay (due to transmission link distance) is already affecting
David -
Let's take Tony's example test case.
A large network is partitioned and heals. As a result I now have 1000 LSPs
which need to be flooded.
Let's suppose on most links/nodes in the network I can support receiving of 500
LSPs/second.
But on one link/node I can only support receiving 33
I read quickly through it, very readable plain narrative explanation of the
IMO best-in-class flood reduction we've in RIFT, implemented and operating
today so I'm fwd'ing through to LSR given the lively discussions around the
topic these days there as well ... Understandably, the spec is dense
Hi Tony,
Are you working on the assumption that there is no data link layer flow
control already which could signal the OS congestion on the receiving end ?
Are we also working on the assumptions that when ISIS PDUs are send in DCs
(unknown today case when out of the sudden 1000s of LSPs may
On Tue, Jul 23, 2019 at 5:24 PM Les Ginsberg (ginsberg)
wrote:
> Tony –
>
>
>
> As usual, you cover a lot of territory – and even after a couple of
> readings I am not sure I got everything.
>
I was being accused of being too flowerly in my prose for many years so I
adopted an acerbic, terse
Tony –
As usual, you cover a lot of territory – and even after a couple of readings I
am not sure I got everything.
Still, I dare to reply.
Inline.
From: Tony Przygienda
Sent: Tuesday, July 23, 2019 1:56 PM
To: Les Ginsberg (ginsberg)
Cc: Tony Li ; lsr@ietf.org
Subject: Re: [Lsr] Dynamic flow
Reviewer: Ladislav Lhotka
Review result: Ready with Nits
I reviewed already revision 09 of this module [1]. All substantial
objections and suggestions expressed in that review are addressed in
revision 23 and I am satisfied with the result. I especially
appreciate that descriptions were
Hi Les,
On Tue, Jul 23, 2019 at 08:29:30PM +, Les Ginsberg (ginsberg) wrote:
> [...] As network-wide convergence depends upon fast propagation of LSP
> changes -
you're losing me between that previous part and the next:
> - which in turn requires consistent flooding rates on all interfaces
>
>
> It is a mistake to equate LSP flooding with a set of independent P2P
> “connections” – each of which can operate at a rate independent of the
> other.
>
>
>
>
At least my experience much disagrees with that and such a proposal seems
to steer towards slowest receiver in the whole network
Tony –
Thanx for picking up the discussion.
Thanx also for doing the math to show that bandwidth is not a concern. I think
most/all of us knew that – but it is good to put that small question behind us.
I also think we all agree on the goal - which is to flood significantly faster
than many
12 matches
Mail list logo
