[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RRG] Initial comments on the LISP proposal



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