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 that your "tx based flow control" only needed
changes to the internal implementation of the LSP-sender.
That's not the case. Your algorithm also depends on behaviour
of the LSP-receiver. I did not see that mentioned anywhere before.
Good to see that you (and Tony) now acknowledge this necessity.
I hope you also realize (and agree) that changing the algorithm
to send PSNPs on the LSP-receiver, in a way to improve the
flow-control algorithm for the LSP-sender, will probably have a
negative impact on the current efficiency of bundling acks in
PSNPs. And that change can multiply the number of PSNPs (and thus
ISIS PDUs in input queues) that need to be received on routers.
If you don’t like the name we can certainly find something more
appealing.
I don't care much about the name.
(In general I do care about naming in programming. And even 10x more
about
naming in protocol documents. But that's not important in the discussion
at the moment).
The point I was trying to get across is that your proposal is not
something that happens internally on a single individual router. It is
an algorithm that involves 2 routers. And thus it is a protocol issue.
What I am proposing does not require protocol extensions -
therefore no draft is required.
Protocols do no only describe octets on the wire. They also describe
behaviour. Thus, as Tony has already said, your proposed algorithm
also need to be documented. In an RFC probably.
Whether a BCP draft is desired is something I am open to considering.
I don't know much about process in the IETF. But I was always under
the assumptions that BCPs were mostly network design/configuration
recommendations for network operators.
From an earlier email:
[Les:] I think you know what I am about to say.. :)
Yes, my question of why use exponential backoffs was a rethorical
question (as I wrote at the end of my email).
I wrote:
I hope it is clear to everyone that these are not serious questions.
I'm
just saying: "sometimes fast is slow".
FYI, few people probably know this, but I happen to be the guy that
intially came up with the idea of exponential backoffs in IGPs.
(Back in 1999 when I was at cisco).
Anyway, to reiterate my point: "sometimes fast is slow". It seems we
now all agree that sending LSPs "rapidly" and then assuming
retransmissions
will fix any problems, is an approach that is way too naive. Good.
henk.
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
