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

Marco Liebsch <Marco.Liebsch@neclab.eu> Tue, 06 February 2018 17:09 UTC

Return-Path: <Marco.Liebsch@neclab.eu>
X-Original-To: ila@ietfa.amsl.com
Delivered-To: ila@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CE8012D856; Tue, 6 Feb 2018 09:09:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level:
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRFMgiNEZrYc; Tue, 6 Feb 2018 09:09:39 -0800 (PST)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9C1F126CF6; Tue, 6 Feb 2018 09:09:38 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id D154F103B42; Tue, 6 Feb 2018 18:09:36 +0100 (CET)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jpyoRPoNHROo; Tue, 6 Feb 2018 18:09:36 +0100 (CET)
X-ENC: Last-Hop-TLS-encrypted
X-ENC: Last-Hop-TLS-encrypted
Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id AE1B1103B3A; Tue, 6 Feb 2018 18:09:28 +0100 (CET)
Received: from PALLENE.office.hd ([169.254.1.144]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.03.0319.002; Tue, 6 Feb 2018 18:09:28 +0100
From: Marco Liebsch <Marco.Liebsch@neclab.eu>
To: "Sri Gundavelli (sgundave)" <sgundave@cisco.com>, Dino Farinacci <farinacci@gmail.com>
CC: dmm <dmm@ietf.org>, "ila@ietf.org" <ila@ietf.org>
Thread-Topic: [DMM] [Ila] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt
Thread-Index: AQHTnugX1NNjtJ/ocUSKKWFw5WqVraOWhNuAgAAUzoCAAAGEAIAAAVoAgAAD6QCAAPkdwA==
Date: Tue, 06 Feb 2018 17:09:27 +0000
Message-ID: <69756203DDDDE64E987BC4F70B71A26DD5AEDF95@PALLENE.office.hd>
References: <151750859755.24445.6929673804211867286.idtracker@ietfa.amsl.com> <CAPDqMerbX4UJ-mK-A-f=im=1h0Yz-52QfWLLgVDkybtSShNp5Q@mail.gmail.com> <D698D3B3.2A3906%sgundave@cisco.com> <D43DF85C-75F6-445B-895F-D27CE3285061@gmail.com> <D698E00C.10A01%sgundave@cisco.com> <b9d5a581af5c46d3834f080c8e62b6a3@scwexch12apd.uswin.ad.vzwcorp.com> <1ED57BC0-DBE3-49A9-801C-7F19EE98ECE9@gmail.com> <5d6067277f484e78b561cf511f9d2861@scwexch12apd.uswin.ad.vzwcorp.com> <D69E42B4.10DB3%sgundave@cisco.com> <60D36175-0CB4-48E1-98C1-B7B1CAA0B876@gmail.com> <D69E5671.10DCE%sgundave@cisco.com> <680D7F3C-8417-40A3-856D-205D77B21AA6@gmail.com> <D69E5971.10DDB%sgundave@cisco.com>
In-Reply-To: <D69E5971.10DDB%sgundave@cisco.com>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.1.6.170]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ila/aPUcYtVQABqtDW-qAhX00GzxTG0>
Subject: Re: [Ila] [DMM] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt
X-BeenThere: ila@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Identifier Locator Addressing <ila.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ila>, <mailto:ila-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ila/>
List-Post: <mailto:ila@ietf.org>
List-Help: <mailto:ila-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ila>, <mailto:ila-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Feb 2018 17:09:42 -0000

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-bounces@ietf.org] On Behalf Of Sri Gundavelli (sgundave)
Sent: Dienstag, 6. Februar 2018 04:07
To: Dino Farinacci
Cc: dmm; ila@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" <farinacci@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" <farinacci@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) 
>>>> <sgundave@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.Bogineni@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-bounces@ietf.org] On Behalf Of Dino 
>>>>>Farinacci
>>>>> Sent: Monday, February 5, 2018 7:32 PM
>>>>> To: Bogineni, Kalyani <Kalyani.Bogineni@VerizonWireless.com>
>>>>> Cc: Tom Herbert <tom@quantonium.net>; ila@ietf.org; dmm 
>>>>><dmm@ietf.org>;  Sri Gundavelli (sgundave) <sgundave@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.Bogineni@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
>>>>> ila@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://www.ietf.org/mailman/listinfo/dmm