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