My sense of humor to be excused, Les 😗😁
Yes, so here's suggestion taht will build a better sloped hysteresis that
will allow you to ramp up slower first to not oscillate and also ramp down
somewhat more graciously. It's a sketch, more interesting metrics can be
taken into it further but that's the
Tony –
If you have a suggestion for Tx back-off algorithm please feel free to share.
The proposal in the draft is just a suggestion.
As this is a local matter there is no interoperability issue, but certainly
documenting a better algorithm is worthwhile.
Les (claws in check 😊 )
From: Tony P
Tony -
With respect, it is hard to know what you are proposing since there has never
been a public description.
The draft on which you are a co-author does not discuss any sort of algorithm
to dynamically alter the advertised value based on current router state. In
fact it argues (or at least
> easy to say with a single PD. If you have 20, each with a different
> architecture, it becomes a different problem.
My employer has multiple PD implementations. I sympathize, but it’s still
necessary.
Tony
___
Lsr mailing list
Lsr@ietf.org
https
Tony,
On 19/02/2020 20:25, tony...@tony.li wrote:
Peter,
I'm not scared of polynomial evaluation, but the fact that my IGP
implementation is dependent on the PD specifics, which are not
generally available and need to be custom built for each PD
specifically. I always thought a good IGP imp
Les,
> As you need to send signaling based upon dynamic receiver state and this
> signaling is contained in unreliable PDUs (hellos) and to be useful this
> signaling needs to be sent ASAP - you cannot wait until the next periodic
> hello interval (default 10 seconds) to expire. So you are go
Peter,
> I'm not scared of polynomial evaluation, but the fact that my IGP
> implementation is dependent on the PD specifics, which are not generally
> available and need to be custom built for each PD specifically. I always
> thought a good IGP implementation is PD agnostic.
Your implementa
Having worked for last couple of years on implementation of flooding speeds
that converge LSDBs some order of magnitudes above today's speeds ;-)
here's a bunch of observations
1. TX side is easy and useful. My observation having gone quickly over the
-ginsberg- draft is that you really want a be
Robert –
Sure – we can add some text in this area.
Implementations which don’t do well at current flooding speeds clearly won’t do
well at faster flooding speeds unless they are enhanced. And such
implementations won’t do well at scale even w/o faster flooding.
As always with these kinds of imp
Hi Les,
Yes this "small delay" of ACK aggregation is something which I am a bit
worried here from SNPs sender side.
Now as indeed draft mentioned prioritizing SNPs on reception let me
indicate that some platforms I have not so long ago dealt with do not even
prioritize any IGP packet over other p
Tony -
Peter has a done a great job of highlighting that "single queue" is an
oversimplification - I have nothing to add to that discussion.
I would like to point out another aspect of the Rx based solution.
As you need to send signaling based upon dynamic receiver state and this
signaling is
Robert –
Thanx for your input.
Note that one of the suggestions in
https://datatracker.ietf.org/doc/draft-ginsberg-lsr-isis-flooding-scale/ is to
prioritize the reception of SNPs over LSPs so that we are less likely to drop
ACKs.
It is not clear to me why you think SNP generation would be an
Tony,
On 19/02/2020 11:37, Tony Li wrote:
Peter,
I'm aware of the PD layer and that is not the issue. The problem is that there
is no common value to report across different PD layers, as each architecture
may have different number of queues involved, etc. Trying to find a common
value to r
Peter,
> I'm aware of the PD layer and that is not the issue. The problem is that
> there is no common value to report across different PD layers, as each
> architecture may have different number of queues involved, etc. Trying to
> find a common value to report to IPGs across various PDs woul
Tony,
On 19/02/2020 10:47, Tony Li wrote:
Peter,
Given many different hardware architectures one may run a single IGP
implementation on, this becomes impractical and complex as each hardware
architecture has its own specifics. One would rather keep the IGP
implementation hardware agnostic,
Peter,
> Given many different hardware architectures one may run a single IGP
> implementation on, this becomes impractical and complex as each hardware
> architecture has its own specifics. One would rather keep the IGP
> implementation hardware agnostic, rather than providing hardware speci
Tony,
On 19/02/2020 10:30, Tony Li wrote:
Peter,
above is nowhere close to what the reality is, especially in the distributed
system. In such system, packets traverses via multiple queues on both LC and RP
and application like IGP has no visibility to these queues.
As you may recall, I w
Peter,
> above is nowhere close to what the reality is, especially in the distributed
> system. In such system, packets traverses via multiple queues on both LC and
> RP and application like IGP has no visibility to these queues.
As you may recall, I was lead software architect for NCS 6000.
Hi Les & all,
Watching this discussion I would like to state that IMO going with
transmitter based rate limiting (I would not call it flow control) is much
easier option to deploy and operate. It also has no dependency across other
side of p2p adj which is a very important factor. The only issue h
Tony,
On 19/02/2020 08:52, tony...@tony.li wrote:
Les,
Overall, I think you are making general statements and not providing
needed specifics.
I’m sorry it’s not specific enough for you. I’m not sure that I can
help to your satisfaction.
Maybe it’s obvious to you how a receiver based
20 matches
Mail list logo
