Maybe I am missing something, but these two look like changes to the
spec which will improve interoperability, and are easily done.
Is there a good reason not to add the clarifications that are requested
here?
Yours,
Joel
On 6/22/2011 6:32 PM, Alia Atlas wrote:
i) For instance, if an ETR receives a LISP encapsulated packet and
>> decapsulates it,
>> but does not have EID locally, what should the ETR do?
>
> Drop the packet. When decapsulation occurs, the inner header is inspected
> and what an IP router does today is what it does post decapsulation.
Another option is for the ETR to look up the EID in the mapping database and
forward it. Or the ETR could try and route it assuming the
destination IP address
is globally routable.
That the correct decision is to drop the packet is NOT specified.
There are indications
in the draft of decapsulation and reencapsulation& when those should be done is
not specified.
>> ii) Does an ETR have to do packet fragment reassembly? If an ETR
>> does not support
>> fragment reassembly, should it send an ICMP Too Big message and
>> drop the fragment?
>> What should an ETR do with a fragment directed to its RLOC?
>
> The ETR follows the IP and IPv6 specification in regards to reassemly of
> fragments. However, we try to avoid fragmentation. See section 5.4 "Dealing
> with Large Encapsulated Packets" for solutions.
Of course, I read through that section. My concern is the case where an ITR
may set the DF bit to 0.
"When the outer header encapsulation uses an IPv4 header, an
implementation SHOULD set the DF bit to 1 so ETR fragment reassembly
can be avoided. An implementation MAY set the DF bit in such headers
to 0 if it has good reason to believe there are unresolvable path MTU
issues between the sending ITR and the receiving ETR."
IF everything needs to be implemented, then an ETR has to be prepared for
an ITR to do that (adversarially if nothing else) and handle reassembly at
line-rate.
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
