I believe that saying "ITRs don't receiving packets." is a
linguistic step that only confuses people.
You are right, but your text wasn't clear if the packets were coming
from the site or from the core. So I assumed you were referring to the
Map-Request or Data-Probe case.
ITRs receive unencapsulated packets from the site, and encapsulate
them in LISP headers (assuming
Right, just like any router does today.
mappings are already available.) Now, one can argue that the ITR
function in the router does not "receive" packets, since it was the
router that received the packet. (One can even argue that the
router "intercepted" the packet rather than "received" it.) But
functionally it is the same thing.
I am not following you, but don't bother to explain. You are making a
subtle point about forwarding versus consuming packets? Where an ETR
would consume an encapsulated packet because its addressed to itself
and when an ITR receives packets from site hosts, that it is forwarding?
Dino
Yours,
Joel
Dino Farinacci wrote:
Given that LISP ITRs work by intercepting packets that are not
addressed to them, a host implementation would need to be able to
intercept packets "in the stack". That is going to need some
ability to modify kernel behavior.
(1) ITRs don't receive packets. They encapsulate packets.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
