Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08

Peter McCann <Peter.McCann@huawei.com> Fri, 02 December 2016 20:19 UTC

Return-Path: <Peter.McCann@huawei.com>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39325127078; Fri, 2 Dec 2016 12:19:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.117
X-Spam-Level:
X-Spam-Status: No, score=-7.117 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_PASS=-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 7SVirguY5Anq; Fri, 2 Dec 2016 12:19:07 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26EC0128BA2; Fri, 2 Dec 2016 12:19:07 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DBV06581; Fri, 02 Dec 2016 20:19:05 +0000 (GMT)
Received: from SZXEML429-HUB.china.huawei.com (10.82.67.184) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 2 Dec 2016 20:19:04 +0000
Received: from SZXEML503-MBS.china.huawei.com ([169.254.7.244]) by SZXEML429-HUB.china.huawei.com ([10.82.67.184]) with mapi id 14.03.0235.001; Sat, 3 Dec 2016 04:19:00 +0800
From: Peter McCann <Peter.McCann@huawei.com>
To: "sarikaya@ieee.org" <sarikaya@ieee.org>
Thread-Topic: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08
Thread-Index: AQHSSbnrlOvyfD5HhUuLK//TKkT+rKD0YrSAgACxlZD//4HaAIAAhmjg//97iACAAIbHYA==
Date: Fri, 02 Dec 2016 20:18:59 +0000
Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE77DB598E5@SZXEML503-MBS.china.huawei.com>
References: <148036629464.5478.15248622721170321679.idtracker@ietfa.amsl.com> <6E8FD89A-A217-4958-8DF8-EE7D0CD77F13@gmail.com> <CAKD1Yr3nCfMFz_1wqvDmiyMK2OiKZAwYTv2GKN9axf7JuOdtxA@mail.gmail.com> <5963DDF1F751474D8DEEFDCDBEE43AE77DB5988B@SZXEML503-MBS.china.huawei.com> <CAKD1Yr3J0XQSLGHBX52pD8rGbk-UsSqfJpUkBSDOvO3k9ORSaw@mail.gmail.com> <5963DDF1F751474D8DEEFDCDBEE43AE77DB598CA@SZXEML503-MBS.china.huawei.com> <CAC8QAce3j25y3MdOrV3mJQmN=hL-D-WK2kRgfGe4bhQ4KSoTjA@mail.gmail.com>
In-Reply-To: <CAC8QAce3j25y3MdOrV3mJQmN=hL-D-WK2kRgfGe4bhQ4KSoTjA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.193.125.244]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.5841D739.03CB, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.7.244, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: b6fb876f5e0792fc87db06614529f370
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmm/hUxBSQ2mGxzSplAuQ1necwsxhEE>
Cc: "draft-ietf-dmm-ondemand-mobility@ietf.org" <draft-ietf-dmm-ondemand-mobility@ietf.org>, "dmm@ietf.org" <dmm@ietf.org>
Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Dec 2016 20:19:12 -0000

Maybe I missed Lorenzo's point and talked past him, though.

I agree we should be talking about the state maintained for a prefix and not individual addresses.  At least, for IPv6.

There is still a state management problem and we need to decide whether explicit signaling is required.

-Pete


-----Original Message-----
From: Behcet Sarikaya [mailto:sarikaya2012@gmail.com] 
Sent: Friday, December 02, 2016 3:15 PM
To: Peter McCann <Peter.McCann@huawei.com>
Cc: Lorenzo Colitti <lorenzo@google.com>; draft-ietf-dmm-ondemand-mobility@ietf.org; dmm@ietf.org
Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08

Lorenzo,
It is 3GPP practice (or law, should I say) is to assign a prefix in
IPv6 to the UE. That is what Peter is talking about.

Regards,

Behcet

On Fri, Dec 2, 2016 at 2:12 PM, Peter McCann <Peter.McCann@huawei.com> wrote:
> With a fixed access network the prefix can be assigned to the link and 
> used by anyone who joins the link.
>
>
>
> With a prefix offering mobility the prefix belongs to the mobile host 
> and needs to move with it.  There aren’t enough prefixes (even in 
> IPv6) to assign a permanent prefix to each UE for every topological 
> attachment point that it might visit or start a session from.
>
>
>
> -Pete
>
>
>
>
>
> From: Lorenzo Colitti [mailto:lorenzo@google.com]
> Sent: Friday, December 02, 2016 3:09 PM
> To: Peter McCann <Peter.McCann@huawei.com>
> Cc: jouni.nospam <jouni.nospam@gmail.com>; 
> draft-ietf-dmm-ondemand-mobility@ietf.org; dmm@ietf.org
> Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08
>
>
>
> But you have that problem with IP addresses as well, right? I don't 
> see how "assigning a prefix with certain properties" requires more 
> state in the network than "assigning an IP address with certain properties".
>
>
>
> On Fri, Dec 2, 2016 at 12:00 PM, Peter McCann 
> <Peter.McCann@huawei.com>
> wrote:
>
> Providing any kind of mobility service for a prefix will require some 
> state somewhere in the network.  It would be great to avoid an 
> allocation request / response for the prefix, but the state has to be 
> created somehow before the UE can use the prefix and it has to be 
> reclaimed eventually after the UE stops using the prefix (which may 
> not be until well after it disconnects from the current link and moves to another one).
>
>
>
> Would welcome any suggestions on how to manage this state.
>
>
>
> -Pete
>
>
>
>
>
> From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Lorenzo Colitti
> Sent: Friday, December 02, 2016 12:04 PM
> To: jouni.nospam <jouni.nospam@gmail.com>
> Cc: draft-ietf-dmm-ondemand-mobility@ietf.org; dmm@ietf.org
> Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08
>
>
>
> Hi,
>
>
>
> I like the goal of reducing network cost by allowing the use of IP 
> addresses that do not require network mobility, but we should not be 
> doing this by requesting IP addresses from the network, because this 
> violates IPv6 address assignment best practices.
>
>
>
> Specifically, RFC 7934 recommends that a) the network should provide 
> multiple addresses from each prefix and b) the network should allow 
> the host to use new addresses without requiring explicit requests to the network.
> This is in conflict with at least this text in the draft, which says:
>
>
>
>    In case an application
>
>    requests one, the IP stack shall make an attempt to configure one 
> by
>
>    issuing a request to the network.  If the operation fails, the IP
>
>    stack shall fail the associated socket request
>
>
>
> One way to resolve this conflict would be to say that the network must 
> not assign individual addresses, but /64 (or shorter) prefixes. So if 
> the device desires to use fixed IPv6 addresses, then the network 
> should give the host a fixed IPv6 prefix from which the host can form 
> as many addresses as it wants.
>
>
>
> I do not think we should advance this document until the conflicts are 
> resolved. This document is about IPv6 address assignment to mobile 
> nodes, and we should not publish a document about IPv6 address 
> assignment that conflicts with best current practices on IPv6 address assignment.
>
>
>
> Regards,
>
> Lorenzo
>
>
>
> On Mon, Nov 28, 2016 at 12:56 PM, jouni.nospam 
> <jouni.nospam@gmail.com>
> wrote:
>
> Folks,
>
>
>
> The authors of draft-ietf-dmm-ondemand-mobility-07 and 
> draft-sijeon-dmm-use-cases-api-source have come up with a merged 
> document draft-ietf-dmm-ondemand-mobility-08.
>
>
>
> This email starts a 2 week WGLC for draft-ietf-dmm-ondemand-mobility-08.
>
> The WGLC starts 11/28/16 and ends 12/12/16.
>
>
>
> Provide your comments, concerns and approvals to the email list (and 
> hopefully also to IssueTracker).
>
>
>
> - Jouni & Dapeng
>
>
>
>
>
>
>
> Begin forwarded message:
>
>
>
> From: IETF Secretariat <ietf-secretariat-reply@ietf.org>
>
> Subject: IETF WG state changed for draft-ietf-dmm-ondemand-mobility
>
> Date: November 28, 2016 at 12:51:34 PM PST
>
> To: <draft-ietf-dmm-ondemand-mobility@ietf.org>, 
> <dmm-chairs@ietf.org>, <max.ldp@alibaba-inc.com>
>
> Resent-From: <alias-bounces@ietf.org>
>
> Resent-To: jouni.nospam@gmail.com, maxpassion@gmail.com
>
>
>
>
> The IETF WG state of draft-ietf-dmm-ondemand-mobility has been changed 
> to "In WG Last Call" from "WG Document" by Jouni Korhonen:
>
> https://datatracker.ietf.org/doc/draft-ietf-dmm-ondemand-mobility/
>
>
> Comment:
> WGLC starts 11/28/16 and ends 12/12/16.
>
>
>
>
> _______________________________________________
> 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
>