This depends on the implementation. I plan to not support it this way. LISP does not require the implementation to configure static tunnel interfaces in the ITRs and ETRs but strongly recommends it for TE-ITRs and TE-ETRs.I'm not concerned about the LISP-enlightened nodes; I'm concerned for the legacy nodes that don't yet implement the scheme and I believe you may be in for some backward-compatibility issues.
The legacy nodes don't are not LISP boxes and don't have to change. To them the packets between the ITR and ETR are just plain old IPv4 or IPv6 packets.
3) Sending encapsulated packets when there is no way of knowing whether there is a suitably-configured decapsulator on the path could fail to reach some services, e.g., services that reside behind NAT boxes and have "holes" punched in the NAT that only recognize unencapsulated packets.Same issue when you don't inject your site based route into BGP.I don't understand your response; I was saying that the encapsulated packets are delivered to the NAT box in front of the server, but the NAT has a hole punched through it that only recognizes unencapsulated packets. The service will therefore be unreachable.
NAT breaks a lot of things. The ETR has to be upstream of the NAT or collocated in the NAT.
Yep, a problem with any tunneling design.Fixable with a suitable tunnel path MTU assurance mechanism.
Yes, you can do PMTU with encapsulated data packets from ITR to ETR. Dino -- to unsubscribe send a message to rrg-request@psg.com with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg