Subject: [lisp] LISP Interworking: Proxy Egress Tunnel Routers

From: "Darrel Lewis (darlewis)" <[email-masked]>
Date: Fri, 8 Jan 2010 15:37:12 -0800

LISPers,

The WG chairs have asked me reopen discussion on Proxy Egress Tunnel
Routers.  We have discussed them on the WG list, and they were also
talked about during the presentation around "LISP Deployment" by
Margaret and Myself.

To review, a Proxy Egress Tunnel Router is a LISP Network Element that
would decapsulate traffic destined to non-LISP sites on behalf of a
given LISP site.  Proxy Egress Tunnel Routers are not directly related
to Proxy Ingress Tunnel Routers.  Instead, they allow an particular ITR
to encapsulate packets it normally would forward un-encapsulated.  These
packets would normally be forwarded by the ITR un-encapsulated.

   There are two primary reasons why sites would want to utilize a PETR:

   Avoiding strict uRPF failures:  Some provider's access networks
      require the source of the packets emitted to be within the
      addressing scope of the access networks.

   Traversing a different IP Protocol:  A LISP site may want to transmit
      packets to a non-LISP site where the some of the intermediate
      network does not support an IP protocol (v4 or v6).  PETRs can
      allow this LISP site's data to 'hop over' this by utilizing LISP's
      support for mixed protocol encapsulation.

Are there any objections to including text for Proxy Egress Tunnel
Routers to the Interworking Draft?  Both of these cases are evident in
the existing LISP beta network, and we have implementation experience
showing that they are both possible and fairly straightforward to
deploy.

-Darrel

---

From: Michael Menth <[email-masked]>
Date: Sat, 09 Jan 2010 00:54:21 +0100

Hi Darrel,

>       support for mixed protocol encapsulation.

I do not understand the two application scenarios and how PETRs can 
help. Could you explain that in more detail, please?

Regards,

    Michael

> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp
>   

-- 
Dr. Michael Menth, Assistant Professor
University of Wuerzburg, Institute of Computer Science
Am Hubland, D-97074 Wuerzburg, Germany, room B206
phone: (+49)-931/31-86644 (new), fax: (+49)-931/888-6632
mailto:[email-masked]
http://www3.informatik.uni-wuerzburg.de/research/ngn

---

From: "Darrel Lewis (darlewis)" <[email-masked]>
Date: Mon, 11 Jan 2010 12:32:18 -0800

> help. Could you explain that in more detail, please?

Michael,

Today when an ITR receives a packet on its local interface with the
destination address of a non-lisp site, today it forwards it without
encapsulation.  To be specific, an ITR has a map-cache that contains
both 'positive' and 'negative' cache entries.  When a packet's
destination address matches a positive entry, it is encapsulated to the
locators in the mapping.  When a packet's destination address matches a
negative entry, the packet is forwarded natively without encapsulation
(to the next hop).

However, there are a couple of cases where this non-encapsulated packet
will get dropped.

First, the Provider Edge router may be doing some sort of strict
filtering on the source address of packets sent by the CE device (the
ITR).  Thus packets with the source of an EID may be dropped because the
PE router does not have an route to the EID out the interface.  

Second, the Provider Edge router may only support IPv4.  So an ITR
sending a IPv6 packet will obviously fail.

The Proxy ETR allows an ITR to encapsulate packets that match 'negative'
map-cache entries to a destination that can bypass both the above
situations.  In the first case, the encapsulated packet's outer header
has a correct source address.  In the second case, the encapsulated
outer header would be an IPv4 packet.  Of course, this implies that the
Proxy ETR has dual stack external connectivity (post decapsulation) the
Proxy ETR's upstream router(s) use loose mode uRPF.

Hope this helps explain the situation a little bit more clearly.

-Darrel

---

From: Michael Menth <[email-masked]>
Date: Tue, 12 Jan 2010 09:32:33 +0100

Hi Darrel,

thanks for this clear explanation. One more question that was not 
addressed in your previous email. I guess that the ITR is configured 
with the address of some PETR outside the source LISP domain and uses 
this PETR if needed, right? I mean the PETR is usually independent of 
the destination EID?

Regards,

    Michael

---

From: "Darrel Lewis (darlewis)" <[email-masked]>
Date: Tue, 12 Jan 2010 10:53:09 -0800

> Hi Darrel,
> 
> thanks for this clear explanation. 

My Pleasure.

>One more question that was not 

Correct.  The Proxy ETR is only used for non-LISP destinations, and is a
tool for the source (the ITR) to use.

-Darrel