Subject: [nvo3] LISP control plane input into gap analysis draft

From: "Yves Hertoghs (yhertogh)" <[email-masked]>
Date: Mon, 4 Nov 2013 20:25:29 +0000

Hi,

As requested at the IETF88 physical meeting:
Draft-hertoghs-nvo3-lisp-controlplane-unified uses LISP as a control plane for a combination of data planes.  It used the (at the time) current versions of the cp and dp nvo3 drafts and shows how this unified LISP CP solution satisfies them.  As a result sections 3.3 and 3.4 can be used as a direct input into draft-ietf-nvo3-gap-analysis.

So, i'd like to request to add LISP as a CP option to draft-ietf-nvo3-gap-analysis ,  and use the text in 3.3 and 3.4 to complete the current gap analysis.

Let me know if you dont agree/have questions

Yves Hertoghs

---

From: Damien Saucez <[email-masked]>
Date: Mon, 4 Nov 2013 13:07:10 -0800

I agree that LISP is an interesting approach for nvo3.

Regards,

Damien Saucez

On 04 Nov 2013, at 12:25, Yves Hertoghs (yhertogh) <[email-masked]> wrote:

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

---

From: Lucy yong <[email-masked]>
Date: Mon, 4 Nov 2013 21:48:33 +0000

I agree that we have analyze on LISP applicability and gap to NVO3.

Could someone explain to me how to use LISP solution to provide route path control? For example, in a VN, ingress NVE MUST forward the packets to another NVE at which a tenant system runs firewall software. The second NVE then forwards to the packets to the third NVE where an attached TS has the address that matches the destination address in the inner address on the packets.

Lucy

From: [email-masked] [mailto:[email-masked]] On Behalf Of Damien Saucez
Sent: Monday, November 04, 2013 3:07 PM
To: Yves Hertoghs (yhertogh)
Cc: [email-masked]; [email-masked]
Subject: Re: [nvo3] LISP control plane input into gap analysis draft

Regards,

Damien Saucez

On 04 Nov 2013, at 12:25, Yves Hertoghs (yhertogh) <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Yves Hertoghs
_______________________________________________
nvo3 mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/nvo3

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 4 Nov 2013 13:52:58 -0800

> I agree that LISP is an interesting approach for nvo3.

We should do it for the users and network operators. Less control-planes will make provisioning and management simpler for them. 

A unified approach gives you that. And we have an existence proof with IS-IS and BGP, protocols that carry and support multiple address families. 

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 4 Nov 2013 14:00:45 -0800

> Could someone explain to me how to use LISP solution to provide route path control? For example, in a VN, ingress NVE MUST forward the packets to another NVE at which a tenant system runs firewall…

LISP has a decapsaltor/encasulator component called an RTR. An RTR can give you suboptimal paths by choice if you want to route around failures, congestion points, or use policy paths. You can find details in http://datatracker.ietf.org/doc/draft-farinacci-lisp-te.

But yes, you can have an RTR co-located with a firewall, laod-balancer, and NAT type middle devices.

Dino

---

From: "Yves Hertoghs (yhertogh)" <[email-masked]>
Date: Mon, 4 Nov 2013 22:36:35 +0000

I agree that LISP has built in service chaining support through using LISP
RTRs as described by Dino.

But there are other, protocol independent ways of achieving the same
behaviour, see the work being presented at the SFC BOF
https://datatracker.ietf.org/meeting/88/agenda/sfc/

Yves

On 04/11/13 23:00, "Dino Farinacci" <[email-masked]> wrote:

>> Could someone explain to me how to use LISP solution to provide route
>>path control? For example, in a VN, ingress NVE MUST forward the packets
>>to another NVE at which a tenant system runs firewall software. The
>>second NVE then forwards to the packets to the third NVE where an
>>attached TS has the address that matches the destination address in the
>>inner address on the packets.
>>  
>> Lucy
>
>LISP has a decapsaltor/encasulator component called an RTR. An RTR can
>give you suboptimal paths by choice if you want to route around failures,
>congestion points, or use policy paths. You can find details in
>http://datatracker.ietf.org/doc/draft-farinacci-lisp-te.
>

---

From: Sharon <[email-masked]>
Date: Wed, 6 Nov 2013 04:51:27 -0800

To add to Dino's comment, 
based on implementation experience (which can be referenced in ODL open source), at the physical to virtual network infrastructure definitions level.. 

a (lisp) re-tunneling element, with an underlay address and access to (cached) global mapping information.. can be used to:

- map flows to function chains by load and tenancy according to a specified (per source and or dest) itinerary, in a self balanced manner

- map flows to programable segmented paths in the underlay, for application aware core balancing e.g streamer accessing content real-time vs content being replicated in the background 

- replicate flows for multicasting to multiple rlocs, or for tapping / debugging / wiresharking / calea

Plus a few more utilities.
So LISP RTR is a recommended very practical "base-class"

--szb

> On Nov 4, 2013, at 2:00 PM, Dino Farinacci <[email-masked]> wrote:
> 

Dino

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 7 Nov 2013 13:23:44 -0800

http://events.linuxfoundation.org/events/opendaylight-summit/program/cfp