Subject: [5gangip] Fwd: RE: [lisp] [Ideas] Mapping System Requirements and draft-padma-ideas-problem-statement-00.txt

From: Michael Menth <[email-masked]>
Date: Wed, 28 Sep 2016 11:13:37 +0200

Hi Dino,

Am 28.09.2016 um 05:02 schrieb Dino Farinacci:
>> When I spoke to some of the 5G folks this was clearly the direction and in fact Dino's LISP was one of the strongest candidates there as control plane. 
> The IETF’s LISP-DDT borrows ideas from DNS but does not need to be structured like the DNS deployed today. There is hierarchy for scale with iterative lookups, but we don’t have to allow it to get out of hand with too many levels of hierarchy.
What do you mean by that exactly? What's the problem with DNS and what's the advantage of LISP-DDT?

Michael

---

From: AshwoodsmithPeter <[email-masked]>
Date: Wed, 28 Sep 2016 12:43:46 +0000

I'm guessing that DNS is designed for low frequency updates but high frequency queries while a mapping system for LISP needs to handle very high frequency updates and queries. 

Peter

-----Original Message-----
From: 5gangip [mailto:[email-masked]] On Behalf Of Michael Menth
Sent: Wednesday, September 28, 2016 5:14 AM
To: [email-masked]
Subject: [5gangip] Fwd: RE: [lisp] [Ideas] Mapping System Requirements and draft-padma-ideas-problem-statement-00.txt

Hi Dino,

Michael

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

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 28 Sep 2016 09:09:58 -0400

There is:

Achieving host mobility using DNS dynamic updating protocol

published back in 2008.  You can do a google search to find a source for 
the pdf.  Note that I do not use it for my HIP proposal. Amongst other 
issues, it does not handle the double-jump event.

But the paper proposes an approach for fast DNS updates and availability.

Bob

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 28 Sep 2016 10:38:18 -0700

Yes, that’s right. Among other implementation details.

Dino

> On Sep 28, 2016, at 5:43 AM, AshwoodsmithPeter <[email-masked]> wrote:
> 
>

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 28 Sep 2016 17:02:10 -0500

> Yes, that’s right. Among other implementation details.

Can we say that this is LISP specific issue?

ILNP already uses DNS.
ILA being derived from ILNP can also use DNS.

So we need to discuss it if it is not LISP-only issue, I think.

Behcet

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 28 Sep 2016 15:16:28 -0700

> ILA being derived from ILNP can also use DNS.

Well if an ILNP/ILA host is going to move around and change its locator, it has to do a record update to  DNS. And this could be frequently.

And then the moving host has to tell its peers to know the new locator. That can be done by a mapping system (but DNS doens’t do this) or messaging peer-to-peer. 

And then there is multicast. How does ILNP and ILA do multicast?

Dino

---

From: Ca By <[email-masked]>
Date: Wed, 28 Sep 2016 15:26:16 -0700

On Wednesday, September 28, 2016, Dino Farinacci <[email-masked]>
wrote:

> > On Wed, Sep 28, 2016 at 12:38 PM, Dino Farinacci <[email-masked]
> <javascript:;>> wrote:
> Well if an ILNP/ILA host is going to move around and change its locator,
> it has to do a record update to  DNS. And this could be frequently.
>
> And then the moving host has to tell its peers to know the new locator.
> That can be done by a mapping system (but DNS doens’t do this) or messaging
> peer-to-peer.
>
Is there scope for mutlicast?  I would say no.

I do not believe multicast ip is provided to the UE anywhere today in
3gpp  (embms is not multicast to the UE, but it is a technology the
effectively addresss the little opportunity in multicast without multicast
ip)

> >>> On Sep 28, 2016, at 5:43 AM, AshwoodsmithPeter <
> [email-masked] <javascript:;>> wrote:
> >>>
> >>>
> >>> I'm guessing that DNS is designed for low frequency updates but high
> frequency queries while a mapping system for LISP needs to handle very high
> frequency updates and queries.
> >>>
> >>> Peter
> >>>
> >>> From: 5gangip [mailto:[email-masked] <javascript:;>] On
> Behalf Of Michael Menth
> >>> To: [email-masked] <javascript:;>
> >>> Subject: [5gangip] Fwd: RE: [lisp] [Ideas] Mapping System Requirements
> and draft-padma-ideas-problem-statement-00.txt
> >>>
> >>> Hi Dino,
> >>>
> >>>>> When I spoke to some of the 5G folks this was clearly the direction
> and in fact Dino's LISP was one of the strongest candidates there as
> control plane.
> >>>> The IETF’s LISP-DDT borrows ideas from DNS but does not need to be
> structured like the DNS deployed today. There is hierarchy for scale with
> iterative lookups, but we don’t have to allow it to get out of hand with
> too many levels of hierarchy.
> >>> [email-masked] <javascript:;>
> >>> [email-masked] <javascript:;>
> >> [email-masked] <javascript:;>
> [email-masked] <javascript:;>

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 28 Sep 2016 17:38:32 -0500

ILNP RFC 6740 says:
Multicast forwarding and routing are unchanged, in order to avoid
   requiring changes in deployed IP routers and routing protocols.
 So IP multicast applies in ILNP.

On Wed, Sep 28, 2016 at 5:26 PM, Ca By <[email-masked]> wrote:
> I do not believe multicast ip is provided to the UE anywhere today in 3gpp
> (embms is not multicast to the UE, but it is a technology the effectively
> addresss the little opportunity in multicast without multicast ip)
>
>
>
>> >
>> >>>>> and in fact Dino's LISP was one of the strongest candidates there as control
>> >>>>> plane.
>> >>>> iterative lookups, but we don’t have to allow it to get out of hand with too
>> >>>> many levels of hierarchy.

---

From: AshwoodsmithPeter <[email-masked]>
Date: Thu, 29 Sep 2016 13:26:33 +0000

I think we'd definitely like to take advantage of wireless' inherent multicast capability especially for  real time video but one of the challenges I'm told is that  not 
every UE uses the same downlink encoding  (nothing to do with video CODEC) due each having different interference behavior etc. so there would need to be grouping by similar UE downlink encodings as part the last hop replication.
	
Peter

-----Original Message-----
From: Behcet Sarikaya [mailto:[email-masked]] 
Sent: Wednesday, September 28, 2016 6:39 PM
To: Ca By <[email-masked]>
Cc: Dino Farinacci <[email-masked]>; [email-masked]; Michael Menth <[email-masked]>; AshwoodsmithPeter <[email-masked]>
Subject: Re: [5gangip] Mapping System Requirements and draft-padma-ideas-problem-statement-00.txt

ILNP RFC 6740 says:

On Wed, Sep 28, 2016 at 5:26 PM, Ca By <[email-masked]> wrote:
>> > On Wed, Sep 28, 2016 at 12:38 PM, Dino Farinacci 
>> > <[email-masked]>
>> > wrote:
>> Well if an ILNP/ILA host is going to move around and change its 
>> locator, it has to do a record update to  DNS. And this could be frequently.
>>
>> That can be done by a mapping system (but DNS doens’t do this) or 
>> messaging peer-to-peer.
>>
> effectively addresss the little opportunity in multicast without 
> multicast ip)
>
>
>
>> >
>> >>> I'm guessing that DNS is designed for low frequency updates but 
>> >>> high frequency queries while a mapping system for LISP needs to 
>> >>> handle very high frequency updates and queries.
>> >>>
>> >>> Peter
>> >>>
>> >>> Subject: [5gangip] Fwd: RE: [lisp] [Ideas] Mapping System 
>> >>> Requirements and draft-padma-ideas-problem-statement-00.txt
>> >>>
>> >>> Hi Dino,
>> >>>
>> >>>>> When I spoke to some of the 5G folks this was clearly the 
>> >>>>> direction and in fact Dino's LISP was one of the strongest 
>> >>>>> candidates there as control plane.
>> >>>> The IETF’s LISP-DDT borrows ideas from DNS but does not need to 
>> >>>> be structured like the DNS deployed today. There is hierarchy 
>> >>>> for scale with iterative lookups, but we don’t have to allow it 
>> >>>> to get out of hand with too many levels of hierarchy.

---

From: AshwoodsmithPeter <[email-masked]>
Date: Thu, 29 Sep 2016 13:33:22 +0000

The world is long overdue for  world-wide <key, value> distributed DB. 

The "WWDB" ;)

Peter

-----Original Message-----
From: Dino Farinacci [mailto:[email-masked]] 
Sent: Wednesday, September 28, 2016 1:38 PM
To: AshwoodsmithPeter <[email-masked]>
Cc: Michael Menth <[email-masked]>; [email-masked]
Subject: Re: [5gangip] Fwd: RE: [lisp] [Ideas] Mapping System Requirements and draft-padma-ideas-problem-statement-00.txt

Dino

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 29 Sep 2016 09:37:47 -0400

Look at the various IDs dealing with Distributed Hash Tables.  And of 
course the research and free DHT servers.

---

From: AshwoodsmithPeter <[email-masked]>
Date: Thu, 29 Sep 2016 15:53:39 +0000

Yes I know.. but my point was it was about time it became 'mainstream'.

I dream of being able to issue a LINUX/IOS etc. call to put() and get() and just having it 'work' the same way I can open a socket and it just 'works'. How cool and impactful would that be!

Peter

-----Original Message-----
From: Robert Moskowitz [mailto:[email-masked]] 
Sent: Thursday, September 29, 2016 9:38 AM
To: AshwoodsmithPeter <[email-masked]>; Dino Farinacci <[email-masked]>
Cc: [email-masked]; Michael Menth <[email-masked]>
Subject: Re: [5gangip] Fwd: RE: [lisp] [Ideas] Mapping System Requirements and draft-padma-ideas-problem-statement-00.txt

Look at the various IDs dealing with Distributed Hash Tables.  And of course the research and free DHT servers.

On 09/29/2016 09:33 AM, AshwoodsmithPeter wrote:
> Subject: Re: [5gangip] Fwd: RE: [lisp] [Ideas] Mapping System

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 29 Sep 2016 11:03:42 -0500

As Cameron said, EMBMS in 3GPP is not really IP multicast, it is
designed for software delivery, efficient delivery of iOS or Android
updates to all UEs, as such I think it is layer 2 multicast, with base
stations doing the last hop replication.

I don't know how Netflix or sports game video is distributed online,
maybe it is application layer multicast.

In short, multicast mobility type of work is difficult to justify but
certainly technically challenging :)

Behcet

---

From: Rex Buddenberg <[email-masked]>
Date: Thu, 29 Sep 2016 10:35:01 -0700

> certainly technically challenging :)

Not so (difficult to justify).

If you look at the nature of emergency services data, a great deal of
it is multicast in nature -- has to go >1 places.  Indeed if you talk
to EMS folks who's view of the world is Land Mobile Radio, they have a
different set of terminology, but it's multicast.

Yes, technically challenging relative to unicast.  But if you get the
multicast right, unicast is a simpler subset.

Belongs in scope.

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 30 Sep 2016 11:13:27 -0500

I don't understand why this conversation is being hidden from the list.

Folks, I worked on multicast mobility.
I was co-chair of multicast mobility or Multimob WG from 2009 to 2014.
Multimob scope was adding multicast support to the unicast mobility
protocols of PMIPv6 and a bit of MIPv6.

We did work it out, found good solutions and successfully terminated
the WG (BTW, good lesson to long lasting WGs :)
.
However, there is a caveat, IETF did not give us any standard stack
RFCs, only experimental or informational.

So the message is clear, let us solve the unicast problem first and
them worry about multicast support.

Behcet
On Tehu, Sep 29, 2016 at 6:12 PM, Rex Buddenberg <[email-masked]> wrote:
> On Thu, 2016-09-29 at 18:46 -0400, Tom Herbert wrote:
>> On Sep 29, 2016 6:32 PM, "Padmadevi Pillay Esnault" <[email-masked]
>> > wrote:
>> >
>> > See below
>> >
>> > From: 5gangip [mailto:[email-masked]] On Behalf Of Rex
>> Buddenberg
>> > Sent: Thursday, September 29, 2016 10:35 AM
>> > To: [email-masked]; AshwoodsmithPeter
>> > Cc: [email-masked]; Ca By; Michael Menth; Dino Farinacci
>> > [Padma Pillay Esnault]
>> > Agree here.
>> > [Padma Pillay Esnault] Agree. As we are moving towards a hyper-
>> connected society, more and more services will multicast in nature.
>> Do you really want to control/communicate to things as in internet of
>> things one by one?
>> >
>> Security and reliability make this really hard, especially for
>> critical information like hazard warnings to autonomous vehicles. I'm
>> not sure how well VANET solves this which would seem to want a lot of
>> multicast.
>
> Depends on what security you need.  Content authenticity?  Not too bad
> -- recipients all need the sendor's public key.  Content
> confidentiality is harder using the existing PKI procedures.
>      I can't think of many applications where authenticity is not a
> requirement, but there are a lot where confidentiality is not.
>
> Reliability.  TCP is a unicast protocol.  Period.  But there are
> multicast transport protocols (NORM is one) that provide reliability in
> multicast environments.
>
> Just because a problem is hard does not mean the requirements are not
> legit.
>
>
>> Tom
>> > Ideas mailing list
>> > [email-masked]
>> > https://www.ietf.org/mailman/listinfo/ideas

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 30 Sep 2016 12:47:58 -0400

And one addition here.  I have not even concerned myself with multicast 
until we can vastly improve on GTP-U.  Maybe I am making more out of it 
than needed, but with everything going down a pipe to a coupe heads, 
something other than IP multicast may be a better approach.

And I was told that any proposal to change GTP-U within 3GPP is a 
non-starter.  So go figure.  But then someone may have better 
connections within 3GPP on this.

Bob

---

From: Jouni korhonen <[email-masked]>
Date: Fri, 30 Sep 2016 12:49:39 -0700

On Sep 30, 2016, at 9:47 AM, Robert Moskowitz <[email-masked]> wrote:

> And one addition here.  I have not even concerned myself with multicast until we can vastly improve on GTP-U.  Maybe I am making more out of it than needed, but with everything going down a pipe to a coupe heads, something other than IP multicast may be a better approach.
> 
> And I was told that any proposal to change GTP-U within 3GPP is a non-starter.  So go figure.  But then someone may have better connections within 3GPP on this.

I take you are referring to GTP-Uv1. Depends what you want to change on it. Incremental stuff is usually doable as long as it does not break old stuff.

At the beginning of Rel-8 there were attempts to do bigger changes to GTP-U (like having a GTP-Uv2) but there was considerable push back.. AFAIR (it’s been long time ;) due GTP-U using boxes in RAN, not really in core network.

Btw, there is multicast (MBMS) flavor of GTP-U. Just look at TS36.445 as a starting point.

- Jouni

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 30 Sep 2016 16:31:02 -0500

> Btw, there is multicast (MBMS) flavor of GTP-U. Just look at TS36.445 as a starting point.

This is not multicast GTP-U, 36.445 says that GTP-U will be used to
carry or tunnel IP multicast over M1 interface from eNB to the EPC,
i.e. SGW.

Behcet