RE: [RRG] Initial comments on the LISP proposal

["Templin, Fred L" <Fred.L.Templin@boeing.com>]

> -----Original Message-----
> From: Dino Farinacci [mailto:dino@cisco.com] 
> Sent: Tuesday, March 20, 2007 8:31 AM
> To: Templin, Fred L
> Cc: ram@iab.org; rrg
> Subject: 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.

I'm concerned about legacy end systems; not legacy network middle boxes.
 
> >>> 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.

The point is that LISP may interact in strange ways with the
legacy deployment. If a working serice is set up behind a NAT
today (with a hole punched through the NAT), then that same
service should still work tomorrow after LISP gets deployed.
 
> >> 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.

Need to be careful with this; the ITR can certainly receive an
ICMPv4 "fragmentation needed" from some middlebox within the
tunnel. But, it is only guaranteed to get back the first 8
octets of the encapsulated packet so translation for sending
an ICMP back to the original destination is infeasible. The
only safe way I know of for the tunnel to support an assured
MTU (while avoiding unecessary in-the-network fragmentation)
is for the ITR to be able to probe the path and get an
acknowledgement back from the ETR.

Fred
fred.l.templin@boeing.com
 
> 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