Subject: Re: [lisp] draft-ietf-lisp-interworking-01

From: "Flinck, Hannu (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 18 May 2010 17:14:49 +0300

Hello Darrel and others

I haven't seen much comments or discussion about the interworking draft.
Obviously much has changed since March 11 in the base line LISP (new
canonical address format useful for the interworking, changes in the
control plane message content etc.). All of those are of course not
reflected in version-01 of the interworking draft.

Still, I have some basic questions about how the LISP interworking is
intended to work. I believe getting interworking clear and functional
would help a lot the base line LISP protocol as well. 

It is said in the interworking draft v01 that:

In Section 5.1 "PITR EID announcements" that 
 "A key part of PITR functionality is to advertise routes for
highly-aggregated EID prefixes into part of the global routing system."

Then, on the other hand, for case 3 "LISP site to non-LISP site"
interworking (page 5), the LISP site needs to know when not to
encapsulate packets. This can be achieved by one of the two mechanisms:

- checking if the destination of an IP packet is found to match a prefix
from BGP routing table, then the site is reachable by the BGP core

- if the destination address is not found in the mapping database.

But isn't PITR announcing the aggregated EID to the BGP system as per
section 5.1? Meaning that the first test will always pass, there will be
a match in the BGP routing table? Or is there something hidden behind
the "parts of global routing system" wording, something like to the
direction that aggregated EIDs MUST not be announced to LISP sites? If
so, this should be said more clearly, ... And BGP community attribute
defined...

With the same logic, isn't it so that the LISP-R site will only use LISP
tunneling only when communicating with LISP-NR? So all other cases LISP
is not used at all. Only the BGP prefix check is done that indicates not
to use LISP (and possibly the mapping database check is needed)? This is
because the prefix is there in the BGP system and thefore routable. Or
if this is not the desired behavior as I think it is not, then both of
the above tests (BGP prefix and the mapping system) need to be executed?
Not either or?

LISP-NAT

LISP-NAT is stated to enable the interworking of non-LISP sites and
LISP-NR sites by ensuring that the LISP-NR's site address are always
routable. "inner" LISP-NR EID is translated to "outer" LISP-R value.

I do not understand why would an ITR that performs the NATing
LISP-encapsulate the packet to non-LISP site after the address
translation. Both the source and destination are after address
translation routable addresses, so why not just send the packet? And in
fact as you can see encapsulating a packet with globally routable
addresses is contradicting case 3 behavior as per section 2. The case
for Proxy-egress tunnel router doesn't happen as the source address was
translated to be routable in the LISP NAT.   

Any clarification appreciated.  

Best regards
Hannu  

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of ext Darrel Lewis
>Sent: Thursday, March 11, 2010 02:54
>To: [email-masked]
>Subject: [lisp] draft-ietf-lisp-interworking-01
>
>All,
>
>
>I have (finally) finished incorporating all the comments that 
>I received, both on the list and privately, for the 
>draft-ietf-lisp-interworking-01 submission posted to the list 
>a few weeks ago.  Thanks for all the great comments!
>
>While I can't post this to the directory until 3/22, I figured 
>I'd send the text to the list now in case someone had comments 
>before or during the upcoming WG meeting.
>
>Text of the draft  and html diff from -00 attached.
>
>Thanks.
>
>-Darrel  (on behalf of the other interworking authors: Dino, 
>Dave, and Vince)
>
>