well, e'thing can be improved. I found what I suggesed since Les asked
works well enough ... As they say, your mileage may vary
whatever you suggest as absolute value in MaxLPSTx will not hold up the
test of time, 10/sec was a great value in 80s ...
--- tony
On Tue, Mar 10, 2020 at 3:39 PM
Chris/Acee -
I strongly agree with Peter.
There is no point in creating a protocol specific registry for behavior values
which are protocol agnostic.
This only adds duplication (which is NOT the same as redundancy ).
What I find unfortunate is that the table in Section 10 of
> On Mar 10, 2020, at 11:22 AM, Tony Przygienda wrote:
>
> Hey Christian, MaxTX is not that hard to derive since it's basically limited
> by the local system and its CPU/prioritization/queing architecture.
Well so the value is "Fast as you can?" then? It's a specific value "MaxLSPTx"
in
On Tue, Mar 10, 2020 at 9:43 AM wrote:
> With regards to punting to TCP, I think that TCP (stacks) enforce packet
> ordering.
>
> i.e. if you receive packets 1, 3,4, …,N, then you can only use packet 1
> until you receive packet 2. In the meantime, you cannot use the (N-2)
> packets that you did
With regards to punting to TCP, I think that TCP (stacks) enforce packet
ordering.
i.e. if you receive packets 1, 3,4, …,N, then you can only use packet 1 until
you receive packet 2. In the meantime, you cannot use the (N-2) packets that
you did received.
That seems like a regression for IS-IS
Hey Christian, MaxTX is not that hard to derive since it's basically
limited by the local system and its CPU/prioritization/queing architecture.
For the rest of your email, in short, you have my observations in the
previous email what I think is useful and can be done ... BTW, timestamps
are
Les Ginsberg (ginsberg) writes:
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.
Peter Psenak writes:
Hi Acee,
On 09/03/2020 14:49, Acee Lindem (acee) wrote:
Hi Peter, Chris,
I agree that a number of IS-IS IANA registries have this level of
specification. For example:
Chris,
On 09/03/2020 13:26, Christian Hopps wrote:
On Mar 9, 2020, at 6:36 AM, Peter Psenak
wrote:
Hi Chris,
On 07/03/2020 15:46, Christian Hopps wrote:
1) I think we should have an IANA registry instead of just a table defined in
section 10 of draft-ietf-lsr-isis-srv6-extensions-06.
Hi Acee,
On 09/03/2020 14:49, Acee Lindem (acee) wrote:
Hi Peter, Chris,
I agree that a number of IS-IS IANA registries have this level of
specification. For example:
https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-22-23-25-141-222-223
Dear Les,
Thanks a lot for your comments. I will take your suggestion to add description
on how to use the IFIT Capability information when the submission is opened.
As described in my reply to Acee, following is my quick reply:
IFIT is deployed in a specific domain referred as the IFIT
Dear Acee,
Thanks a lot for your comments. I have revised the title of drafts and will
take your suggestion to add more text on how to use the IFIT Capability
information, once the submission is opened. Here is my quick reply:
IFIT is deployed in a specific domain referred as the IFIT domain.
12 matches
Mail list logo