Tony -
From: Tony Li On Behalf Of tony...@tony.li
Sent: Wednesday, July 24, 2019 3:37 PM
To: Les Ginsberg (ginsberg)
Cc: stephane.litkow...@orange.com; lsr@ietf.org
Subject: Re: [Lsr] Dynamic flow control for flooding
Les,
If you disagree please take things bullet-by-bullet:
* LSP
Les,
> If you disagree please take things bullet-by-bullet:
>
> LSP input queue implementations are typically interface independent FIFOs
Very true. It would not be unreasonable for an implementation to report free
space in the FIFO (in number of PDUs) divided by the number of active
> Whether a BCP draft is desired is something I am open to considering.
Process nit: what we’re talking about doing, regardless of how we do it, is
overriding 10589. As that’s a normative reference, overriding that requires
that we have a standards track document.
I don’t believe that even
Les,
> This thread reminds me of how easy it is to miscommunicate – and I bear some
> of the responsibility for that.
Communications takes two. The receiver must also be focused on the input. My
bad too.
> I don’t see anything in there about changing the PSNP signaling rate. From
>
Les,
Ok, let me reset. I’ve re-read your slides.
I don’t see anything in there about changing the PSNP signaling rate. From
your comments to Henk, I infer that you’re open to changing that rate.
As soon as you do that, you’re now providing receiver based feedback and
creating flow control.
Tony –
I have NEVER proposed that the flooding rate be determined by the slowest node.
Quite the opposite.
Flooding rate should be based on the target convergence time and should be
aggressive because most topology changes involve much fewer than 1000 LSPs
(arbitrary number). So even w a slow
Les,
Can’t we use from a transmitter point of view, the lack of ACKs from the
receiver as a signal that the transmitter should slow down ?
I agree that depending on the exact bottleneck/issue, the IS-IS stack of the
receiver may not be aware that something bad is happening and can’t provide
Henk -
Welcome to the discussion.
Inline.
> -Original Message-
> From: henk.i...@xs4all.nl
> Sent: Wednesday, July 24, 2019 5:34 AM
> To: Les Ginsberg (ginsberg)
> Cc: stephane.litkow...@orange.com; Tony Li ; lsr@ietf.org
> Subject: Re: [Lsr] Dynamic flow control for flooding
>
>
>
More inline…
From: Tony Li On Behalf Of tony...@tony.li
Sent: Tuesday, July 23, 2019 10:56 PM
To: Les Ginsberg (ginsberg)
Cc: stephane.litkow...@orange.com; lsr@ietf.org
Subject: Re: [Lsr] Dynamic flow control for flooding
Les,
There is something to be said for simply “flooding fast” and not
*[Les:] At the cost of convergence. Not a good tradeoff.*
Hi Les - why at the cost of convergence ? No one as I see it is proposing
the same rate to every peer. Quite contrary -- per peer rate of flooding.
So if you keep flooding high speed on fast links the convergence will not
be any slower
Tony –
Inline.
From: Tony Li On Behalf Of tony...@tony.li
Sent: Tuesday, July 23, 2019 10:39 PM
To: Les Ginsberg (ginsberg)
Cc: lsr@ietf.org
Subject: Re: [Lsr] Dynamic flow control for flooding
Les,
I also think we all agree on the goal - which is to flood significantly faster
than many
Robert,
> The second part of the question was really about at what layer it makes most
> sense to provide this control loop.
To me, the obvious thing to do is to make minor revisions to the protocol. We
need to:
- Add a TLV so that the receiver can provide feedback. IMHO, this should be in
Robert,
Nothing has changed about the probability of network partitioning. That was
simply a use case selected to motivate the discussion about flooding speed.
The entire discussion is almost orthogonal to dynamic flooding. Let’s please
take that out of the discussion.
Tony
> On Jul 24,
Les Ginsberg (ginsberg) schreef op 2019-07-23 22:29:
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.
Of course, if some routers are slow, convergence in parts of the network
might be slow. But
I'm under the impression the whole discussion got triggered by my rather
loose remark during the dinner based on, admittedly, my quite dated
implementation experience (with 2 disjoint distributed SPTs to reduce
flooding). I realized it seems not clearly spelled out on the thread. So to
hopefully
Hi,
Yes indeed while I was reading your richly connected node restart problem
use of overload-bit should be explored, proposed, implemented.
For the partition problem I have two general comments:
a) If network partitions is likely to happen more often in the case of
dynamic flooding perhaps as
Hello Robert,
Tony brought up the example of a partioned network.
But there are more examples.
E.g. in a network there is a router with a 1000 neighbors.
(When discussing distributed vs centralized flooding-topology
reduction algorithms, I've been told these network designs exist).
When such
Hey Henk & all,
If acks for 1000 LSPs take 16 PSNPs (max 66 per PSNP) or even as long as
Tony mentioned the full flooding as Tony said may take 33 sec - is this
really a problem ?
Remember we are not talking about protocol convergence after link flap or
node going down. We are talking about
Hello Les,
Les Ginsberg (ginsberg) wrote on 2019-07-24 07:17:
If you accept that, then it makes sense to look for the simplest way
to do flow control and that is decidedly not from the RX side. (I
expect Tony Li to disagree with that – but I have already
outlined why it is more complex to
Hello Les,
Les Ginsberg (ginsberg) schreef op 2019-07-24 07:17:
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
Hi Tony,
> 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 1995, so I don’t think
> that’s a common use case today.
>
I was more thinking along the lines of leveraging IEEE 802.3x or 802.1Qbb
standard not necessarily
21 matches
Mail list logo
