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

["Sri Gundavelli (sgundave)" <[e-mail]>]

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 <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, February 7, 2018 at 11:09 AM
To: Sri Gundavelli <[e-mail]<mailto:[e-mail]>>, Arashmid Akhavain <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, dmm <[e-mail]<mailto:[e-mail]>>
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


From: Sri Gundavelli (sgundave) [mailto:[e-mail]]
Sent: Wednesday, February 7, 2018 1:29 PM
To: Ron Parker <[e-mail]<mailto:[e-mail]>>; Arashmid Akhavain <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; dmm <[e-mail]<mailto:[e-mail]>>
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



From: Ron Parker <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, February 7, 2018 at 10:22 AM
To: Arashmid Akhavain <[e-mail]<mailto:[e-mail]>>, Sri Gundavelli <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, dmm <[e-mail]<mailto:[e-mail]>>
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).

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

+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:[e-mail]] On Behalf Of Sri Gundavelli (sgundave)
Sent: 07 February 2018 12:50
To: [e-mail]<mailto:[e-mail]>
Cc: dmm <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [DMM] [Ila] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

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 <[e-mail]<mailto:[e-mail]>>
Reply-To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, February 7, 2018 at 9:44 AM
To: Sri Gundavelli <[e-mail]<mailto:[e-mail]>>
Cc: "Bogineni, Kalyani" <[e-mail]<mailto:[e-mail]>>, Marco Liebsch <[e-mail]<mailto:[e-mail]>>, Dino Farinacci <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, dmm <[e-mail]<mailto:[e-mail]>>
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) <[e-mail]<mailto:[e-mail]>> 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

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" <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, February 6, 2018 at 1:23 PM
To: Marco Liebsch <[e-mail]<mailto:[e-mail]>>, Sri Gundavelli <[e-mail]<mailto:[e-mail]>>, Dino Farinacci <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, dmm <[e-mail]<mailto:[e-mail]>>
Subject: RE: [Ila] [DMM] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt


Marco, Sri:



Here is the services based 5G architecture.



[cid:image001.png@01D3A01D.4969C2C0]



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.



[cid:image002.png@01D3A01D.4969C2C0]



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



[cid:image003.png@01D3A01D.4969C2C0]



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:[e-mail]] On Behalf Of Marco Liebsch
Sent: Tuesday, February 6, 2018 12:09 PM
To: Sri Gundavelli (sgundave) <[e-mail]<mailto:[e-mail]>>; Dino Farinacci <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; dmm <[e-mail]<mailto:[e-mail]>>
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-----

From: dmm [mailto:[e-mail]] On Behalf Of Sri Gundavelli (sgundave)

Sent: Dienstag, 6. Februar 2018 04:07

To: Dino Farinacci

Cc: dmm; [e-mail]<mailto:[e-mail]>

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" <[e-mail]<mailto:[e-mail]>> 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

>>

>>

>>

>> On 2/5/18, 6:42 PM, "Dino Farinacci" <[e-mail]<mailto:[e-mail]>> 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

>>>

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

>>>> <[e-mail]<mailto:[e-mail]>> wrote:

>>>>

>>>> 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"

>>>> <[e-mail]<mailto:[e-mail]>> wrote:

>>>>

>>>>> 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:[e-mail]] On Behalf Of Dino

>>>>>Farinacci

>>>>> Sent: Monday, February 5, 2018 7:32 PM

>>>>> To: Bogineni, Kalyani <[e-mail]<mailto:[e-mail]>>

>>>>> Cc: Tom Herbert <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; dmm

>>>>><[e-mail]<mailto:[e-mail]>>;  Sri Gundavelli (sgundave) <[e-mail]<mailto:[e-mail]>>

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

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

>>>>>

>>>>>> On Feb 6, 2018, at 5:04 AM, Bogineni, Kalyani

>>>>>> <[e-mail]<mailto:[e-mail]>> wrote:

>>>>>>

>>>>>> Dino:

>>>>>>

>>>>>> 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?

>>>>>

>>>>> There are references throughout the draft where you see eNodeB and

>>>>>pGW  that UPF functionality could be at the same network mode

>>>>>location.

>>>>>

>>>>> Dino

>>>>> _______________________________________________

>>>>> ila mailing list

>>>>> [e-mail]<mailto:[e-mail]>

>>>>>

>>>>>

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

>>>>>ail

>>>>>ma

>>>>> n_

>>>>>

>>>>>

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

>>>>>&r=

>>>>>Id

>>>>> iS

>>>>>

>>>>>

>>>>>ODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT&m=zf1K

>>>>>fRu

>>>>>4n

>>>>> UF

>>>>>

>>>>>

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

>>>>>u0X

>>>>>6l

>>>>> pS

>>>>> iBvg&e=

>>>>

>>>

>>

>



_______________________________________________

dmm mailing list

[e-mail]<mailto:[e-mail]>

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

[e-mail]<mailto:[e-mail]>

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=

_______________________________________________
dmm mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/dmm