[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Provider Selection and Mapping Updates (Re: [RAM] Re: the separation of ID/RLOC)
On 10-jul-2007, at 17:44, Eliot Lear wrote:
The key point is that the processing of these keepalives are done,
at least in LISP, solely by ITRs and ETRs, and not by the global
routing system or by end hosts. So this means that there is
potential aggregation of keepalives with no impact on the core,
other than what is likely to be a modest amount of traffic.
Yes, that helps a lot. However, I still feel the need to be the voice
of restraint in the face of additional overhead...
But I've only really just thought a little about this issue. Does
anyone have a few good references to work in this space?
Please have a look at:
http://www.ietf.org/internet-drafts/draft-ietf-shim6-failure-
detection-08.txt
The idea here is that both the situation where there is traffic in
each direction and the situation where there is no traffic are an
indication that there is no problem, so we don't need to do anything
here, and no keepalives are sent. Only when we send but not receive
there must be a problem, and if we receive but don't send the other
side is going to think there's a problem so we send keepalives.
If you add some special case logic for common things such as TCP ACKs
and TCP session termination, there's hardly ever any need to send
keepalives. Only when active/quiet transitions can't be detected or
in the unusual case that there is only traffic in one direction will
there be keepalives.
Obviously this takes a bit more logic to implement than simply fire
off a keepalive every few seconds. For shim6, it's important to do
this right because you can get keepalive explosions if something goes
down if you're not careful.
For the ETR/ITR case I would at least want to avoid keepaliving when
there is no traffic between an ETR and an ITR.
_______________________________________________
RAM mailing list
RAM at iab.org
https://www1.ietf.org/mailman/listinfo/ram