+1 There are only so many ways to do loc/id split. And if you mix and match you can take the best from each proposal for this particular use-case. Assuming combining the parts doesn’t lead to a zero sum (or negative sum) game.
Dino > On Feb 8, 2018, at 3:11 AM, Arashmid Akhavain <arashmid.akhav...@huawei.com> > wrote: > > +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:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli (sgundave) > Sent: 07 February 2018 12:50 > To: sarik...@ieee.org > Cc: dmm <dmm@ietf.org>; i...@ietf.org > 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 <sarikaya2...@gmail.com> > Reply-To: "sarik...@ieee.org" <sarik...@ieee.org> > Date: Wednesday, February 7, 2018 at 9:44 AM > To: Sri Gundavelli <sgund...@cisco.com> > Cc: "Bogineni, Kalyani" <kalyani.bogin...@verizonwireless.com>, Marco Liebsch > <marco.lieb...@neclab.eu>, Dino Farinacci <farina...@gmail.com>, > "i...@ietf.org" <i...@ietf.org>, dmm <dmm@ietf.org> > 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) > <sgund...@cisco.com> 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" <kalyani.bogin...@verizonwireless.com> > Date: Tuesday, February 6, 2018 at 1:23 PM > To: Marco Liebsch <marco.lieb...@neclab.eu>, Sri Gundavelli > <sgund...@cisco.com>, Dino Farinacci <farina...@gmail.com> > Cc: "i...@ietf.org" <i...@ietf.org>, dmm <dmm@ietf.org> > 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. > > > > <image001.png> > > > > 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. > > > > <image002.png> > > > > Option 2: Here there is no direct interface between Mapping Db and UPFs. UPFs > also support APIs like the control plane functions. > > > > <image003.png> > > > > 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:ila-boun...@ietf.org] On Behalf Of Marco Liebsch > Sent: Tuesday, February 6, 2018 12:09 PM > To: Sri Gundavelli (sgundave) <sgund...@cisco.com>; Dino Farinacci > <farina...@gmail.com> > Cc: i...@ietf.org; dmm <dmm@ietf.org> > > 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:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli (sgundave) > > Sent: Dienstag, 6. Februar 2018 04:07 > > To: Dino Farinacci > > Cc: dmm; i...@ietf.org > > 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" <farina...@gmail.com> 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" <farina...@gmail.com> 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) > > >>>> <sgund...@cisco.com> 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" > > >>>> <kalyani.bogin...@verizonwireless.com> 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:ila-boun...@ietf.org] On Behalf Of Dino > > >>>>>Farinacci > > >>>>> Sent: Monday, February 5, 2018 7:32 PM > > >>>>> To: Bogineni, Kalyani <kalyani.bogin...@verizonwireless.com> > > >>>>> Cc: Tom Herbert <t...@quantonium.net>; i...@ietf.org; dmm > > >>>>><dmm@ietf.org>; Sri Gundavelli (sgundave) <sgund...@cisco.com> > > >>>>> 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 > > >>>>>> <kalyani.bogin...@verizonwireless.com> 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 > > >>>>> i...@ietf.org > > >>>>> > > >>>>> > > >>>>>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 > > dmm@ietf.org > > 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 > > i...@ietf.org > > 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 > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm
_______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
