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

[Behcet Sarikaya <[e-mail]>]

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

> 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 :-)
>
>
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 <[e-mail]>
> Reply-To: "[e-mail]" <[e-mail]>
> Date: Wednesday, February 7, 2018 at 9:44 AM
> To: Sri Gundavelli <[e-mail]>
> Cc: "Bogineni, Kalyani" <[e-mail]>, Marco
> Liebsch <[e-mail]>, Dino Farinacci <[e-mail]>, "
> [e-mail]" <[e-mail]>, dmm <[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]> 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]>
>> Date: Tuesday, February 6, 2018 at 1:23 PM
>> To: Marco Liebsch <[e-mail]>, Sri Gundavelli <
>> [e-mail]>, Dino Farinacci <[e-mail]>
>> Cc: "[e-mail]" <[e-mail]>, dmm <[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.
>>
>>
>>
>>
>>
>> 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:[e-mail] <[e-mail]>] On Behalf
>> Of Marco Liebsch
>> Sent: Tuesday, February 6, 2018 12:09 PM
>> To: Sri Gundavelli (sgundave) <[e-mail]>; Dino Farinacci <
>> [e-mail]>
>> Cc: [e-mail]; dmm <[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] <[e-mail]>] On Behalf
>> Of Sri Gundavelli (sgundave)
>>
>> Sent: Dienstag, 6. Februar 2018 04:07
>>
>> To: Dino Farinacci
>>
>> Cc: dmm; [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]> 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]> 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]> 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]> 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] <[e-mail]>] On
>> Behalf Of Dino
>>
>> >>>>>Farinacci
>>
>> >>>>> Sent: Monday, February 5, 2018 7:32 PM
>>
>> >>>>> To: Bogineni, Kalyani <[e-mail]>
>>
>> >>>>> Cc: Tom Herbert <[e-mail]>; [e-mail]; dmm
>>
>> >>>>><[e-mail]>;  Sri Gundavelli (sgundave) <[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]> 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]
>>
>> >>>>>
>>
>> >>>>>
>>
>> >>>>>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]
>>
>> 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=
>>
>>
>>
>> _______________________________________________
>>
>> ila mailing list
>>
>> [e-mail]
>>
>> 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=
>>
>> _______________________________________________
>> dmm mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dmm
>>
>>
>