Subject: [lisp] LISP Use Cases

From: Luigi Iannone <[email-masked]>
Date: Mon, 10 Aug 2015 00:07:05 +0200

Hi,

As previously said, "use case” might not be the best term, and 
as Darrel Lewis suggested during the meeting in Prague,
the WG should be careful not to create tight constraints by 
binding the protocol to narrow use cases.

Yet, it is always good to have an idea of where the technology we are
designing will be used. This will as well may help in taking some decisions 
along the way.

There is no predefined suggestion, but a good starting point for discussion
is the list provided by Fabio Maino in his mail:
 http://www.ietf.org/mail-archive/web/lisp/current/msg05996.html <http://www.ietf.org/mail-archive/web/lisp/current/msg05996.html>

- LISP VPN (including integration with IPsec)
- NVO3 use case for DC virtualization (including support for VM mobility)
- SDN/NFV (including support for service chaining)
- IoT (LISP as connecting infrastructure for IoT applications)
- Mobile Node  (LISP-MN mobility)

Please send your feedback to which area should have priority.

Joel & Luigi

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 10 Aug 2015 15:42:19 -0700

> - Mobile Node  (LISP-MN mobility)

And I would say all these use-cases must support multicast packets and packets that traverse through NATs. Those are not separate use-cases but baselines that each use-case needs to support.

Dino

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 10 Aug 2015 18:49:28 -0400

Casn you expand a bit.  It is not obvious to me that either IoT or 
Mobile Node needs multicast support from LISP for its LISP usage.

For example, people keep talking about multicast video, but in fact we 
know that is a corner case and become even less common.

Data Center clearly needs some multicast.  I can see some argument for VPN.

Since SDN is simply a way of deploying other things, multicast in VPN 
contexts clearly depends upon what problem you are using SDN to solve.

Yours,
Joel

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 10 Aug 2015 16:11:28 -0700

> Casn you expand a bit.  It is not obvious to me that either IoT or Mobile Node needs multicast support from LISP for its LISP usage.

On IoT or mobile node may want to send multicast packets. Those multicast packets need to get to receivers. The receivers may be at LISP sites.

> For example, people keep talking about multicast video, but in fact we know that is a corner case and become even less common.

If you want to support other transports and you want to stretch L2 subnets, then ARP and IPv6 link-local multicast will need to be supported. That means the overlay needs to transport multicast packets.

> Data Center clearly needs some multicast.  I can see some argument for VPN.

Right. And a node in a VPN site can be anywhere.

> Since SDN is simply a way of deploying other things, multicast in VPN contexts clearly depends upon what problem you are using SDN to solve.

SDN, in my mind is a network management mechanism. When we talk about the LISP architecture and protocols, we are talking about in-network control-plane mechanisms (and I mean between nodes in the network in a distributed fashion).

Dino

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

---

From: Stig Venaas <[email-masked]>
Date: Wed, 12 Aug 2015 10:20:19 -0700

I agree we need to consider multicast. There are people that want to do
multicast over LISP. Some are already doing it. This also includes mobility.

Stig

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 12 Aug 2015 10:22:51 -0700

Yes, where but multicast sources as well as multicast receivers are moving. There are severl military applications for this use-case.

Dino

> On Aug 12, 2015, at 10:20 AM, Stig Venaas <[email-masked]> wrote:
> 
> I agree we need to consider multicast. There are people that want to do multicast over LISP. Some are already doing it. This also includes mobility.
> 
> Stig

---

From: Stig Venaas <[email-masked]>
Date: Wed, 12 Aug 2015 10:44:10 -0700

On Aug 12, 2015 10:22 AM, "Dino Farinacci" <[email-masked]> wrote:
>
> Yes, where but multicast sources as well as multicast receivers are
moving. There are severl military applications for this use-case.

Agree

Stig

---

From: Damien Saucez <[email-masked]>
Date: Fri, 14 Aug 2015 18:18:18 +0200

Hello,

I understand that multicast and nat traversal are potentially required in all use cases, but the "must support" sounds extreme to me. Are they hypothetical requirements or real demand from the market targeted by LISP, new version ?

Damien Saucez 

> On 12 Aug 2015, at 19:44, Stig Venaas <[email-masked]> wrote:
> 
>

---

From: [email-masked]
Date: Sat, 15 Aug 2015 15:03:20 -0700

The logic follows like this:

If NVo3 is a requirement for the recharter, then L2 overlay support is required. If L2 overlay support is required, then you must stretch subnets. If you stretch subnets, broadcast frame support is required. If broadcast frame support is needed, then multicast support on the overlay is needed. 

And if L2 overlays are going to be supported in cloud environments, homenet, or in containers, then NAT-traversal support is required. 

Dino

> On Aug 14, 2015, at 9:18 AM, Damien Saucez <[email-masked]> wrote:
> 
> Hello,
>

---

From: Damien Saucez <[email-masked]>
Date: Mon, 17 Aug 2015 08:50:39 +0200

Perfect!

Damien Saucez 

> On 16 Aug 2015, at 00:03, [email-masked] wrote:
>

---

From: Sharon Barkai <[email-masked]>
Date: Mon, 17 Aug 2015 12:46:47 +0000

would also say that if we are to help implement  overlays with the lisp mapping architecture, then we could expect any overlay aggregation node to subscribe to any traffic identifiers/classifiers
- unicast, multicast.g, taps, chain.index.. and to the mappings them selves

Doesn't mean they get it, may be other policies in place, both in the mapping and in the itr, but xtr can subscribe by essence of overlays - logical not topological connectionless traffic forwarding over IP.

--szb

On Aug 15, 2015, at 3:03 PM, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> wrote:

Dino

On Aug 14, 2015, at 9:18 AM, Damien Saucez <[email-masked]<mailto:[email-masked]>> wrote:

Hello,

Damien Saucez

On 12 Aug 2015, at 19:44, Stig Venaas <[email-masked]<mailto:[email-masked]>> wrote:

Agree

Stig

>
> Dino
>
> > On Aug 12, 2015, at 10:20 AM, Stig Venaas <[email-masked]<mailto:[email-masked]>> wrote:
> >

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

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 17 Aug 2015 09:41:58 -0700

> - unicast, multicast.g, taps, chain.index.. and to the mappings them selves

Yes, definitely agree. And the lisp-subscription ID reflects that.

Note to WG, this draft is about to be published soon.

> Doesn't mean they get it, may be other policies in place, both in the mapping and in the itr, but xtr can subscribe by essence of overlays - logical not topological connectionless traffic forwardin…

Right. 

Dino

> 
> --szb
> 
> On Aug 15, 2015, at 3:03 PM, "[email-masked]" <[email-masked]> wrote:
>

---

From: Luigi Iannone <[email-masked]>
Date: Tue, 25 Aug 2015 11:11:58 +0200

> On 17 Aug 2015, at 18:41, Dino Farinacci <[email-masked]> wrote:
> 

If this is something that will help the rechartering discussion it would be helpful either to publish the draft soon or to sketch by mail what a lisp-subscription ID is.

L.

---

From: Luigi Iannone <[email-masked]>
Date: Tue, 25 Aug 2015 11:14:53 +0200

Dino,

what you write make sense, but let me invite the WG to discuss more on the first _IF_ of your logic: “if NVO3 …".

As I pointed out in another mail, we need more discussion on what we are going to support.

We cannot write a charter that states “LISP will support NVO3 use-cases”.

L.

> On Aug 14, 2015, at 9:18 AM, Damien Saucez <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> Hello,
>> 
>> On 12 Aug 2015, at 19:44, Stig Venaas <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>> 
>>> On Aug 12, 2015 10:22 AM, "Dino Farinacci" <[email-masked] <mailto:[email-masked]>> wrote:
>>> >
>>> > > On Aug 12, 2015, at 10:20 AM, Stig Venaas <[email-masked] <mailto:[email-masked]>> wrote:
>>> > >
>>> [email-masked] <mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/lisp <https://www.ietf.org/mailman/listinfo/lisp>

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 25 Aug 2015 10:02:00 -0700

> We cannot write a charter that states “LISP will support NVO3 use-cases”.

How about this specific text:

For the NVo3 use-case, LISP will support L2-overlays by selecting a data-plane that supports encapsulation of MAC frames in IPv4 or IPv6 packets and by using the mapping database that supports (instance-ID, MAC-address) extended-EIDs.

Dino

---

From: Luigi Iannone <[email-masked]>
Date: Wed, 26 Aug 2015 10:38:04 +0200

> On 25 Aug 2015, at 19:02, Dino Farinacci <[email-masked]> wrote:
> 

Better… but I personally (no hats on) would prefer an tighter charter with a more precise list milestones. 

May be the overlay model thread will give us such list ;-)

L.

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 26 Aug 2015 09:44:59 -0700

I can certainly help you with the charter text and get as specific as we need to.

Dino

> On Aug 26, 2015, at 1:38 AM, Luigi Iannone <[email-masked]> wrote:
> 
>