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

[Behcet Sarikaya <[e-mail]>]

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.
> ietf.org_mailman_listinfo_dmm&d=DwIFAw&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LR
> xpb6__0PomBTQ&r=IdiSODh8aDRjdCeGgd9MznLHMYKgKcs_
> YSwXBDiaofh47oilzaXYRYETcBynUdpT&m=lWGVj8Jd11JyGVLcPLOSIxTZ-
> YHY3VbtfD1mi2uqhOY&s=-EIvAEYOQusoChy_iwtR4nMkaEqRKBTKTJ8GDjADuCk&e=
>
>
>
> _______________________________________________
>
> ila mailing list
>
> [e-mail]
>
> 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=
>
> _______________________________________________
> dmm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmm
>
>