Hello Les,
Thanks for taking the time to respond.
[Les:] Base specification defines partialSNPInterval (2 seconds).
Clearly w faster flooding we should look at decreasing this
timer - but we certainly should not do away with it.
That was the point I was trying to make:
You kept mentioning th
Les,
> 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
> adjacencies. Everyone gets their fair share.
>
> [If dynamic flooding is enabled, this could be based on the number of
> adjacencie
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
adjac
> 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
> your
berg) mailto:ginsb...@cisco.com>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>
Subject: Re: [Lsr] Dynamic flow control for flooding
Les,
Optimizing the throughput through a slow receiver is pretty low on my list
because the ROI is low.
Ok, I disagree. The slow receiver is the critical path to con
>Les
>
>
> From: Tony Li mailto:tony1ath...@gmail.com>> On
> Behalf Of tony...@tony.li <mailto:tony...@tony.li>
> Sent: Wednesday, July 24, 2019 12:04 PM
> To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
> Cc: lsr@ietf.org <mailto:lsr@ietf.org&
operator (so they can address the limitation)
3)Do what we can to limit the overload on the slow node/link
Hope this helps.
Les
From: Tony Li On Behalf Of tony...@tony.li
Sent: Wednesday, July 24, 2019 12:04 PM
To: Les Ginsberg (ginsberg)
Cc: lsr@ietf.org
Subject: Re: [Lsr] Dynamic flow
) [mailto:ginsb...@cisco.com]
Sent: Wednesday, July 24, 2019 14:48
To: tony...@tony.li
Cc: LITKOWSKI Stephane OBS/OINIS; 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
Henk -
Inline.
> -Original Message-
> From: Henk Smit
> Sent: Wednesday, July 24, 2019 6:18 AM
> To: Les Ginsberg (ginsberg)
> Cc: stephane.litkow...@orange.com; Tony Li ; lsr@ietf.org
> Subject: Re: [Lsr] Dynamic flow control for flooding
>
>
> Hello Les,
Les,
> Optimizing the throughput through a slow receiver is pretty low on my list
> because the ROI is low.
Ok, I disagree. The slow receiver is the critical path to convergence. Only
when the slow receiver has absorbed all changes and SPFed do we have
convergence.
> First, the rate that
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 co
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
f.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 implementations do today to handle deployments like the
> case you mention
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, 20
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 as
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 cl
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 a
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 serio
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 do
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 th
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 sug
Les,
> 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).
The only thing I would say to that is: really bad idea.
If you supersaturate the receiver, you waste transmitter in the tr
Les,
> I also think we all agree on the goal - which is to flood significantly
> faster than many implementations do today to handle deployments like the case
> you mention below.
I agree with that, but you haven’t responded to the goal that I proposed: keep
the receiver processing PDUs.
...@orange.com
Sent: Tuesday, July 23, 2019 9:50 PM
To: Les Ginsberg (ginsberg) ; Tony Li ;
lsr@ietf.org
Subject: RE: [Lsr] Dynamic flow control for flooding
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
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 1995,
Of Les Ginsberg (ginsberg)
Sent: Tuesday, July 23, 2019 16:30
To: Tony Li; lsr@ietf.org
Subject: Re: [Lsr] Dynamic flow control for flooding
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
verflow its receive queue isn't going to help
network convergence.
That's all I am saying.
Les
> -Original Message-
> From: David Lamparter
> Sent: Tuesday, July 23, 2019 2:14 PM
> To: Les Ginsberg (ginsberg)
> Cc: Tony Li ; lsr@ietf.org
> Subject: Re
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 need
ted an acerbic, terse style ;-)
>
> *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 control for flooding
>
>
>
>
>
>
>
> It is a mistake to e
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
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 probl
...@ietf.org>> On Behalf Of Tony
Li
Sent: Tuesday, July 23, 2019 6:34 AM
To: lsr@ietf.org<mailto:lsr@ietf.org>
Subject: [Lsr] Dynamic flow control for flooding
Hi all,
I’d like to continue the discussion that we left off with last night.
The use case that I posited was a situation where we h
Hi all,
I’d like to continue the discussion that we left off with last night.
The use case that I posited was a situation where we had 1000 LSPs to
flood. This is an interesting case that can happen if there was a large
network that partitioned and has now healed. All LSPs from the other side
of
39 matches
Mail list logo
