Subject: [DMM] Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

From: Tom Herbert <[email-masked]>
Date: Thu, 1 Feb 2018 13:27:28 -0800

Hello,

We posted this draft that describe using ILA for the mobile network
use case, and some specifics about using ILA in 5G.

We like like to request that the dmm WG consider ILA as a candidate
protocol for the 3GPP "Study on User Plane Protocol in 5GC".

Comments are appreciated!

Thank you,
Tom

---------- Forwarded message ----------
From:  <[email-masked]>
Date: Thu, Feb 1, 2018 at 10:09 AM
Subject: New Version Notification for draft-herbert-ila-mobile-00.txt
To: Tom Herbert <[email-masked]>, Kalyani Bogineni
<[email-masked]>

A new version of I-D, draft-herbert-ila-mobile-00.txt
has been successfully submitted by Tom Herbert and posted to the
IETF repository.

Name:           draft-herbert-ila-mobile
Revision:       00
Title:          Identifier Locator Addressing for Mobile User-Plane
Document date:  2018-02-01
Group:          Individual Submission
Pages:          22
URL:
https://www.ietf.org/internet-drafts/draft-herbert-ila-mobile-00.txt
Status:         https://datatracker.ietf.org/doc/draft-herbert-ila-mobile/
Htmlized:       https://tools.ietf.org/html/draft-herbert-ila-mobile-00
Htmlized:
https://datatracker.ietf.org/doc/html/draft-herbert-ila-mobile-00

Abstract:
   This document discusses the applicability of Identifier Locator
   Addressing (ILA) to the user-plane of mobile networks. ILA allows a
   means to implement network overlays without the overhead,
   complexities, or anchor points associated with encapsulation. This
   solution facilitates highly efficient packet forwarding and provides
   low latency and scalability in mobile networks. ILA can be used in
   conjunction with techniques such as network slices and Network
   Function Virtualization to achieve optimal service based forwarding.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 1 Feb 2018 22:33:02 +0000

Thank you Tom and Kalyani for your submission.

WG - During the adoption of
draft-matsushima-spring-dmm-srv6-mobile-uplane, we did say that we will
consider alternative approaches for the problem statement around mobile
user-plane optimization, and that we will not limit to SRv6 as the only
option. 

ILA is one of the proposals on the table. This is not an adoption call at
this time, but asking the WG to review and open up some discussions that
will help IETF understand the problem/solutions, and pick the right
solution(s) for this problem statement. If there is interest and if the
work is in scope for the group, we will issue an adoption call at some
point in future. Please review.

Thanks!
Dapeng & Sri

On 2/1/18, 1:27 PM, "ila on behalf of Tom Herbert" <[email-masked]
on behalf of [email-masked]> wrote:

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

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 1 Feb 2018 14:59:43 -0800

> point in future. Please review.

I just got on the dmm list. Here is another proposal:

https://datatracker.ietf.org/doc/draft-farinacci-lisp-mobile-network/

Dino

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 1 Feb 2018 23:33:32 +0000

Thank you Dino. 

WG -  Same comments for this draft. LISP is another LOC-ID proposal, with
many common attributes (if I  may say, like two twins) shared with ILA;
some differences in how the Locator (COA) and identifier (HOA) spaces are
defined/used/managed, and with one key difference of tunneling vs
translation. Please review.

Regards
Sri

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 1 Feb 2018 15:38:24 -0800

One thing to add. LISP has a more mature control-plane mapping system. ILA has a recent proposal for its control-plane.

Dino

> On Feb 1, 2018, at 3:33 PM, Sri Gundavelli (sgundave) <[email-masked]> wrote:
> 
> Thank you Dino. 
>

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Fri, 2 Feb 2018 00:38:52 +0000

> One thing to add. LISP has a more mature control-plane mapping system.
>ILA has a recent proposal for its control-plane.

Mobility architectures started with a unified CP/UP approach, then the
industry thought its a great idea to move the Control-plane out, and
reduce the state in the User-plane, and eliminate tunnels. Now, we want to
eliminate the tunnels, but we need a new control protocol to manage the
binding tables, and manage the complex cache states. Wondering, what¹s
wrong with this picture?  What de we name this new CUPS architecture?

Sri

(with no chair hat)

---

From: Tom Herbert <[email-masked]>
Date: Thu, 1 Feb 2018 16:57:36 -0800

> wrong with this picture?  What de we name this new CUPS architecture?
Sri,

Bear in mind that "industry" has different meanings depending on the
context. For ILA, and probably for LISP, the intent is to build a
generic protocol that can be used across variety of use cases in the
networking industry which hasn't uniformly adopted CUPS. It's pretty
obvious that we'd want to leverage a single data plane control plane
for these (isn't that the point of generic protocols :-) ). The CUPS
actually architecture helps a lot here by creating a clean well
abstracted interface that should make it straightforward to adapt an
ILA control plane. I think our architecture where we define ILA as an
NF reflects that.

Tom

---

From: Marco Liebsch <[email-masked]>
Date: Fri, 2 Feb 2018 01:07:44 +0000

I think we should rather relax the dependency between control and data plane. If we treat the data plane as nodes which enforce policies (encap, recap, re-write, etc), any c plane may suit and enforce suitable policies in the selected data plane nodes, e.g.  by utilizing the DMM group’s FPC models. Any solution that binds the data plane to a particular control plane may constrain its deployment, no?

marco

On 2. Feb 2018, at 01:39, Sri Gundavelli (sgundave) <[email-masked]> wrote:

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

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Fri, 2 Feb 2018 01:17:47 +0000

Tom, 

Last I remember, we gave one “generic” and an access agnostic protocol in
the form MIPv6/PMIPv6, they never got it and never cared.

But, if you can sell it to 3GPP, this new control-plane that goes into
user-plane, I am with you.  :-)

Sri

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Fri, 2 Feb 2018 01:20:06 +0000

Absolutely! A programmable data plane what FPC interface is offering,
keeps the CUPS objectives.

Sri

On 2/1/18, 5:07 PM, "ila on behalf of Marco Liebsch" <[email-masked]
on behalf of [email-masked]> wrote:

>I think we should rather relax the dependency between control and data
>plane. If we treat the data plane as nodes which enforce policies (encap,
>recap, re-write, etc), any c plane may suit and enforce suitable policies
>in the selected data plane nodes, e.g.  by utilizing the DMM group’s FPC
>models. Any solution that binds the data plane to a particular control
>plane may constrain its deployment, no?
>
>marco
>
>
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 2 Feb 2018 15:40:58 +0000

Hi, please add AERO to the list:

https://datatracker.ietf.org/doc/draft-templin-aerolink/

AERO does IPv6 ND over tunnels, and supports mobility via dynamic
neighbor cache updates the same as any IPv6 link. Use cases include
(but are not limited to):

- Enterprise mobile devices (cellphones, tablets, etc. as mobile networks)
- civil aviation networks (airplanes as mobile networks)
- Unmanned Air Systems (drones as mobile networks)

AERO has been discussed in this forum several years back, and has
continued to mature since that time. Maybe now is the time to start
talking about it again.

Thanks - Fred

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Fri, 2 Feb 2018 16:00:07 +0000

Thank you Fred. 
 
There is a reason for mobile architectures shifting towards CP-UP split
architecture (Ref: DMM WG documents + 3GPP CUPS), and the stated goal of
further simplification in the mobile user plane (Reference: 3GPP CT4 Study
item and 3GPP Liaison statement to DMM). Now, it will be good if we can
explain how each of these protocols (ILA, LISP, AERO ..) address those key
objectives around mobile user-plane optimization, else there is no reason
for the WG to consider that specific protocol option. So, please do
include this text in the I-D, and/or explain to the WG on how its
addressing these issues.

WG - Please review AERO specs, along with the other proposals.

Sri

---

From: "Bogineni, Kalyani" <[email-masked]>
Date: Mon, 5 Feb 2018 20:04:01 +0000

Dino:

Can you add a section to show how this proposal would fit in 5G architecture? 

Kalyani

-----Original Message-----
From: ila [mailto:[email-masked]] On Behalf Of Sri Gundavelli (sgundave)
Sent: Thursday, February 1, 2018 6:34 PM
To: Dino Farinacci <[email-masked]>
Cc: [email-masked]; Tom Herbert <[email-masked]>; dmm <[email-masked]>
Subject: [E] Re: [Ila] [DMM] Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

Thank you Dino. 

WG -  Same comments for this draft. LISP is another LOC-ID proposal, with many common attributes (if I  may say, like two twins) shared with ILA; some differences in how the Locator (COA) and identifier (HOA) spaces are defined/used/managed, and with one key difference of tunneling vs translation. Please review.

Regards
Sri

On 2/1/18, 2:59 PM, "Dino Farinacci" <[email-masked]> wrote:

>> ILA is one of the proposals on the table. This is not an adoption 
>>call at  this time, but asking the WG to review and open up some 
>>discussions that  will help IETF understand the problem/solutions, and 
>>pick the right
>> solution(s) for this problem statement. If there is interest and if 
>>the  work is in scope for the group, we will issue an adoption call at 
>>some  point in future. Please review.
>
>https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.o
>rg_doc_draft-2Dfarinacci-2Dlisp-2Dmobile-2Dnetwork_&d=DwICAg&c=udBTRvFv
>XC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=IdiSODh8aDRjdCeGgd9MznLHMYKgKcs_Y
>SwXBDiaofh47oilzaXYRYETcBynUdpT&m=0FPXpkwcIr_nXgnH3elSoIO0UbXQVCs2mAT1a
>FmeI30&s=GsKsl3A6sbXWSegMimugCGCWIdJey5Gt4pq_z6Ql1oA&e=
>
>Dino
>

_______________________________________________
ila mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ila&d=DwICAg&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=IdiSODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT&m=0FPXpkwcIr_nXgnH3elSoIO0UbXQVCs2mAT1aFmeI30&s=c4jMVkWkS0nBsE4QFXON2NvUrA6Z4vZu0xTCtvI3hf4&e=

---

From: "Bogineni, Kalyani" <[email-masked]>
Date: Mon, 5 Feb 2018 20:04:55 +0000

Fred:

Can you add a section to show how this proposal will work in 5G architecture?

Kalyani

-----Original Message-----
From: ila [mailto:[email-masked]] On Behalf Of Sri Gundavelli (sgundave)
Sent: Friday, February 2, 2018 11:00 AM
To: Templin, Fred L <[email-masked]>; Dino Farinacci <[email-masked]>; Tom Herbert <[email-masked]>
Cc: [email-masked]; dmm <[email-masked]>
Subject: [E] Re: [Ila] [DMM] Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

Thank you Fred. 
 
There is a reason for mobile architectures shifting towards CP-UP split architecture (Ref: DMM WG documents + 3GPP CUPS), and the stated goal of further simplification in the mobile user plane (Reference: 3GPP CT4 Study item and 3GPP Liaison statement to DMM). Now, it will be good if we can explain how each of these protocols (ILA, LISP, AERO ..) address those key objectives around mobile user-plane optimization, else there is no reason for the WG to consider that specific protocol option. So, please do include this text in the I-D, and/or explain to the WG on how its addressing these issues.

Sri

On 2/2/18, 7:40 AM, "Templin, Fred L" <[email-masked]> wrote:

>rg_doc_draft-2Dtemplin-2Daerolink_&d=DwICAg&c=udBTRvFvXC5Dhqg7UHpJlPps3
>mZ3LRxpb6__0PomBTQ&r=IdiSODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilza
>XYRYETcBynUdpT&m=sCHryEZFtc7CtEHHHDax7-Ae9uuwPgGWuYf9-O1T12w&s=HIFgnfSr
>nLv7H1FRiA_sivkZ6tqIQkBDmLgnGi9logQ&e=
>

_______________________________________________
ila mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ila&d=DwICAg&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=IdiSODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT&m=sCHryEZFtc7CtEHHHDax7-Ae9uuwPgGWuYf9-O1T12w&s=rVisbGTQdyRNwu8W6zgFJawofONn9JBd1ixzyMqefrQ&e=

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 6 Feb 2018 09:32:02 +0900

> On Feb 6, 2018, at 5:04 AM, Bogineni, Kalyani <[email-masked]> wrote:
> 
> Dino:
> 

Can you be more specific in what you’d like to see in the new section?

There are references throughout the draft where you see eNodeB and pGW that UPF functionality could be at the same network mode location. 

Dino

---

From: "Bogineni, Kalyani" <[email-masked]>
Date: Tue, 6 Feb 2018 01:15:53 +0000

Dino:

Please look at 3GPP TS 23.501 to understand the architecture of NGC. We tried to explain that in the White paper.
TS 23.502 has the procedures for the NGC. TS 23.503 specifies the policy and charging control framework for NGC.
CT4 has a technical report on protocol aspects for NGC in TR 29.891.

Your draft needs to describe how it fits in the 5G architecture, right now it only addresses 4G.

Kalyani

-----Original Message-----
From: ila [mailto:[email-masked]] On Behalf Of Dino Farinacci
Sent: Monday, February 5, 2018 7:32 PM
To: Bogineni, Kalyani <[email-masked]>
Cc: Tom Herbert <[email-masked]>; [email-masked]; dmm <[email-masked]>; Sri Gundavelli (sgundave) <[email-masked]>
Subject: Re: [Ila] [E] Re: [DMM] Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

Dino
_______________________________________________
ila mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ila&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=IdiSODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT&m=zf1KfRu4nUFsUT8IJVExPygA_iAC-h4BErkY_CE2ugM&s=oLQOKLOAxuYtjVD_qWMbiQjkmP9acy6Au0X6lpSiBvg&e=

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 6 Feb 2018 01:27:57 +0000

I suspect there might be a need for a new interface.

Assuming the LISP mapping system stays in the control plane, next to
SMF/AMF, and the xTR functions on the UPF, there needs to be probably a
new interface along the lines of the N4, for managing the LISP MAP
operations (Reg/Req/Reply/Notify..).  But, off course if the mapping
system stays in the user-plane, may be there is just interworking with the
3GPP authentication interfaces.

Sri

On 2/5/18, 5:15 PM, "Bogineni, Kalyani"
<[email-masked]> wrote:

>Dino:
>
>Please look at 3GPP TS 23.501 to understand the architecture of NGC. We
>tried to explain that in the White paper.
>Cc: Tom Herbert <[email-masked]>; [email-masked]; dmm <[email-masked]>;
>Sri Gundavelli (sgundave) <[email-masked]>
>> On Feb 6, 2018, at 5:04 AM, Bogineni, Kalyani
>><[email-masked]> wrote:
>> 
>> Dino:
>> 
>Can you be more specific in what you¹d like to see in the new section?
>
>There are references throughout the draft where you see eNodeB and pGW
>that UPF functionality could be at the same network mode location.
>
>Dino
>https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_
>listinfo_ila&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=IdiS
>ODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT&m=zf1KfRu4nUF
>sUT8IJVExPygA_iAC-h4BErkY_CE2ugM&s=oLQOKLOAxuYtjVD_qWMbiQjkmP9acy6Au0X6lpS
>iBvg&e=

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 5 Feb 2018 18:42:25 -0800

I don’t know what you mean. If you put the xTR function on an UPF, then by LISP spec definition, Map-Request, Map-Reply, and Map-Register functionality is part of the UPF.

Dino

> On Feb 5, 2018, at 5:27 PM, Sri Gundavelli (sgundave) <[email-masked]> wrote:
>

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 5 Feb 2018 18:44:21 -0800

> Your draft needs to describe how it fits in the 5G architecture, right now it only addresses 4G.

This whitepaper (attached below) indicates how draft-farinacci-lisp-mobile-network fits into the 5G architecture. First of all, do you agree with it? And if so, do you think that information be put in a new section?

Dino

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 6 Feb 2018 02:47:50 +0000

Sure, but I assume the mapping table/DB is some where else in some central
location and not on the UPF?

The question is how does the UPF fetch that entry and if the interface for
that query is built on some 3GPP interface, or its internal to LISP with
no bearing on the access technology.

Sri

On 2/5/18, 6:42 PM, "Dino Farinacci" <[email-masked]> wrote:

>I don’t know what you mean. If you put the xTR function on an UPF, then
>by LISP spec definition, Map-Request, Map-Reply, and Map-Register
>functionality is part of the UPF.
>
>Dino
>
>>> TS 23.502 has the procedures for the NGC. TS 23.503 specifies the
>>>policy
>>> and charging control framework for NGC.

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 5 Feb 2018 18:52:40 -0800

> location and not on the UPF?

True.

> no bearing on the access technology.

The UPF sends IP packets. The UPF is part of the NGC core, right? So the packets from the UPF get to a map-resolver and map-server via IP. It’s pretty simple. At least it should be.

Dino

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 6 Feb 2018 03:06:40 +0000

> The UPF sends IP packets. The UPF is part of the NGC core, right? So the
>packets from the UPF get to a map-resolver and map-server via IP. It’s
>pretty simple. At least it should be.

Sure, that LISP control plane packet is an IP packet. But, every message
that is going between CP and UP will be named and numbered in 3GPP specs,
and so said in my first mail that its probably a new interface specific to
LISP.

With any of the IETF protocols, PMIPv6/LISP/ILA, it can be argued that
these are IP packets. But, we should note that there is interworking
needed with the 3GPP authentication infrastructure, and the protocol
specific control plane. Note that these protocols are not doing MN
identity establishment. May be I could be wrong here on the assumptions
you have around LISP MN capabilities, but to me MN is a standard 3GPP UE
with no special capabilities such as MIPv6/LISP MN stack.

Sri

On 2/5/18, 6:52 PM, "Dino Farinacci" <[email-masked]> wrote:

>The UPF sends IP packets. The UPF is part of the NGC core, right? So the
>packets from the UPF get to a map-resolver and map-server via IP. It’s
>pretty simple. At least it should be.
>
>Dino
>
>> 
>> Sri
>> 
>> 
>> 
>>>>> Your draft needs to describe how it fits in the 5G architecture,
>>>>>right
>>>>> now it only addresses 4G.
>>>>> 
>>>>> Kalyani
>>>>> 
>>>>> 
>>>>> 
>>>>>https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
>>>>>ma
>>>>> n_
>>>>> 
>>>>> 
>>>>>listinfo_ila&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=
>>>>>Id
>>>>> iS
>>>>> 
>>>>> 
>>>>>ODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT&m=zf1KfRu
>>>>>4n
>>>>> UF
>>>>> 
>>>>> 
>>>>>sUT8IJVExPygA_iAC-h4BErkY_CE2ugM&s=oLQOKLOAxuYtjVD_qWMbiQjkmP9acy6Au0X
>>>>>6l
>>>>> pS
>>>>> iBvg&e=
>>>> 
>>> 
>> 
>

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 5 Feb 2018 19:11:19 -0800

> with no special capabilities such as MIPv6/LISP MN stack.

The draft draft-ietf-lisp-mn proposes LISP on the UE. That is not what we are proposing for the 3GPP 5G architecture. The draft draft-farinacci-lisp-mobile-network proposes LISP in the eNodeB/UPF and pGW. 

Enclosed is a pointer to the presntation I gave in the LISP WG and 5gangip in Singapore.

Dino

https://www.dropbox.com/s/scmc6eeqyzwme5o/lisp-mobile-network-ietf-sin.pdf

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 6 Feb 2018 13:52:22 +0900

> protocol for the 3GPP "Study on User Plane Protocol in 5GC".

Echoing Tom's earlier comment about this: I think the address assignment
sections (6.3 and 8.3) should be reworded to clarify that for general
purpose hosts, best practice is not to use singleton addresses, but always
to provide a /64 prefix.

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 6 Feb 2018 05:07:42 +0000

> best practice is not to use singleton addresses, but always to provide a /64 prefix.

But, how does that work with ILA's approach of identifier management?  With the previously IETF recommended approaches in RFC5213 and even in 3GPP architecture, per RFC3315, the network assigned  a set of unique prefixes for each MN, allowed the MN to generate the identifiers.  Even CGA addressing worked with the per-MN prefix model.

But, with ILA there is no concept of prefix assignment. Will ILA network now generate a identifier block for each MN?  Is DHCPv6 the only approach?

If that block is not summarizable, will it not result in mapping table size getting multiple many times?

Sri

From: dmm <[email-masked]<mailto:[email-masked]>> on behalf of Lorenzo Colitti <[email-masked]<mailto:[email-masked]>>
Date: Monday, February 5, 2018 at 8:52 PM
To: Tom Herbert <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, dmm <[email-masked]<mailto:[email-masked]>>
Subject: Re: [DMM] Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

On Fri, Feb 2, 2018 at 6:27 AM, Tom Herbert <[email-masked]<mailto:[email-masked]>> wrote:
We like like to request that the dmm WG consider ILA as a candidate
protocol for the 3GPP "Study on User Plane Protocol in 5GC".

Echoing Tom's earlier comment about this: I think the address assignment sections (6.3 and 8.3) should be reworded to clarify that for general purpose hosts, best practice is not to use singleton addresses, but always to provide a /64 prefix.

---

From: Tom Herbert <[email-masked]>
Date: Mon, 5 Feb 2018 21:13:23 -0800

On Mon, Feb 5, 2018 at 9:07 PM, Sri Gundavelli (sgundave) <
[email-masked]> wrote:

> But, how does that work with ILA's approach of identifier management?
> With the previously IETF recommended approaches in RFC5213 and even in 3GPP
> architecture, per RFC3315, the network assigned  a set of unique prefixes
> for each MN, allowed the MN to generate the identifiers.  Even CGA
> addressing worked with the per-MN prefix model.
>
> But, with ILA there is no concept of prefix assignment. Will ILA network
> now generate a identifier block for each MN?  Is DHCPv6 the only approach?
>
> Sri, see section 6.3.2. That describes encoding the identifier in the
upper sixty-four bits and using an indirection table to accommodate network
prefixes.

Tom

If that block is not summarizable, will it not result in mapping table size
> getting multiple many times?
>
>
> Sri
>
>
>
>
>
> From: dmm <[email-masked]> on behalf of Lorenzo Colitti <
> [email-masked]>
> To: Tom Herbert <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, dmm <[email-masked]>

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 6 Feb 2018 14:15:28 +0900

> upper sixty-four bits and using an indirection table to accommodate network

Hence the request: either make that the only text in section 6.3, or
clearly state that singleton addresses are not recommended by IETF best
practices. And more in general, assume that best practices are followed,
and explain how the proposed scheme will follow them. At the moment, this
scheme seems little more than an afterthought.

---

From: Tom Herbert <[email-masked]>
Date: Mon, 5 Feb 2018 21:17:51 -0800

> purpose hosts, best practice is not to use singleton addresses, but always

Lorenzo,

Section 8.3 provides the argument that singleton addresses are needed for
privacy-sensitive communications. For practicality and probably scaling /64
is needed, however for strong privacy singleton addresses would be needed
(to avoid resorting to NAT).

I'm not sure a best practice can be defined here since it may depend on the
application context.

Tom

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 6 Feb 2018 14:22:06 +0900

> (to avoid resorting to NAT).

You don't need singletons for privacy. You can just assign /64s that change
over time.

> I'm not sure a best practice can be defined here since it may depend on
> the application context.
>

There already is a best practice. It's written down in RFC 7934.

---

From: Tom Herbert <[email-masked]>
Date: Mon, 5 Feb 2018 22:02:10 -0800

On Mon, Feb 5, 2018 at 9:22 PM, Lorenzo Colitti <[email-masked]> wrote:

> You don't need singletons for privacy. You can just assign /64s that
> change over time.
>

Yes, that seems to be the recommendation of RFC4914. However, neither that
RFC nor anyone else that I can tell has been able to quantitatively
describe the relationship between frequency of changing prefix and privacy.
Any statements about this are qualitative in nature. By intuition, it might
be believable that higher frequency should mean better privacy, but nobody
can quantify that. So for a user where privacy is paramount, my example is
a political dissident that is anonymously criticizing their government,
there is no definitive answer to give then when they ask what frequency
they need to ensure their privacy. Besides that, I believe that any
frequency could be defeated with the postulated exploit below (if you see a
flaw in this logic please let me know).

Actually, there is one frequency where the privacy effects can be
qualified: that is to use a different address per connection. This is
effectively what stateful NAT provides and why law enforcement doesn't like
it. With a large enough pool of users behind a NAT, flows sourced form the
same device cannot be correlated by a third party in external network. This
is strong privacy privacy in addressing (properties listed in 8.3). In lieu
of telling the political dissident to find a provider using NAT, assigning
addresses for singe use can provide it. Assigning a /64 to every flow won't
scale, but singleton addresses could.

----

The following exploit is proposed to defeat the privacy goal of periodic
address rotation:

   -

   The attacker creates an “always connected” app that provides some
   seemingly benign service and users download the app.
   -

   The app includes some sort of persistent identity. For instance, this
   could be a login to account.
   -

   The backend server for the app logs the user identity and IP address
   they are using each time they connect.
   -

   When an address change happens, existing connections on the user device
   are disconnected. The app will receive a notification and immediately
   attempt to reconnect using the new source address.
   -

   The backend server will see the new connection and log the new IP
   address as being used by the user.
   -

   Thus, the server has a real-time record of users and the IP address they
   are using.
   -

   The attacker gains access to packet traces taken at some point in the
   Internet. The addresses in the captured packets can be time correlated with
   the server database to deduce the identity of the source of packets for
   flows communications unrelated to the app.

Tom

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 6 Feb 2018 15:16:50 +0900

On Tue, Feb 6, 2018 at 3:02 PM, Tom Herbert <[email-masked]> wrote:

>>> Section 8.3 provides the argument that singleton addresses are needed
>>> for privacy-sensitive communications. For practicality and probably scaling
>>> /64 is needed, however for strong privacy singleton addresses would be
>>> needed (to avoid resorting to NAT).
>>>
>>

In general, any scheme that relies in changing singletons can be
implemented by changing /64 prefixes in the same way.

Your example of a dissident that is criticizing the government is not a
relevant one in the likely case that the government has the power to compel
the network operator to log all the singletons that the network assigns.

> scale, but singleton addresses could.

Saying that assigning unaggregatable singleton addresses to each flow would
scale is an extremely bold statement. Back-of-the-envelope says that with
100M devices and an average of 10 flows per device that last 5 minutes on
average you've got 1B entries and 3.3 milion flow updates per second. That
amount of state must be available within a reasonable time (line rate, or,
say, 1 RTT) to any border router that could conceivably receive a packet
for any one of those flows. I don't know what sort of hardware you'd be
able to run that on, nor who would want to make such a colossal
infrastructure investment even if it could be done.

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 6 Feb 2018 06:25:54 +0000

Tom:

Thanks! That sounds like some  interesting trick. But, let me make sure I understood this correctly.  So, the identifier space for the MN is encoded in the upper 64-bits. Now, the UE can use those bits to generate any Identifier from that space, and use it with the SIR prefix to form the 128 bit address.  Bear with me, let me use an example

MN1 is assigned a prefix  2001:ABCD:CAFÉ:   / 48
MN2 is assigned a prefix  2001:ABCD:FOOD:  /48

The SIR Prefix for that ILA domain is  2001:DB8::/64

So, the SIR Addresses can be formed using the  16-bit identifier space left from the /48 prefix assignment? UE can form any identifier from bit space?

I can't figure out the scheme from this below text in 6.3.2. I think I am missing the context here. May be you guys discussed this before.

----

   To support /64 prefix assignment with ILA, the ILA identifier can be
   encoded in the the upper sixty-four bits of an address and the lower

   sixty-four bits are ignored by ILA. Since only a subset of bits are
   available, a level of indirection can be used so that ILA transforms
   the upper sixty four bits to contain both a locator and an index into
   a locator (ILA-N) specific table. The entry in the table provides the
   original sixty-four bit prefix so that ILA to SIR address
   transformation can be done.

-----

From: Tom Herbert <[email-masked]<mailto:[email-masked]>>
Date: Monday, February 5, 2018 at 9:13 PM
To: Sri Gundavelli <[email-masked]<mailto:[email-masked]>>
Cc: Lorenzo Colitti <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, dmm <[email-masked]<mailto:[email-masked]>>
Subject: Re: [DMM] Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

Sri, see section 6.3.2. That describes encoding the identifier in the upper sixty-four bits and using an indirection table to accommodate network prefixes.

Tom

Sri

---

From: "Bogineni, Kalyani" <[email-masked]>
Date: Tue, 6 Feb 2018 13:03:26 +0000

Dino:

This paper does describe the architecture. This information in a section would help and also explain what is different between
LISP and ILSR. Figure 3 shows SMF for ILSR, AMF+, Nsmf+, Namf+, and ILSR4. You can explain what the '+' means and what the
new functionalities in SMF for ILSR are and what ILSR4 is (is it a variant of N4/Sx - PFCP in 29.244).

Kalyani

-----Original Message-----
From: Dino Farinacci [mailto:[email-masked]] 
Sent: Monday, February 5, 2018 9:44 PM
To: Bogineni, Kalyani <[email-masked]>
Cc: Tom Herbert <[email-masked]>; [email-masked]; dmm <[email-masked]>; Sri Gundavelli (sgundave) <[email-masked]>
Subject: Re: [Ila] [E] Re: [DMM] Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 6 Feb 2018 22:06:25 +0900

The other authors can comment but to me ILSR and LISP are the same thing. 

ILSR is an architecture that can use the LISP protocol set. 

Dino

> On Feb 6, 2018, at 10:03 PM, Bogineni, Kalyani <[email-masked]> wrote:
> 
> Dino:
>

---

From: Marco Liebsch <[email-masked]>
Date: Tue, 6 Feb 2018 17:09:27 +0000

It could be a nice option to keep the data plane specific control (the mapping DB you refer to) in the user plane and
take a common N4 to update the mapping DB in case of mobility. But I think that clashes with the clear data plane / control plane
separation in nextgen. And: there may be data plane solutions which don't come with a control plane / mapping system. For these
the N4 needs to disseminate complete forwarding states (an more, e.g. for chargeable event monitoring, device dormancy support etc.)
to all relevant data plane nodes, means the ones that hold a state for the mobile. 

Btw, in terms of compatibility with nextgen, so far N4 is terminated only in few types of core data plane nodes with a
dedicated role. We may investigate options to push forwarding and further policies from the (nextgen) control plane to other
data plane nodes which don't terminate N4. 

marco

-----Original Message-----
From: dmm [mailto:[email-masked]] On Behalf Of Sri Gundavelli (sgundave)
Sent: Dienstag, 6. Februar 2018 04:07
To: Dino Farinacci
Cc: dmm; [email-masked]
Subject: Re: [DMM] [Ila] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

> The UPF sends IP packets. The UPF is part of the NGC core, right? So 
>the packets from the UPF get to a map-resolver and map-server via IP. 
>It's pretty simple. At least it should be.

Sure, that LISP control plane packet is an IP packet. But, every message that is going between CP and UP will be named and numbered in 3GPP specs, and so said in my first mail that its probably a new interface specific to LISP.

With any of the IETF protocols, PMIPv6/LISP/ILA, it can be argued that these are IP packets. But, we should note that there is interworking needed with the 3GPP authentication infrastructure, and the protocol specific control plane. Note that these protocols are not doing MN identity establishment. May be I could be wrong here on the assumptions you have around LISP MN capabilities, but to me MN is a standard 3GPP UE with no special capabilities such as MIPv6/LISP MN stack.

Sri

On 2/5/18, 6:52 PM, "Dino Farinacci" <[email-masked]> wrote:

>> Sure, but I assume the mapping table/DB is some where else in some 
>>central  location and not on the UPF?
>
>True.
>
>> The question is how does the UPF fetch that entry and if the 
>>interface for  that query is built on some 3GPP interface, or its 
>>internal to LISP with  no bearing on the access technology.
>
>The UPF sends IP packets. The UPF is part of the NGC core, right? So 
>the packets from the UPF get to a map-resolver and map-server via IP. 
>It's pretty simple. At least it should be.
>
>Dino
>
>> 
>> Sri
>> 
>> 
>> 
>>> I don't know what you mean. If you put the xTR function on an UPF, 
>>> then by LISP spec definition, Map-Request, Map-Reply, and 
>>> Map-Register functionality is part of the UPF.
>>> 
>>> Dino
>>> 
>>>> Assuming the LISP mapping system stays in the control plane, next 
>>>>to  SMF/AMF, and the xTR functions on the UPF, there needs to be 
>>>>probably a  new interface along the lines of the N4, for managing 
>>>>the LISP MAP  operations (Reg/Req/Reply/Notify..).  But, off course 
>>>>if the mapping  system stays in the user-plane, may be there is just 
>>>>interworking with  the  3GPP authentication interfaces.
>>>> 
>>>> Sri
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>>>policy  and charging control framework for NGC.
>>>>>right  now it only addresses 4G.
>>>>> 
>>>>> Kalyani
>>>>> 
>>>>> 
>>>>> 
>>>>> Cc: Tom Herbert <[email-masked]>; [email-masked]; dmm 
>>>>><[email-masked]>;  Sri Gundavelli (sgundave) <[email-masked]>
>>>>> There are references throughout the draft where you see eNodeB and 
>>>>>pGW  that UPF functionality could be at the same network mode 
>>>>>location.
>>>>> 
>>>>> Dino

---

From: Tom Herbert <[email-masked]>
Date: Tue, 6 Feb 2018 10:30:20 -0800

On Mon, Feb 5, 2018 at 10:16 PM, Lorenzo Colitti <[email-masked]> wrote:

>> Yes, that seems to be the recommendation of RFC4914. However, neither
>> that RFC nor anyone else that I can tell has been able to quantitatively

The number of unique /64 prefixes a network could assign for this purpose
is much less than 2^64 due to network prefix and a prefix needed for
internal routing.

> relevant one in the likely case that the
>

Consider that the dissident might be exiled in a country that is
sympathetic to their cause, and the government being criticized has no
control over the local provider. There are several famous individuals for
which this is true, protecting their anonymity and location may be a matter
life and death.

> government has the power to compel the network operator to log all the
> singletons that the network assigns.
>
>
Then the government should have the power to compel an operator to log NAT
mappings, but apparently that hasn't happened or isn't sufficient for what
law enforcement thinks they need. I suspect that the primary reason that LI
wants trackable addresses in the Internet is to perform mass passive
surveillance on transit networks in their jurisdiction to deduce criminal
networks and intent.

> Saying that assigning unaggregatable singleton addresses to each flow
> would scale is an extremely bold statement. Back-of-the-envelope says that
> with 100M devices and an average of 10 flows per device that last 5 minutes
> on average you've got 1B entries and 3.3 milion flow updates per second.
> That amount of state must be available within a reasonable time (line rate,
> or, say, 1 RTT) to any border router that could conceivably receive a
> packet for any one of those flows. I don't know what sort of hardware you'd
> be able to run that on, nor who would want to make such a colossal

Here are some mitigating factors for scaling issue:

1) Not all communications require strong privacy, so they all don't need
singleton addresses.
2) The amount of state is equal, or at least proportional, to that in a
network using NAT today. Scaling single use addresses then scales as much
as NAT scales.
3) As pointed out in section 8.3 it is conceivable that crypto-graphic
addresses might be used that would allow a method of address aggregation
that a provider network knows about but is hidden to the rest of the world.
I think this possibility is worth investigation.

Tom

---

From: Tom Herbert <[email-masked]>
Date: Tue, 6 Feb 2018 11:04:49 -0800

HI Sri,

On Mon, Feb 5, 2018 at 10:25 PM, Sri Gundavelli (sgundave) <
[email-masked]> wrote:

> Tom:
>
> Thanks! That sounds like some  interesting trick. But, let me make sure I
> understood this correctly.  So, the
>
identifier space for the MN is encoded in the upper 64-bits. Now, the UE
> can use those bits to generate any Identifier from that space, and use it
> with the SIR prefix to form the 128 bit address.  Bear with me, let me use
> an example
>
> MN1 is assigned a prefix  *2001:ABCD:CAFÉ*:   / 48
> MN2 is assigned a prefix  *2001:ABCD:FOOD*:  /48
>
> So, the SIR Addresses can be formed using the  16-bit identifier space
> left from the /48 prefix assignment? UE can form any identifier from bit
> space?
>
> No, we want allow a full /64 assignment since that is being already
deployed.

> I can’t figure out the scheme from this below text in 6.3.2. I think I am
> missing the context here. May be you guys discussed this before.
>

----
>    transformation can be done.
The SIR prefix and identifier are encoded in the upper 64 bits. Assuming
the network has a /24, and address for /64 assignment might have this
format.

Network                    SIR/identifier                 IID
    24 bits                   40 bits                           64 bits
------------------------|------------------------------|--------------------------------------------------|

The IID part is arbitrarily assigned by the device, so that is ignored by
ILA. All routing, lookups, and transformations (excepting checksum neutral
mapping)  are based in upper sixty-four bits.

For SIR->ILA  transformation, a lookup is done on the upper sixty four
bits. That returns a locator that would have format something like:

 Network                   Locator                 Locator_index

    24 bits                   20 bits                  20 bits
------------------------|-----------------------|--------------------------|

The packet is forwarded and routed to the ILA addressed by locator (/44
route). ILA, the locator index is used as a key to an ILA-N specific  table
that returns the 40 bit SIR/identifier. This value is then written in the
packet do ILA->SIR transformation thereby restoring the original address.

The locator index is not globally unique, it is specific to each ILA-N.
When a node attaches to an ILA-N, an index is chosen so that the table is
populated at the ILA-N and the ILA mapping includes the locator and index.
When a node detaches from on ILA, it's entry in the table is removed and
the index can be reused after a holddown period to purge stale mappings.

Tom

> From: Tom Herbert <[email-masked]>
> To: Sri Gundavelli <[email-masked]>
> Cc: Lorenzo Colitti <[email-masked]>, "[email-masked]" <[email-masked]>,
> dmm <[email-masked]>

---

From: "Bogineni, Kalyani" <[email-masked]>
Date: Tue, 6 Feb 2018 21:23:31 +0000

Marco, Sri:

Here is the services based 5G architecture.

SMF is a control plane entity and talks to the User plane functions (UPF) through N4 interface as specified in 3GPP TS 29.244.

Here are two variants:

Option 1: Mapping DB talks to the UPFs using a variant of N4 possibly.

Option 2: Here there is no direct interface between Mapping Db and UPFs. UPFs also support APIs like the control plane functions.

The architecture is extensible and additional control plane or user plane functions can be added.

Is this what you had in mind?

Kalyani

-----Original Message-----
From: ila [mailto:[email-masked]] On Behalf Of Marco Liebsch
Sent: Tuesday, February 6, 2018 12:09 PM
To: Sri Gundavelli (sgundave) <[email-masked]>; Dino Farinacci <[email-masked]>
Cc: [email-masked]; dmm <[email-masked]>
Subject: Re: [Ila] [DMM] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

It could be a nice option to keep the data plane specific control (the mapping DB you refer to) in the user plane and take a common N4 to update the mapping DB in case of mobility. But I think that clashes with the clear data plane / control plane separation in nextgen. And: there may be data plane solutions which don't come with a control plane / mapping system. For these the N4 needs to disseminate complete forwarding states (an more, e.g. for chargeable event monitoring, device dormancy support etc.) to all relevant data plane nodes, means the ones that hold a state for the mobile.

Btw, in terms of compatibility with nextgen, so far N4 is terminated only in few types of core data plane nodes with a dedicated role. We may investigate options to push forwarding and further policies from the (nextgen) control plane to other data plane nodes which don't terminate N4.

marco

-----Original Message-----

To: Dino Farinacci

Cc: dmm; [email-masked]<mailto:[email-masked]>

Sri

>> On 2/5/18, 6:42 PM, "Dino Farinacci" <[email-masked]<mailto:[email-masked]>> wrote:

>>>> On Feb 5, 2018, at 5:27 PM, Sri Gundavelli (sgundave)

>>>> <[email-masked]<mailto:[email-masked]>> wrote:

>>>> <[email-masked]<mailto:[email-masked]>> wrote:

>>>>> Please look at 3GPP TS 23.501 to understand the architecture of NGC.

>>>>>We

>>>>> From: ila [mailto:[email-masked]] On Behalf Of Dino

>>>>>Farinacci

>>>>> To: Bogineni, Kalyani <[email-masked]<mailto:[email-masked]>>

>>>>> Cc: Tom Herbert <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; dmm

>>>>><[email-masked]<mailto:[email-masked]>>;  Sri Gundavelli (sgundave) <[email-masked]<mailto:[email-masked]>>

>>>>> Subject: Re: [Ila] [E] Re: [DMM] Fwd: New Version Notification for

>>>>>draft-herbert-ila-mobile-00.txt

>>>>>> <[email-masked]<mailto:[email-masked]>> wrote:

>>>>>> Can you add a section to show how this proposal would fit in 5G

>>>>>> architecture?

>>>>> Can you be more specific in what you¹d like to see in the new

>>>>>section?

>>>>> [email-masked]<mailto:[email-masked]>

>>>>>https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_m

>>>>>ail

>>>>>listinfo_ila&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ

>>>>>&r=

>>>>>ODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT&m=zf1K

>>>>>fRu

>>>>>sUT8IJVExPygA_iAC-h4BErkY_CE2ugM&s=oLQOKLOAxuYtjVD_qWMbiQjkmP9acy6A

>>>>>u0X

dmm mailing list

[email-masked]<mailto:[email-masked]>

https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_dmm&d=DwIFAw&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=IdiSODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT&m=lWGVj8Jd11JyGVLcPLOSIxTZ-YHY3VbtfD1mi2uqhOY&s=-EIvAEYOQusoChy_iwtR4nMkaEqRKBTKTJ8GDjADuCk&e=

ila mailing list

[email-masked]<mailto:[email-masked]>

https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ila&d=DwIFAw&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=IdiSODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT&m=lWGVj8Jd11JyGVLcPLOSIxTZ-YHY3VbtfD1mi2uqhOY&s=cwX6UkOqq2vREiCvsQ7GPBXgKsinbkDmmckbpGwi73o&e=

---

From: Marco Liebsch <[email-masked]>
Date: Tue, 6 Feb 2018 22:09:59 +0000

Hi Kalyani,

my current take is to keep the data plane independent of a specific mapping base. Even if it comes with an extended control plane per the two options that you draw, I personally don’t think that SMF and UPF/Data Plane should communicate through the service-based architecture.

marco

On 6. Feb 2018, at 22:30, Bogineni, Kalyani <[email-masked]<mailto:[email-masked]>> wrote:

Marco, Sri:

Here are two variants:

Kalyani

-----Original Message-----
From: ila [mailto:[email-masked]] On Behalf Of Marco Liebsch
Sent: Tuesday, February 6, 2018 12:09 PM
To: Sri Gundavelli (sgundave) <[email-masked]<mailto:[email-masked]>>; Dino Farinacci <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; dmm <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Ila] [DMM] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

marco

-----Original Message-----

To: Dino Farinacci

Sri

dmm mailing list

ila mailing list

---

From: "Bogineni, Kalyani" <[email-masked]>
Date: Wed, 7 Feb 2018 02:56:27 +0000

Marco:

Response Inline

From: Marco Liebsch [mailto:[email-masked]]
Sent: Tuesday, February 6, 2018 5:10 PM
To: Bogineni, Kalyani <[email-masked]>
Cc: Sri Gundavelli (sgundave) <[email-masked]>; Dino Farinacci <[email-masked]>; [email-masked]; dmm <[email-masked]>
Subject: Re: [Ila] [DMM] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

Hi Kalyani,

my current take is to keep the data plane independent of a specific mapping base. Even if it comes with an extended control plane per the two options that you draw, I personally don't think that SMF and UPF/Data Plane should communicate through the service-based architecture.
[KB] Does this mean you prefer option 1 because option 2 shows APIs from both UPFs and Mapping DB to the services based interfaces?

marco

Marco, Sri:

Here are two variants:

Kalyani

-----Original Message-----
From: ila [mailto:[email-masked]] On Behalf Of Marco Liebsch
Sent: Tuesday, February 6, 2018 12:09 PM
To: Sri Gundavelli (sgundave) <[email-masked]<mailto:[email-masked]>>; Dino Farinacci <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; dmm <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Ila] [DMM] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

marco

-----Original Message-----

To: Dino Farinacci

Sri

dmm mailing list

ila mailing list

---

From: Marco Liebsch <[email-masked]>
Date: Wed, 7 Feb 2018 08:39:58 +0000

Kalyani, even with Option 1 I see much impact on the control plane as it implies that SMF offers/uses service to/from the Mapping DB utilizing the service-based interfaces.
My comment was more about whether we need or should introduce a new building block into the control plane at all.

marco

From: Bogineni, Kalyani [mailto:[email-masked]]
Sent: Mittwoch, 7. Februar 2018 03:56
To: Marco Liebsch
Cc: Sri Gundavelli (sgundave); Dino Farinacci; [email-masked]; dmm
Subject: RE: [Ila] [DMM] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

Marco:

Response Inline

Cc: Sri Gundavelli (sgundave) <[email-masked]<mailto:[email-masked]>>; Dino Farinacci <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; dmm <[email-masked]<mailto:[email-masked]>>

Hi Kalyani,

marco

Marco, Sri:

Here are two variants:

Kalyani

-----Original Message-----
From: ila [mailto:[email-masked]] On Behalf Of Marco Liebsch
Sent: Tuesday, February 6, 2018 12:09 PM
To: Sri Gundavelli (sgundave) <[email-masked]<mailto:[email-masked]>>; Dino Farinacci <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; dmm <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Ila] [DMM] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

marco

-----Original Message-----

To: Dino Farinacci

Sri

dmm mailing list

ila mailing list

---

From: "Bogineni, Kalyani" <[email-masked]>
Date: Wed, 7 Feb 2018 13:20:04 +0000

Marco:

I think you are talking about 2 features: one for mobility that needs the database; another for non-mobility state transfer
between user plane nodes (not necessarily mobility nodes).

Kalyani

From: ila [mailto:[email-masked]] On Behalf Of Marco Liebsch
Sent: Wednesday, February 7, 2018 3:40 AM
To: Bogineni, Kalyani <[email-masked]>
Cc: [email-masked]; dmm <[email-masked]>; Dino Farinacci <[email-masked]>; Sri Gundavelli (sgundave) <[email-masked]>
Subject: Re: [Ila] [DMM] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

marco

From: Bogineni, Kalyani [mailto:[email-masked]]
Sent: Mittwoch, 7. Februar 2018 03:56
To: Marco Liebsch
Cc: Sri Gundavelli (sgundave); Dino Farinacci; [email-masked]<mailto:[email-masked]>; dmm
Subject: RE: [Ila] [DMM] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

Marco:

Response Inline

Hi Kalyani,

marco

Marco, Sri:

Here are two variants:

Kalyani

-----Original Message-----
From: ila [mailto:[email-masked]] On Behalf Of Marco Liebsch
Sent: Tuesday, February 6, 2018 12:09 PM
To: Sri Gundavelli (sgundave) <[email-masked]<mailto:[email-masked]>>; Dino Farinacci <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; dmm <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Ila] [DMM] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

marco

-----Original Message-----

To: Dino Farinacci

Sri

dmm mailing list

ila mailing list

---

From: Arashmid Akhavain <[email-masked]>
Date: Wed, 7 Feb 2018 16:14:05 +0000

The database is simply a vehicle to locate UPFs in the network. As UPFs move around,  the database gets updated and notifies other UPFs
that are interested to receive this information. The records could be of course augmented to store additional information.

Option 1 might require changes to N4. But given the small number of required instructions, I don't think these changes will be significant.

Options 2 will use the APIs which I think is a more flexible and perhaps easier. The mapping database (in a distributed model which I think need to be used in MN) will also use this method to synchronise its nodes, load balance, etc. We don't need any special interface here.

Kalyani, you talked about non-mobility state transfer between the UPFs. Wouldn't this info. use the established data path between the UPFs (i.e. N9)?

Arashmid

From: dmm [mailto:[email-masked]] On Behalf Of Bogineni, Kalyani
Sent: 07 February 2018 08:20
To: Marco Liebsch <[email-masked]>
Cc: [email-masked]; dmm <[email-masked]>
Subject: Re: [DMM] [Ila] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

Marco:

Kalyani

Cc: [email-masked]<mailto:[email-masked]>; dmm <[email-masked]<mailto:[email-masked]>>; Dino Farinacci <[email-masked]<mailto:[email-masked]>>; Sri Gundavelli (sgundave) <[email-masked]<mailto:[email-masked]>>

marco

Marco:

Response Inline

Hi Kalyani,

marco

Marco, Sri:

Here are two variants:

Kalyani

-----Original Message-----
From: ila [mailto:[email-masked]] On Behalf Of Marco Liebsch
Sent: Tuesday, February 6, 2018 12:09 PM
To: Sri Gundavelli (sgundave) <[email-masked]<mailto:[email-masked]>>; Dino Farinacci <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; dmm <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Ila] [DMM] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

marco

-----Original Message-----

To: Dino Farinacci

Sri

dmm mailing list

ila mailing list

---

From: "Bogineni, Kalyani" <[email-masked]>
Date: Wed, 7 Feb 2018 16:20:45 +0000

Arashmid - response inline

From: ila [mailto:[email-masked]] On Behalf Of Arashmid Akhavain
Sent: Wednesday, February 7, 2018 11:14 AM
To: Bogineni, Kalyani <[email-masked]>; Marco Liebsch <[email-masked]>
Cc: [email-masked]; dmm <[email-masked]>
Subject: Re: [Ila] [DMM] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

Kalyani, you talked about non-mobility state transfer between the UPFs. Wouldn't this info. use the established data path between the UPFs (i.e. N9)?
[KB] I was trying to understand what Marco meant by the text in his email that I highlighted in yellow.

Arashmid

To: Marco Liebsch <[email-masked]<mailto:[email-masked]>>

Marco:

Kalyani

marco

Marco:

Response Inline

Hi Kalyani,

marco

Marco, Sri:

Here are two variants:

Kalyani

-----Original Message-----
From: ila [mailto:[email-masked]] On Behalf Of Marco Liebsch
Sent: Tuesday, February 6, 2018 12:09 PM
To: Sri Gundavelli (sgundave) <[email-masked]<mailto:[email-masked]>>; Dino Farinacci <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; dmm <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Ila] [DMM] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

marco

-----Original Message-----

To: Dino Farinacci

Sri

dmm mailing list

ila mailing list

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 7 Feb 2018 17:49:22 +0100

Le 06/02/2018 à 05:52, Lorenzo Colitti a écrit :
> purpose hosts, best practice is not to use singleton addresses, but 
> always to provide a /64 prefix.

I would say a prefix yes, but prefer a /63 and shorter.

Alex

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Wed, 7 Feb 2018 17:23:02 +0000

Hi Kalyani,

For all the approaches that we are talking (ILA, LISP, SRv6 ..etc), there are two nodes that's where the translation/tunneling is happening. In a generic sense, it could be a layer-2 termination point, a first-hop router, or a transit router. When seen from 3GPP lens, there is only UPF and the N4 interface that you talk about. But, there is N3 (eNB to UPF) and then there are also other nodes where there is an impact.  The translation/tunneling/steering may very well happen on some router connected to the service cloud/core (on N6),  or at some exit router where there is no 3GPP UPF function and there is no N4.

So, there are two key questions here:

1.) Is the UPF only node that is impacted here? Is the assumption that these protocols are doing some translation/tunneling only on UPF node? Or, we can introduce a two types of IP forwarding nodes, one collocated with UPF and another without UPF. I know how this discussion will go in 3GPP; they will insist and say they we will never recognize any other node other what they created.

2.) Is N4 the only interface to these two types of node variants. Or we will have N4’ to these both types of nodes from some AF (which can interwork with the service bus), and we don’t’ touch N4.

Marco’s point is to keep this generic and not make this very UPF specific, as it will be too restrictive.

Sri

From: "Bogineni, Kalyani" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, February 6, 2018 at 1:23 PM
To: Marco Liebsch <[email-masked]<mailto:[email-masked]>>, Sri Gundavelli <[email-masked]<mailto:[email-masked]>>, Dino Farinacci <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, dmm <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Ila] [DMM] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

Marco, Sri:

Here are two variants:

Kalyani

-----Original Message-----
From: ila [mailto:[email-masked]] On Behalf Of Marco Liebsch
Sent: Tuesday, February 6, 2018 12:09 PM
To: Sri Gundavelli (sgundave) <[email-masked]<mailto:[email-masked]>>; Dino Farinacci <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; dmm <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Ila] [DMM] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

marco

-----Original Message-----

To: Dino Farinacci

Sri

dmm mailing list

ila mailing list

---

From: Tom Herbert <[email-masked]>
Date: Wed, 7 Feb 2018 09:29:41 -0800

On Wed, Feb 7, 2018 at 8:49 AM, Alexandre Petrescu <
[email-masked]> wrote:

>> On Fri, Feb 2, 2018 at 6:27 AM, Tom Herbert <[email-masked] <mailto:
>> [email-masked]>> wrote:
>>
> Alex,

I'm curious as to why you'd need even shorter prefixes. If a subnet is so
huge that it needs more than a /64, why not just give it a static prefix
allocation. ILA can be used independently within the subnet if desired.

Tom

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 7 Feb 2018 11:44:00 -0600

Hi Sri,

On Wed, Feb 7, 2018 at 11:23 AM, Sri Gundavelli (sgundave) <
[email-masked]> wrote:

> Hi Kalyani,
>
> For all the approaches that we are talking (ILA, LISP, SRv6 ..etc), there
> are two nodes that's where the translation/tunneling is happening. In a
> generic sense, it could be a layer-2 termination point, a first-hop router,
> or a transit router. When seen from 3GPP lens, there is only UPF and the N4
> interface that you talk about. But, there is N3 (eNB to UPF) and then there
> are also other nodes where there is an impact.  The
> translation/tunneling/steering may very well happen on some router
> connected to the service cloud/core (on N6),  or at some exit router where
> there is no 3GPP UPF function and there is no N4.
>
>
>
I find it a bit too simplistic to put these two words
translation / tunneling

in a sort of unifying manner.

I don't think the reality is that simple, especially when you talk to 3GPP
people.

In fact the translation or Id/Loc separation systems offer completely
different and whole new view of how the data plane will work than tunneling
which is the legacy technology.

On the other hand, draft-ietf-dmm-srv6-mobile-uplane-00 which was previously

draft-matsushima-spring-dmm-srv6-mobile-uplane-03

proposes a more efficient way of tunneling.
I don't see any discussion on the main subject, i.e. SRv6 mobile user plane
so far on this list and I am puzzled by that.

So my humble suggestion is to concentrate on the advantages and
disadvantages of SRv6 mobile user plane draft to 3GPP 4G (if there is time
maybe a bit of 5G). I assure you there is a lot of meat there which should
keep you busy for a long time.

Regards,
Behcet

> 1.) Is the UPF only node that is impacted here? Is the assumption that
> these protocols are doing some translation/tunneling only on UPF node? Or,
> we can introduce a two types of IP forwarding nodes, one collocated with
> UPF and another without UPF. I know how this discussion will go in 3GPP;
> they will insist and say they we will never recognize any other node other
> what they created.
>
> 2.) Is N4 the only interface to these two types of node variants. Or we
> will have N4’ to these both types of nodes from some AF (which can
> interwork with the service bus), and we don’t’ touch N4.
>
> From: "Bogineni, Kalyani" <[email-masked]>
> To: Marco Liebsch <[email-masked]>, Sri Gundavelli <
> [email-masked]>, Dino Farinacci <[email-masked]>
> SMF is a control plane entity and talks to the User plane functions (UPF)
> through N4 interface as specified in 3GPP TS 29.244.
>
>
>
> Here are two variants:
>
>
>
> Option 2: Here there is no direct interface between Mapping Db and UPFs.
> UPFs also support APIs like the control plane functions.
>
>
>
>
>
> From: ila [mailto:[email-masked] <[email-masked]>] On Behalf
> Of Marco Liebsch
> It could be a nice option to keep the data plane specific control (the
> mapping DB you refer to) in the user plane and take a common N4 to update
> the mapping DB in case of mobility. But I think that clashes with the clear
> data plane / control plane separation in nextgen. And: there may be data
> plane solutions which don't come with a control plane / mapping system. For
> these the N4 needs to disseminate complete forwarding states (an more, e.g.
> for chargeable event monitoring, device dormancy support etc.) to all
> relevant data plane nodes, means the ones that hold a state for the mobile.
>
>
>
> Btw, in terms of compatibility with nextgen, so far N4 is terminated only
> in few types of core data plane nodes with a dedicated role. We may
> investigate options to push forwarding and further policies from the
> (nextgen) control plane to other data plane nodes which don't terminate N4.
>
>
>
> marco
>
>
>
> From: dmm [mailto:[email-masked] <[email-masked]>] On Behalf
> Of Sri Gundavelli (sgundave)
>
> these are IP packets. But, we should note that there is interworking needed
> with the 3GPP authentication infrastructure, and the protocol specific
> control plane. Note that these protocols are not doing MN identity
> establishment. May be I could be wrong here on the assumptions you have
> around LISP MN capabilities, but to me MN is a standard 3GPP UE with no
> special capabilities such as MIPv6/LISP MN stack.
>
>
>
>
>
>
>
> Sri
>
>
>
>
>
>
>
>
>
>
>
>
>
> >>>>> From: ila [mailto:[email-masked] <[email-masked]>] On
> Behalf Of Dino
>
> >>>>>Farinacci
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.
> ietf.org_mailman_listinfo_dmm&d=DwIFAw&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LR
> xpb6__0PomBTQ&r=IdiSODh8aDRjdCeGgd9MznLHMYKgKcs_
> YSwXBDiaofh47oilzaXYRYETcBynUdpT&m=lWGVj8Jd11JyGVLcPLOSIxTZ-
> YHY3VbtfD1mi2uqhOY&s=-EIvAEYOQusoChy_iwtR4nMkaEqRKBTKTJ8GDjADuCk&e=
>
>
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.
> ietf.org_mailman_listinfo_ila&d=DwIFAw&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LR
> xpb6__0PomBTQ&r=IdiSODh8aDRjdCeGgd9MznLHMYKgKcs_
> YSwXBDiaofh47oilzaXYRYETcBynUdpT&m=lWGVj8Jd11JyGVLcPLOSIxTZ-
> YHY3VbtfD1mi2uqhOY&s=cwX6UkOqq2vREiCvsQ7GPBXgKsinbkDmmckbpGwi73o&e=
>

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Wed, 7 Feb 2018 17:50:26 +0000

They all look the same, Behcet :-)

You tunnel, it becomes LISP; when you translate it becomes ILA;  When you call that mapping table a binding table, and keep it one place, it becomes Mobile IPv6.

When you move that table to some cloud and push it/fetch/flood it, they all converge :-)

Sri

From: Behcet Sarikaya <[email-masked]<mailto:[email-masked]>>
Reply-To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, February 7, 2018 at 9:44 AM
To: Sri Gundavelli <[email-masked]<mailto:[email-masked]>>
Cc: "Bogineni, Kalyani" <[email-masked]<mailto:[email-masked]>>, Marco Liebsch <[email-masked]<mailto:[email-masked]>>, Dino Farinacci <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, dmm <[email-masked]<mailto:[email-masked]>>
Subject: Re: [DMM] [Ila] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

Hi Sri,

On Wed, Feb 7, 2018 at 11:23 AM, Sri Gundavelli (sgundave) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Kalyani,

I don't think the reality is that simple, especially when you talk to 3GPP people.

In fact the translation or Id/Loc separation systems offer completely different and whole new view of how the data plane will work than tunneling which is the legacy technology.

proposes a more efficient way of tunneling.
I don't see any discussion on the main subject, i.e. SRv6 mobile user plane so far on this list and I am puzzled by that.

So my humble suggestion is to concentrate on the advantages and disadvantages of SRv6 mobile user plane draft to 3GPP 4G (if there is time maybe a bit of 5G). I assure you there is a lot of meat there which should keep you busy for a long time.

Regards,
Behcet

Sri

Marco, Sri:

Here are two variants:

Kalyani

-----Original Message-----
From: ila [mailto:[email-masked]] On Behalf Of Marco Liebsch
Sent: Tuesday, February 6, 2018 12:09 PM
To: Sri Gundavelli (sgundave) <[email-masked]<mailto:[email-masked]>>; Dino Farinacci <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; dmm <[email-masked]<mailto:[email-masked]>>

marco

-----Original Message-----

To: Dino Farinacci

Sri

dmm mailing list

ila mailing list

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 7 Feb 2018 11:58:37 -0600

On Wed, Feb 7, 2018 at 11:50 AM, Sri Gundavelli (sgundave) <
[email-masked]> wrote:

> You tunnel, it becomes LISP; when you translate it becomes ILA;  When you
> call that mapping table a binding table, and keep it one place, it becomes
> Mobile IPv6.
>
A strong no, Sri. You are talking about a legacy technology that is already
in place in 4G and now being carried to 5G.
Versus a proposal to totally change it, hopefully sometime later in 5G.

Again, I think it would be more productive to work on the main subject,
i.e. SRv6 user plane proposal by Matsushima.

Regards,
Behcet

> Sri
>
>
>
>
>
> From: Behcet Sarikaya <[email-masked]>
> Reply-To: "[email-masked]" <[email-masked]>
> Cc: "Bogineni, Kalyani" <[email-masked]>, Marco
> Liebsch <[email-masked]>, Dino Farinacci <[email-masked]>, "
> [email-masked]" <[email-masked]>, dmm <[email-masked]>
>
> I don't see any discussion on the main subject, i.e. SRv6 mobile user
> plane so far on this list and I am puzzled by that.
>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iet
>> f.org_mailman_listinfo_dmm&d=DwIFAw&c=udBTRvFvXC5Dhqg7UHpJl
>> Pps3mZ3LRxpb6__0PomBTQ&r=IdiSODh8aDRjdCeGgd9MznLHMYKgKcs_YSw
>> XBDiaofh47oilzaXYRYETcBynUdpT&m=lWGVj8Jd11JyGVLcPLOSIxTZ-YHY
>> 3VbtfD1mi2uqhOY&s=-EIvAEYOQusoChy_iwtR4nMkaEqRKBTKTJ8GDjADuCk&e=
>>
>>
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iet
>> f.org_mailman_listinfo_ila&d=DwIFAw&c=udBTRvFvXC5Dhqg7UHpJl
>> Pps3mZ3LRxpb6__0PomBTQ&r=IdiSODh8aDRjdCeGgd9MznLHMYKgKcs_YSw
>> XBDiaofh47oilzaXYRYETcBynUdpT&m=lWGVj8Jd11JyGVLcPLOSIxTZ-YHY
>> 3VbtfD1mi2uqhOY&s=cwX6UkOqq2vREiCvsQ7GPBXgKsinbkDmmckbpGwi73o&e=
>>

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Wed, 7 Feb 2018 18:05:58 +0000

> Again, I think it would be more productive to work on the main subject, i.e. SRv6 user plane proposal by Matsushima.

Behcet – Yes,  that’s already in charter. We are only comparing various approaches for the other paper.

Sri

Date: Wednesday, February 7, 2018 at 9:58 AM

On Wed, Feb 7, 2018 at 11:50 AM, Sri Gundavelli (sgundave) <[email-masked]<mailto:[email-masked]>> wrote:
They all look the same, Behcet :-)

A strong no, Sri. You are talking about a legacy technology that is already in place in 4G and now being carried to 5G.
Versus a proposal to totally change it, hopefully sometime later in 5G.

Again, I think it would be more productive to work on the main subject, i.e. SRv6 user plane proposal by Matsushima.

Regards,
Behcet

Sri

Hi Sri,

Regards,
Behcet

Sri

Marco, Sri:

Here are two variants:

Kalyani

-----Original Message-----
From: ila [mailto:[email-masked]] On Behalf Of Marco Liebsch
Sent: Tuesday, February 6, 2018 12:09 PM
To: Sri Gundavelli (sgundave) <[email-masked]<mailto:[email-masked]>>; Dino Farinacci <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; dmm <[email-masked]<mailto:[email-masked]>>

marco

-----Original Message-----

To: Dino Farinacci

Sri

dmm mailing list

ila mailing list

---

From: Arashmid Akhavain <[email-masked]>
Date: Wed, 7 Feb 2018 18:11:55 +0000

+1

These are more or less different implementations of the same data path architecture/design.
The mandate from 3GPP however is to investigate new data path options (emphasis on the "S") for N9, not to study SRV6 for N9.

Arashmid

From: dmm [mailto:[email-masked]] On Behalf Of Sri Gundavelli (sgundave)
Sent: 07 February 2018 12:50
To: [email-masked]
Cc: dmm <[email-masked]>; [email-masked]
Subject: Re: [DMM] [Ila] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

Sri

Hi Sri,

Regards,
Behcet

2.) Is N4 the only interface to these two types of node variants. Or we will have N4' to these both types of nodes from some AF (which can interwork with the service bus), and we don't' touch N4.

Marco's point is to keep this generic and not make this very UPF specific, as it will be too restrictive.

Sri

Marco, Sri:

Here are two variants:

Kalyani

-----Original Message-----
From: ila [mailto:[email-masked]] On Behalf Of Marco Liebsch
Sent: Tuesday, February 6, 2018 12:09 PM
To: Sri Gundavelli (sgundave) <[email-masked]<mailto:[email-masked]>>; Dino Farinacci <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; dmm <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Ila] [DMM] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

marco

-----Original Message-----

To: Dino Farinacci

Sri

dmm mailing list

ila mailing list

---

From: Ron Parker <[email-masked]>
Date: Wed, 7 Feb 2018 18:22:46 +0000

Hi.

I'm new to the thread and have been monitoring it for a couple of weeks now.   I have a question regarding 5G SSC (Session & Service Continuity) and its intersection with LISP/ILA/MIP/etc.   One of the SSC modes (mode 3) for 5G is make-before-break on the PDU session.   This implies that the UE has, temporarily 2 IP addresses (or 2 pairs if v4/v6 dual-stack).

Might there be solutions in the IP stack on both the client side and server side to deal with this change of IP address?   Would that obviate the need for these complex high-scale mapping techniques?

Thanks.

   Ron

From: ila [mailto:[email-masked]] On Behalf Of Arashmid Akhavain
Sent: Wednesday, February 7, 2018 1:12 PM
To: Sri Gundavelli (sgundave) <[email-masked]>; [email-masked]
Cc: [email-masked]; dmm <[email-masked]>
Subject: Re: [Ila] [DMM] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

+1

Arashmid

From: dmm [mailto:[email-masked]] On Behalf Of Sri Gundavelli (sgundave)
Sent: 07 February 2018 12:50
To: [email-masked]<mailto:[email-masked]>
Cc: dmm <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [DMM] [Ila] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

Sri

Hi Sri,

Regards,
Behcet

Sri

Marco, Sri:

Here are two variants:

Kalyani

-----Original Message-----
From: ila [mailto:[email-masked]] On Behalf Of Marco Liebsch
Sent: Tuesday, February 6, 2018 12:09 PM
To: Sri Gundavelli (sgundave) <[email-masked]<mailto:[email-masked]>>; Dino Farinacci <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; dmm <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Ila] [DMM] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

marco

-----Original Message-----

To: Dino Farinacci

Sri

dmm mailing list

ila mailing list

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Wed, 7 Feb 2018 18:28:43 +0000

Hi Ron,

> This implies that the UE has, temporarily 2 IP addresses (or 2 pairs if v4/v6 dual-stack).

That’s Mobile IPv6 and other client-based solutions such as ILNP.  Unfortunately, industry failed to realize client support and hence the focus on network based approaches. It is true, nothing can beat a system where the end node is capable of managing its mobility, but, that did not work out.

Sri

From: Ron Parker <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, February 7, 2018 at 10:22 AM
To: Arashmid Akhavain <[email-masked]<mailto:[email-masked]>>, Sri Gundavelli <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, dmm <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Ila] [DMM] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

Hi.

I’m new to the thread and have been monitoring it for a couple of weeks now.   I have a question regarding 5G SSC (Session & Service Continuity) and its intersection with LISP/ILA/MIP/etc.   One of the SSC modes (mode 3) for 5G is make-before-break on the PDU session.   This implies that the UE has, temporarily 2 IP addresses (or 2 pairs if v4/v6 dual-stack).

Thanks.

   Ron

To: Sri Gundavelli (sgundave) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

+1

These are more or less different implementations of the same data path architecture/design.
The mandate from 3GPP however is to investigate new data path options (emphasis on the “S”) for N9, not to study SRV6 for N9.

Arashmid

Sri

Hi Sri,

Regards,
Behcet

Sri

Marco, Sri:

Here are two variants:

Kalyani

-----Original Message-----
From: ila [mailto:[email-masked]] On Behalf Of Marco Liebsch
Sent: Tuesday, February 6, 2018 12:09 PM
To: Sri Gundavelli (sgundave) <[email-masked]<mailto:[email-masked]>>; Dino Farinacci <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; dmm <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Ila] [DMM] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

marco

-----Original Message-----

To: Dino Farinacci

Sri

dmm mailing list

ila mailing list

---

From: "Bogineni, Kalyani" <[email-masked]>
Date: Wed, 7 Feb 2018 18:31:35 +0000

Sri:

The white paper should bring out the impacts to the system (N3, etc) when we compare the different proposals.

Kalyani

From: Sri Gundavelli (sgundave) [mailto:[email-masked]]
Sent: Wednesday, February 7, 2018 12:23 PM
To: Bogineni, Kalyani <[email-masked]>; Marco Liebsch <[email-masked]>; Dino Farinacci <[email-masked]>
Cc: [email-masked]; dmm <[email-masked]>
Subject: Re: [Ila] [DMM] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

Hi Kalyani,

Sri

Marco, Sri:

Here are two variants:

Kalyani

-----Original Message-----
From: ila [mailto:[email-masked]] On Behalf Of Marco Liebsch
Sent: Tuesday, February 6, 2018 12:09 PM
To: Sri Gundavelli (sgundave) <[email-masked]<mailto:[email-masked]>>; Dino Farinacci <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; dmm <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Ila] [DMM] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

marco

-----Original Message-----

To: Dino Farinacci

Sri

dmm mailing list

ila mailing list

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Wed, 7 Feb 2018 18:45:24 +0000

Kalyani – Sure.

Riding on N4 variant for mapping/SRv6 policy lookup etc is fine and can work for N9. But, if N3 is not touched, the UPF will be a complex entity with GTP towards one end and XYZ towards other side. But, I understand the scope is only N9 study.

Sri

From: "Bogineni, Kalyani" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, February 7, 2018 at 10:31 AM
To: Sri Gundavelli <[email-masked]<mailto:[email-masked]>>, Marco Liebsch <[email-masked]<mailto:[email-masked]>>, Dino Farinacci <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, dmm <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Ila] [DMM] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

Sri:

Kalyani

To: Bogineni, Kalyani <[email-masked]<mailto:[email-masked]>>; Marco Liebsch <[email-masked]<mailto:[email-masked]>>; Dino Farinacci <[email-masked]<mailto:[email-masked]>>

Hi Kalyani,

Sri

Marco, Sri:

Here are two variants:

Kalyani

-----Original Message-----
From: ila [mailto:[email-masked]] On Behalf Of Marco Liebsch
Sent: Tuesday, February 6, 2018 12:09 PM
To: Sri Gundavelli (sgundave) <[email-masked]<mailto:[email-masked]>>; Dino Farinacci <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; dmm <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Ila] [DMM] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

marco

-----Original Message-----

To: Dino Farinacci

Sri

dmm mailing list

ila mailing list

---

From: Ron Parker <[email-masked]>
Date: Wed, 7 Feb 2018 19:09:39 +0000

Thanks, Sri.

I agree that clients (and servers) don't currently cope.   But I also wonder what the motivation is of this SSC mode 3 and how its backers envision it being used beneficially.

   Ron

From: Sri Gundavelli (sgundave) [mailto:[email-masked]]
Sent: Wednesday, February 7, 2018 1:29 PM
To: Ron Parker <[email-masked]>; Arashmid Akhavain <[email-masked]>; [email-masked]
Cc: [email-masked]; dmm <[email-masked]>
Subject: Re: [Ila] [DMM] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

Hi Ron,

> This implies that the UE has, temporarily 2 IP addresses (or 2 pairs if v4/v6 dual-stack).

That's Mobile IPv6 and other client-based solutions such as ILNP.  Unfortunately, industry failed to realize client support and hence the focus on network based approaches. It is true, nothing can beat a system where the end node is capable of managing its mobility, but, that did not work out.

Sri

Hi.

Thanks.

   Ron

+1

Arashmid

Sri

Hi Sri,

Regards,
Behcet

Sri

Marco, Sri:

Here are two variants:

Kalyani

-----Original Message-----
From: ila [mailto:[email-masked]] On Behalf Of Marco Liebsch
Sent: Tuesday, February 6, 2018 12:09 PM
To: Sri Gundavelli (sgundave) <[email-masked]<mailto:[email-masked]>>; Dino Farinacci <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; dmm <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Ila] [DMM] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

marco

-----Original Message-----

To: Dino Farinacci

Sri

dmm mailing list

ila mailing list

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Wed, 7 Feb 2018 19:54:14 +0000

Ron,

There are two parts to this discussion. The mobile node with a enhanced client stack, vs a a mobile node with a standard IPv6 stack. Some of the SSC modes can be supported with the standard IPv6 stack. MN has a prefix P1, but latter the network decides to allocate a new prefix. It can do so by sending a IPv6 RA message with the new prefix. If I remember correctly, in SSC mode  3, a new PDU session is created before removing the previous PDU.

Sri

From: Ron Parker <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, February 7, 2018 at 11:09 AM
To: Sri Gundavelli <[email-masked]<mailto:[email-masked]>>, Arashmid Akhavain <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, dmm <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Ila] [DMM] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

Thanks, Sri.

I agree that clients (and servers) don’t currently cope.   But I also wonder what the motivation is of this SSC mode 3 and how its backers envision it being used beneficially.

   Ron

To: Ron Parker <[email-masked]<mailto:[email-masked]>>; Arashmid Akhavain <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

Hi Ron,

Sri

Hi.

Thanks.

   Ron

+1

Arashmid

Sri

Hi Sri,

Regards,
Behcet

Sri

Marco, Sri:

Here are two variants:

Kalyani

-----Original Message-----
From: ila [mailto:[email-masked]] On Behalf Of Marco Liebsch
Sent: Tuesday, February 6, 2018 12:09 PM
To: Sri Gundavelli (sgundave) <[email-masked]<mailto:[email-masked]>>; Dino Farinacci <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; dmm <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Ila] [DMM] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

marco

-----Original Message-----

To: Dino Farinacci

Sri

dmm mailing list

ila mailing list

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 7 Feb 2018 21:32:48 +0000

Hi Sri,

AERO needs also be mentioned as a tunneling option.

Thanks - Fred

From: dmm [mailto:[email-masked]] On Behalf Of Sri Gundavelli (sgundave)
Sent: Wednesday, February 07, 2018 9:50 AM
To: [email-masked]
Cc: dmm <[email-masked]>; [email-masked]
Subject: Re: [DMM] [Ila] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

Sri

Hi Sri,

Regards,
Behcet

Sri

Marco, Sri:

Here are two variants:

Kalyani

-----Original Message-----
From: ila [mailto:[email-masked]] On Behalf Of Marco Liebsch
Sent: Tuesday, February 6, 2018 12:09 PM
To: Sri Gundavelli (sgundave) <[email-masked]<mailto:[email-masked]>>; Dino Farinacci <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; dmm <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Ila] [DMM] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

marco

-----Original Message-----

To: Dino Farinacci

Sri

dmm mailing list

ila mailing list

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 7 Feb 2018 21:34:49 +0000

Hi Dino,

> From: dmm [mailto:[email-masked]] On Behalf Of Dino Farinacci
> Sent: Thursday, February 01, 2018 3:38 PM
> To: Sri Gundavelli (sgundave) <[email-masked]>
> Subject: Re: [DMM] [Ila] Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt
> 

AERO uses IPv6 Neighbor Discovery as its control-plane. Surely that is the most mature?

Thanks - Fred

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Wed, 7 Feb 2018 21:56:01 +0000

Hi Fred,

Ack!

Sri

From: "Templin, Fred L" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, February 7, 2018 at 1:32 PM
To: Sri Gundavelli <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: dmm <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [DMM] [Ila] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

Hi Sri,

Thanks - Fred

Sri

Hi Sri,

Regards,
Behcet

Sri

Marco, Sri:

Here are two variants:

Kalyani

-----Original Message-----
From: ila [mailto:[email-masked]] On Behalf Of Marco Liebsch
Sent: Tuesday, February 6, 2018 12:09 PM
To: Sri Gundavelli (sgundave) <[email-masked]<mailto:[email-masked]>>; Dino Farinacci <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; dmm <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Ila] [DMM] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

marco

-----Original Message-----

To: Dino Farinacci

Sri

dmm mailing list

ila mailing list

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 8 Feb 2018 09:30:54 +0900

+1

There are only so many ways to do loc/id split. And if you mix and match you can take the best from each proposal for this particular use-case. Assuming combining the parts doesn’t lead to a zero sum (or negative sum) game. 

Dino

> On Feb 8, 2018, at 3:11 AM, Arashmid Akhavain <[email-masked]> wrote:
> 
> +1
>  
> Cc: "Bogineni, Kalyani" <[email-masked]>, Marco Liebsch <[email-masked]>, Dino Farinacci <[email-masked]>, "[email-masked]" <[email-masked]>, dmm <[email-masked]>
> On Wed, Feb 7, 2018 at 11:23 AM, Sri Gundavelli (sgundave) <[email-masked]> wrote:
> Hi Kalyani,
>  
> To: Marco Liebsch <[email-masked]>, Sri Gundavelli <[email-masked]>, Dino Farinacci <[email-masked]>

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 8 Feb 2018 09:34:58 +0900

> AERO uses IPv6 Neighbor Discovery as its control-plane. Surely that is the most mature?

Yes when used in a layer-2 subnet. Uses in a wider scope it has NHRP properties. 

If you remember we had something called LISP-EMACS (thanks John Curran) which we “ARPed a Map-Request over a layer 3 multicast fabric” to resolve mappings. 

Dino

---

From: Marco Liebsch <[email-masked]>
Date: Thu, 8 Feb 2018 09:50:15 +0000

Hi Kalyani,

My take on your latest feedback:
> I think you are talking about 2 features: one for mobility that needs the database; another
> for non-mobility state transfer between user plane nodes (not necessarily mobility nodes).

True, control plane impact on data plane can be on N3, N9 but also on N9. The latter is probably what you classify as non-mobility.
My point was to not break the N4 but rather look towards a reasonable and extensible protocol solution so that mapping
rules can be carried over it. In such case the mapping DB may be co-located with the SMF or external to the SMF. My main point
was to not make the control plane configuring the data plane through the service-based interfaces.

About the second case, I think it's interesting enough to include N6 where the mapping system would control
the data plane to steer traffic to the mobile's UPF(s). Think about decentralizing the UPFs and relocating a
UPF mid-session. The plain old but popular DMM scenario: How to enable IP address- and session continuity
when the anchor UPF changes.

Best regards,
marco

From: Sri Gundavelli (sgundave) [mailto:[email-masked]]
Sent: Mittwoch, 7. Februar 2018 18:23
To: Bogineni, Kalyani; Marco Liebsch; Dino Farinacci
Cc: [email-masked]; dmm
Subject: Re: [Ila] [DMM] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

Hi Kalyani,

Sri

Marco, Sri:

Here are two variants:

Kalyani

-----Original Message-----
From: ila [mailto:[email-masked]] On Behalf Of Marco Liebsch
Sent: Tuesday, February 6, 2018 12:09 PM
To: Sri Gundavelli (sgundave) <[email-masked]<mailto:[email-masked]>>; Dino Farinacci <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; dmm <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Ila] [DMM] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

marco

-----Original Message-----

To: Dino Farinacci

Sri

dmm mailing list

ila mailing list

---

From: Marco Liebsch <[email-masked]>
Date: Thu, 8 Feb 2018 10:03:04 +0000

..sorry, correction in my first sentence below:
"True, control plane impact on data plane can be on N3, N9 but also on N6."..

From: dmm [mailto:[email-masked]] On Behalf Of Marco Liebsch
Sent: Donnerstag, 8. Februar 2018 10:50
To: Sri Gundavelli (sgundave); Bogineni, Kalyani; Dino Farinacci
Cc: [email-masked]; dmm
Subject: Re: [DMM] [Ila] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

Hi Kalyani,

Best regards,
marco

Cc: [email-masked]<mailto:[email-masked]>; dmm

Hi Kalyani,

Sri

Marco, Sri:

Here are two variants:

Kalyani

-----Original Message-----
From: ila [mailto:[email-masked]] On Behalf Of Marco Liebsch
Sent: Tuesday, February 6, 2018 12:09 PM
To: Sri Gundavelli (sgundave) <[email-masked]<mailto:[email-masked]>>; Dino Farinacci <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; dmm <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Ila] [DMM] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

marco

-----Original Message-----

To: Dino Farinacci

Sri

dmm mailing list

ila mailing list

---

From: "Bogineni, Kalyani" <[email-masked]>
Date: Thu, 8 Feb 2018 12:33:50 +0000

Marco:

There are 2 kinds of non-mobility nodes/functions:

-          One set is what you are referring to as N6 based functions, also called Gi-LAN functions that could be
chained to PGW/UPF on Gi/SGi/N6.

-          The second set of functions are related to transport (IP/MPLS) over which mobility traffic traverses.

The first set needs some kind of policy/charging control and will need interaction to the services interface.
The second set possibly don't need policy/charging control.

We need to see if some of the protocol choices like SRv6 are trying to address the second set also.

Kalyani

From: Marco Liebsch [mailto:[email-masked]]
Sent: Thursday, February 8, 2018 5:03 AM
To: Marco Liebsch <[email-masked]>; Sri Gundavelli (sgundave) <[email-masked]>; Bogineni, Kalyani <[email-masked]>; Dino Farinacci <[email-masked]>
Cc: [email-masked]; dmm <[email-masked]>
Subject: RE: [DMM] [Ila] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

Hi Kalyani,

Best regards,
marco

Hi Kalyani,

Sri

Marco, Sri:

Here are two variants:

Kalyani

-----Original Message-----
From: ila [mailto:[email-masked]] On Behalf Of Marco Liebsch
Sent: Tuesday, February 6, 2018 12:09 PM
To: Sri Gundavelli (sgundave) <[email-masked]<mailto:[email-masked]>>; Dino Farinacci <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; dmm <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Ila] [DMM] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

marco

-----Original Message-----

To: Dino Farinacci

Sri

dmm mailing list

ila mailing list

---

From: "Bogineni, Kalyani" <[email-masked]>
Date: Thu, 8 Feb 2018 12:39:10 +0000

Sri:

Even though N3 is shown for 5G and S1-U for 4G, my understanding is that there are commons sub-layers in the protocol stack
that are common to both 4G and 5G radio accesses that could be re-used. The adaptation from GTP to IP has to happen
somewhere, either in the radio node or in the UPF. The UPF closer to the radio node also does the adaptation. Are there any
other ideas?

Kalyani

Hi Kalyani,

Sri

Marco, Sri:

Here are two variants:

Kalyani

-----Original Message-----
From: ila [mailto:[email-masked]] On Behalf Of Marco Liebsch
Sent: Tuesday, February 6, 2018 12:09 PM
To: Sri Gundavelli (sgundave) <[email-masked]<mailto:[email-masked]>>; Dino Farinacci <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; dmm <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Ila] [DMM] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

marco

-----Original Message-----

To: Dino Farinacci

Sri

dmm mailing list

ila mailing list

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 8 Feb 2018 15:54:02 +0000

Hi Dino,

> Sent: Wednesday, February 07, 2018 4:35 PM
> To: Templin, Fred L <[email-masked]>
> Cc: Sri Gundavelli (sgundave) <[email-masked]>; [email-masked]; dmm <[email-masked]>

The AERO tunnel is an NBMA link the same as for any link, and uses RFC4861 neighbor
discovery messaging. All nodes on the link can communicate as single-hop neighbors.

> fabric” to resolve mappings.

I don't recall that, but AERO got its start with ISATAP back in Y2K .
Like AERO, ISATAP uses IPv6 ND messaging over tunnels.

Thanks - Fred

---

From: Marco Liebsch <[email-masked]>
Date: Thu, 8 Feb 2018 17:16:27 +0000

Kalyani,

steering traffic on N6 in between a correspondent service (Data Network, DN) and a mobile's UPF,
and this is what I referred to, does not require N6/Gi-LAN functions, just routing policies in the transport network.
This can be policies at the N6 edges, means at the UPF side and the DN side, serving as ingress/egress for the
mobile's downlink and uplink traffic. Still these policies need information from the mobility control plane,
which is at least the locator (current UPF for that traffic).

But I understood that N6 is out of scope of your document, so it's fine.

Thanks,
marco

From: Bogineni, Kalyani [mailto:[email-masked]]
Sent: Donnerstag, 8. Februar 2018 13:34
To: Marco Liebsch; Sri Gundavelli (sgundave); Dino Farinacci
Cc: [email-masked]; dmm
Subject: RE: [DMM] [Ila] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

Marco:

Kalyani

To: Marco Liebsch <[email-masked]<mailto:[email-masked]>>; Sri Gundavelli (sgundave) <[email-masked]<mailto:[email-masked]>>; Bogineni, Kalyani <[email-masked]<mailto:[email-masked]>>; Dino Farinacci <[email-masked]<mailto:[email-masked]>>

Hi Kalyani,

Best regards,
marco

Hi Kalyani,

Sri

Marco, Sri:

Here are two variants:

Kalyani

-----Original Message-----
From: ila [mailto:[email-masked]] On Behalf Of Marco Liebsch
Sent: Tuesday, February 6, 2018 12:09 PM
To: Sri Gundavelli (sgundave) <[email-masked]<mailto:[email-masked]>>; Dino Farinacci <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; dmm <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Ila] [DMM] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

marco

-----Original Message-----

To: Dino Farinacci

Sri

dmm mailing list

ila mailing list

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Fri, 9 Feb 2018 00:14:08 +0000

HI Kalyani,

>  The adaptation from GTP to IP has to happen somewhere, either in the radio node or in the UPF.

I guess when you say from “adaptation from GTP to IP”, you mean to say GTP-U decapsulation of the user-plane IP packet for handling it by other protocols and for forwarding it on N9.

If N3 is untouched, then its the UPF that is doing that decapsulation and giving it to  XYZ function (LISP/ILA/SRv6/Aero/*). There is no node that can do the GTP-U decap.  But, that also makes the UPF with dual personality of GTP-U one one side and XYZ function towards the other UPF on N9. But, in some cases there may not be even a N9 (Ex: S/P GW function for a session are collocated on the same SAE GW when there is no mobility). So,  my point is solving this for N9 may not greatly simplify the architecture; there is still an anchor and there is still GTP-U. The CT4 study may be about N9, but I think it will be useful IMO for IETF to look at the entire system and realize a GTP-U less architecture.

Sri

Date: Thursday, February 8, 2018 at 4:39 AM

Sri:

Kalyani

Hi Kalyani,

Sri

Marco, Sri:

Here are two variants:

Kalyani

-----Original Message-----
From: ila [mailto:[email-masked]] On Behalf Of Marco Liebsch
Sent: Tuesday, February 6, 2018 12:09 PM
To: Sri Gundavelli (sgundave) <[email-masked]<mailto:[email-masked]>>; Dino Farinacci <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; dmm <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Ila] [DMM] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

marco

-----Original Message-----

To: Dino Farinacci

Sri

dmm mailing list

ila mailing list

---

From: Uma Chunduri <[email-masked]>
Date: Fri, 9 Feb 2018 01:06:48 +0000

Hi Tom, Kalyani -

I fully agree what Sri said below.

>From Section 7.2 of the subject line:

                 --->             --->            --->
    DN to ILA-R      ILA-R to ILA-N   ILA-N to gNB     gNB to UE
   +------------+   +------------+   +------------+   +------------+
   | Application|   | Application|   | Application|   | Application|
   +------------+   +------------+   +------------+   +------------+
   |     L4     |   |     L4     |   |     L4     |   |     L4     |
   +------------+   +------------+   +------------+   +------------+
   |    IPv6    |   | IPv6 (ILA) |   |    IPv6    |   |  PDU Layer |
   +------------+ | +------------+ | +------------+   +------------+
   |     L2     | | |     L2     | | |   GTP-U    |   | AN Protocol|
   +------------+ | +------------+ | +------------+   |   Layers   |
                  |                | |   UDP/IP   |   |            |
                 N6   <--N9 -->   N3 +------------+   +------------+
                                     |    L2      |
                                     +------------+

If this were to be nextgen and seeking key benefits of ID/LOCs, I strongly suggest changing the content of the draft to make this fully anchorless i.e., including N3 else I am not seeing *any mobility* scenario  that is being solved by ILA.

As it stands - eNB/gNB mobility would be taken care by S1U/N3. Meaning both X2 based and S1 based handovers/mobility (used 4G terminology, but I meant equivalent interfaces) is out of the scope for ILA.

If you were to bring in transformation concept (tunnel-free concept) or ILA-N it has to be on gNB not UPF (not even staging BP UPF).

Please tell me if my understanding is incorrect here. I have few more questions on the draft and shall wait.

--
Uma C.

Sent: Thursday, February 08, 2018 4:14 PM

HI Kalyani,

>  The adaptation from GTP to IP has to happen somewhere, either in the radio node or in the UPF.

I guess when you say from "adaptation from GTP to IP", you mean to say GTP-U decapsulation of the user-plane IP packet for handling it by other protocols and for forwarding it on N9.

Sri

Sri:

Kalyani

Hi Kalyani,

Sri

Marco, Sri:

Here are two variants:

Kalyani

-----Original Message-----
From: ila [mailto:[email-masked]] On Behalf Of Marco Liebsch
Sent: Tuesday, February 6, 2018 12:09 PM
To: Sri Gundavelli (sgundave) <[email-masked]<mailto:[email-masked]>>; Dino Farinacci <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; dmm <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Ila] [DMM] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

marco

-----Original Message-----

To: Dino Farinacci

Sri

dmm mailing list

ila mailing list

---

From: "Bogineni, Kalyani" <[email-masked]>
Date: Fri, 9 Feb 2018 02:06:50 +0000

Uma:

The goal of the white paper is to understand how each of the proposals impact N3, N4, SMF and gNB as is listed in Section of the white paper.

Here is the extract from Section 4 of the CT4 study item. They say that coordination with other working groups will be done as needed. So
documenting the proposals is important.

------------- from CT4 Study item --------

As CT4 is not responsible for selecting the user plane protocol in the RAN (e.g. N3, F1-U), and since the user plane protocol in the 5GC cannot be decided irrespectively of the user plane protocol supported in the RAN, the study will have to involve coordination with RAN3.

Coordination will also be required with CT3 for potential impacts on N6, and with SA2 if the work has possible impacts on the stage 2 specifications.

---------

Kalyani

From: Uma Chunduri [mailto:[email-masked]]
Sent: Thursday, February 8, 2018 8:07 PM
To: Sri Gundavelli (sgundave) <[email-masked]>; Bogineni, Kalyani <[email-masked]>; Marco Liebsch <[email-masked]>; Dino Farinacci <[email-masked]>
Cc: [email-masked]; dmm <[email-masked]>
Subject: RE: [Ila] [DMM] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

Hi Tom, Kalyani -

                 --->             --->            --->

--
Uma C.

HI Kalyani,

Sri

Sri:

Kalyani

Hi Kalyani,

Sri

Marco, Sri:

Here are two variants:

Kalyani

-----Original Message-----
From: ila [mailto:[email-masked]] On Behalf Of Marco Liebsch
Sent: Tuesday, February 6, 2018 12:09 PM
To: Sri Gundavelli (sgundave) <[email-masked]<mailto:[email-masked]>>; Dino Farinacci <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; dmm <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Ila] [DMM] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

marco

-----Original Message-----

To: Dino Farinacci

Sri

dmm mailing list

ila mailing list

---

From: Uma Chunduri <[email-masked]>
Date: Fri, 9 Feb 2018 02:12:43 +0000

Kalyani -

In-line [Uma]:

--
Uma C.

From: Bogineni, Kalyani [mailto:[email-masked]]
Sent: Thursday, February 08, 2018 6:07 PM
To: Uma Chunduri <[email-masked]>; Sri Gundavelli (sgundave) <[email-masked]>; Marco Liebsch <[email-masked]>; Dino Farinacci <[email-masked]>
Cc: [email-masked]; dmm <[email-masked]>
Subject: RE: [Ila] [DMM] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

Uma:

The goal of the white paper is to understand how each of the proposals impact N3, N4, SMF and gNB as is listed in Section of the white paper.
[Uma]: Absolutely. I got that. But I am not asking about the whitepaper below.
                I am not getting which mobility scenario is covered by ILA proposal in the subject line if you don't include N3?

------------- from CT4 Study item --------

---------

Kalyani

To: Sri Gundavelli (sgundave) <[email-masked]<mailto:[email-masked]>>; Bogineni, Kalyani <[email-masked]<mailto:[email-masked]>>; Marco Liebsch <[email-masked]<mailto:[email-masked]>>; Dino Farinacci <[email-masked]<mailto:[email-masked]>>

Hi Tom, Kalyani -

                 --->             --->            --->

--
Uma C.

HI Kalyani,

Sri

Sri:

Kalyani

Hi Kalyani,

Sri

Marco, Sri:

Here are two variants:

Kalyani

-----Original Message-----
From: ila [mailto:[email-masked]] On Behalf Of Marco Liebsch
Sent: Tuesday, February 6, 2018 12:09 PM
To: Sri Gundavelli (sgundave) <[email-masked]<mailto:[email-masked]>>; Dino Farinacci <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; dmm <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Ila] [DMM] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

marco

-----Original Message-----

To: Dino Farinacci

Sri

dmm mailing list

ila mailing list

---

From: "Bogineni, Kalyani" <[email-masked]>
Date: Fri, 9 Feb 2018 02:17:46 +0000

Uma - It will support mobility scenarios similar to what SGW/PGW support in 4G. And will also support
local access to the DN.
Kalyani

From: Uma Chunduri [mailto:[email-masked]]
Sent: Thursday, February 8, 2018 9:13 PM
To: Bogineni, Kalyani <[email-masked]>; Sri Gundavelli (sgundave) <[email-masked]>; Marco Liebsch <[email-masked]>; Dino Farinacci <[email-masked]>
Cc: [email-masked]; dmm <[email-masked]>
Subject: RE: [Ila] [DMM] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

Kalyani -

In-line [Uma]:

--
Uma C.

To: Uma Chunduri <[email-masked]<mailto:[email-masked]>>; Sri Gundavelli (sgundave) <[email-masked]<mailto:[email-masked]>>; Marco Liebsch <[email-masked]<mailto:[email-masked]>>; Dino Farinacci <[email-masked]<mailto:[email-masked]>>

Uma:

------------- from CT4 Study item --------

---------

Kalyani

Hi Tom, Kalyani -

                 --->             --->            --->

--
Uma C.

HI Kalyani,

Sri

Sri:

Kalyani

Hi Kalyani,

Sri

Marco, Sri:

Here are two variants:

Kalyani

-----Original Message-----
From: ila [mailto:[email-masked]] On Behalf Of Marco Liebsch
Sent: Tuesday, February 6, 2018 12:09 PM
To: Sri Gundavelli (sgundave) <[email-masked]<mailto:[email-masked]>>; Dino Farinacci <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; dmm <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Ila] [DMM] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

marco

-----Original Message-----

To: Dino Farinacci

Sri

dmm mailing list

ila mailing list

---

From: Uma Chunduri <[email-masked]>
Date: Fri, 9 Feb 2018 02:23:52 +0000

Sent: Thursday, February 08, 2018 6:18 PM

Uma - It will support mobility scenarios similar to what SGW/PGW support in 4G.
[Uma]:  Yes, then ILA-N has to be on gNB  and ILA-R has to be on the UPF where N6 is there.
                 But current draft suggests ILA-N on another UPF (perhaps BP UPF) and the address transformation between only between UPFs on N9. I don't see any mobility in that case..
                 Perhaps you have to adjust the draft to move ILA-N to gNB. Yes, with this N3 comes into picture.

And will also support local access to the DN.
[Uma]: ??

Kalyani

To: Bogineni, Kalyani <[email-masked]<mailto:[email-masked]>>; Sri Gundavelli (sgundave) <[email-masked]<mailto:[email-masked]>>; Marco Liebsch <[email-masked]<mailto:[email-masked]>>; Dino Farinacci <[email-masked]<mailto:[email-masked]>>

Kalyani -

In-line [Uma]:

--
Uma C.

Uma:

------------- from CT4 Study item --------

---------

Kalyani

Hi Tom, Kalyani -

                 --->             --->            --->

--
Uma C.

HI Kalyani,

Sri

Sri:

Kalyani

Hi Kalyani,

Sri

Marco, Sri:

Here are two variants:

Kalyani

-----Original Message-----
From: ila [mailto:[email-masked]] On Behalf Of Marco Liebsch
Sent: Tuesday, February 6, 2018 12:09 PM
To: Sri Gundavelli (sgundave) <[email-masked]<mailto:[email-masked]>>; Dino Farinacci <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; dmm <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Ila] [DMM] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

marco

-----Original Message-----

To: Dino Farinacci

Sri

dmm mailing list

ila mailing list

---

From: "Bogineni, Kalyani" <[email-masked]>
Date: Fri, 9 Feb 2018 02:30:47 +0000

Uma - responses inline.

Sent: Thursday, February 8, 2018 9:24 PM

And will also support local access to the DN.
[Uma]: ??
[KB] Your above comments are actually applicable here. Depending on the use case, the ILA-N can be collocated with the gNB, or slightly
centralized like in today's SGW locations. From TS 23.501

Figure 4.2.3-4: Applying non-roaming 5G System architecture for concurrent access to two (e.g. local and central) data networks (single PDU Session option) in reference point representation

Kalyani

Kalyani -

In-line [Uma]:

--
Uma C.

Uma:

------------- from CT4 Study item --------

---------

Kalyani

Hi Tom, Kalyani -

                 --->             --->            --->

--
Uma C.

HI Kalyani,

Sri

Sri:

Kalyani

Hi Kalyani,

Sri

Marco, Sri:

Here are two variants:

Kalyani

-----Original Message-----
From: ila [mailto:[email-masked]] On Behalf Of Marco Liebsch
Sent: Tuesday, February 6, 2018 12:09 PM
To: Sri Gundavelli (sgundave) <[email-masked]<mailto:[email-masked]>>; Dino Farinacci <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; dmm <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Ila] [DMM] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

marco

-----Original Message-----

To: Dino Farinacci

Sri

dmm mailing list

ila mailing list

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 9 Feb 2018 09:09:22 +0100

Le 07/02/2018 à 18:29, Tom Herbert a écrit :
> 
> 
> On Wed, Feb 7, 2018 at 8:49 AM, Alexandre Petrescu 
> <[email-masked] <mailto:[email-masked]>>
> wrote:
> 
> 
> 
> On Fri, Feb 2, 2018 at 6:27 AM, Tom Herbert <[email-masked] 
> <mailto:[email-masked]> <mailto:[email-masked] 
> <mailto:[email-masked]>>> wrote:
> 
> Echoing Tom's earlier comment about this: I think the address 
> assignment sections (6.3 and 8.3) should be reworded to clarify that
> for general purpose hosts, best practice is not to use singleton
> addresses, but always to provide a /64 prefix.
> 
> 
> I'm curious as to why you'd need even shorter prefixes.

This is an optional accessory.

A /63 prefix is beneficial for a Mobile Router, or 'IoT Router', for
local area tethering, or for in-vehicle networks.  It gets a /63 from
the ISP and makes two /64s out of it.  One for its WiFi interface and
one for its Ethernet interface.

If it only gets a /64 then it cant make other /64s out of it and it
can't route.

Alex

  If a subnet is
> so huge that it needs more than a /64, why not just give it a static
>  prefix allocation. ILA can be used independently within the subnet
> if desired.
> 
> Tom
>

---

From: Tom Herbert <[email-masked]>
Date: Fri, 9 Feb 2018 08:18:03 -0800

On Fri, Feb 9, 2018 at 12:09 AM, Alexandre Petrescu <
[email-masked]> wrote:

>> [email-masked] <mailto:[email-masked]>>
>> wrote:
>>
>>
>>
>> [email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>
>> wrote:
>>
>> sections (6.3 and 8.3) should be reworded to clarify that

> one for its Ethernet interface.

Why not just get a /64 for WIFI and one for Ethernet? That would be the
common case any way if they are attached to two different providers.

> If it only gets a /64 then it cant make other /64s out of it and it

I'm a bit amused by the phrase "only gets a /64". Assigning a /64 to a
device is the equivalent of assigning four billion IPv4 address spaces
after all! Why not just carve up a /64 into bunch of /96s or something like
that for down stream allocation?

Tom

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 10 Feb 2018 14:33:18 +0100

Le 09/02/2018 à 17:18, Tom Herbert a écrit :
> 
> 
> On Fri, Feb 9, 2018 at 12:09 AM, Alexandre Petrescu 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> 
>         <[email-masked]
>         <mailto:[email-masked]>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>>
>         wrote:
> 
> 
> 
>         <mailto:[email-masked]>> <mailto:[email-masked]
>         <mailto:[email-masked]>>>> wrote:
> 
>         We like like to request that the dmm WG consider ILA as a
>         candidate protocol for the 3GPP "Study on User Plane Protocol in
>         5GC".
> 
> 
> Why not just get a /64 for WIFI and one for Ethernet?

YEs, makes sense.

In that case we talk about providing multiple /64s to end-user.

> That would be the 

But this does not make sense.

In this optional accessory case, we dont want the user terminal to 
connect to two providers in order to get two /64s.  We want it to 
connect it one LTE provider and get at least two /64s for the same 
connection.

> after all! Why not just carve up a /64 into bunch of /96s or something 
> like that for down stream allocation?

That carving out can be made, yes.

But what to do with a /96?  A router could put that /96 in an RA, but a 
Host receiving it can not make an address out of it.

Alex