On Wed, Feb 7, 2018 at 11:50 AM, Sri Gundavelli (sgundave) < [email protected]> 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 <[email protected]> > Reply-To: "[email protected]" <[email protected]> > Date: Wednesday, February 7, 2018 at 9:44 AM > To: Sri Gundavelli <[email protected]> > Cc: "Bogineni, Kalyani" <[email protected]>, Marco > Liebsch <[email protected]>, Dino Farinacci <[email protected]>, " > [email protected]" <[email protected]>, dmm <[email protected]> > > 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 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.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 >> >> [email protected] >> >> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/dmm >> >> >
_______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
