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

Lorenzo Colitti <lorenzo@google.com> Mon, 05 December 2016 02:21 UTC

Return-Path: <lorenzo@google.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 621F41296A2 for <dmm@ietfa.amsl.com>; Sun, 4 Dec 2016 18:21:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.596
X-Spam-Level:
X-Spam-Status: No, score=-5.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 pvd2LtBpF2zA for <dmm@ietfa.amsl.com>; Sun, 4 Dec 2016 18:21:12 -0800 (PST)
Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EA62129681 for <dmm@ietf.org>; Sun, 4 Dec 2016 18:21:12 -0800 (PST)
Received: by mail-io0-x232.google.com with SMTP id c21so530020545ioj.1 for <dmm@ietf.org>; Sun, 04 Dec 2016 18:21:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=q8NIzCJBo+9fp3CH7+t7FSAADP9Ote+l7nARX4tHAB0=; b=PHO1YGU9O9OGaIrR80biYrvl6UirXOvP/Vvl+Qc5XNWfEQB7JJhZ4i6mnz8JwVSLtX S07u+ab82EFMYqpqVXbfwNrenryIEcIC3vNxUvYvM8M7jb1JGl67mHvilQ68hqgEdv6+ 7dtk1bDN3n0XONVDRbbH3cs980fSy+9OhRuCuQvjCkfnuvao59oYYirmyjWzEmp6e6iJ dUSHMJ7KnTCRfU/HN+uvj1bxw2iir6A60UcQwkGAd6NQJH1eC+aLNadciSzRhB4Esffj JrQroCvY3ONq6vL2TfvEiGHqItKn907d+PF3jaRw4NnGN8WJw6I6KvJRNh9n8mZcFn6e zBtQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=q8NIzCJBo+9fp3CH7+t7FSAADP9Ote+l7nARX4tHAB0=; b=C292mJ3xhaLG9BjZ/caafdiOxldCmlo5/9Zcp8y7KDmQZoQvWKUacPZgSGXh0TQaY3 ENOKES9nItjIHHelIj7XrEphXTZ4uV5k5qF3KkwPILXawqZoTsF7wVrOj7IGv+lQoaDy dvL/jJTD/pCAgKQuWKa+Zj8Db5XtFL9JGGbTPZMr13Z4niP63ZSDGfqEzRJ4kEpPwmhL CgFK3oz3o9xYymSKJ9cy9CNQkdzv9SwvDxuyKKdLdN0TkpeRyhxKx6InOgjwcMtkD2Rl SXAnq17Aoq0rWOYShj98vov3kLKYbt3SqstMDk8U6KkF4QWRv+JyVc8Zz9T48Ym5mKB7 qwig==
X-Gm-Message-State: AKaTC03L4+OzE73/9tCFkINuAlxQu5txOKFSoiTmMY+BcUFqI7fUhe+DHGZzw0fBouS83M0wCDwPpCvCOfTsBITC
X-Received: by 10.36.178.81 with SMTP id h17mr6628793iti.98.1480904471122; Sun, 04 Dec 2016 18:21:11 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.18.160 with HTTP; Sun, 4 Dec 2016 18:20:50 -0800 (PST)
In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE77DB59938@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> <CAKD1Yr1wzpyryb+T5N7FkVSpPfnZWKG_OH3izo35i8JjR=y+Ow@mail.gmail.com> <5963DDF1F751474D8DEEFDCDBEE43AE77DB59938@SZXEML503-MBS.china.huawei.com>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Sun, 04 Dec 2016 18:20:50 -0800
Message-ID: <CAKD1Yr3q_sAxXkhYJN6nGm9fXkX6xewstU6sRcKfY+h17OpHJg@mail.gmail.com>
To: Peter McCann <Peter.McCann@huawei.com>
Content-Type: multipart/alternative; boundary="f403045d96aef310bf0542dff0a2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmm/Krx0oGXttttGaYrmPFXbJeFBRks>
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: Mon, 05 Dec 2016 02:21:15 -0000

Agreed; if we want to support this sort of mobility it needs to be possible
to tell a MN that its previous prefix is no longer valid.

>From a technical perspective this can be done using router advertisements,
except for the 2-hour rule in RFC 4862 section 5.3.3. That rule exists to
prevent DOS attacks on shared links, so I think it would be reasonable to
update RFC 4862 to say that less-than-2-hour valid lifetimes are acceptable
if the link provides strong guarantees that there are no other nodes on
link that can mount such an attack.

On Fri, Dec 2, 2016 at 12:36 PM, Peter McCann <Peter.McCann@huawei.com>
wrote:

> Agree, I am not arguing in favor of sharing a prefix between two or more
> MNs at the same time.  However, I think it is important to reclaim a prefix
> for use by another MN after the current MN has moved to a new attachment
> point and stopped using the prefix it got from the old attachment point.
> It is also important to refrain from advertising the prefix to another MN
> until the current MN has stopped using it.  That is the network state I am
> talking about.
>
>
>
> -Pete
>
>
>
>
>
> *From:* Lorenzo Colitti [mailto:lorenzo@google.com]
> *Sent:* Friday, December 02, 2016 3:32 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
>
>
>
> On the particular case of shared links: note that they have substantial
> scalability and performance issues. In order for shared links to work you
> have to engage in DAD proxying, ND snooping, client isolation and all sorts
> of unsavoury and L2/L3 magic that does not scale. Some of these issues are
> described in RFC 7934 section 9.3. On shared links, these forces act to
> reduce the number of IP addresses per host that the network can support and
> leads to the negative consequences in section 4 of the document, which is
> why they are not recommended.
>
>
>
> For these and other reasons, on many public networks we're seeing a shift
> *away* from shared links - see, for example, draft-ietf-v6ops-unique-ipv6-prefix-per-host
> , and the current large deployments of that model in the form of Comcast
> community wifi.
>
>
>
> For many years 3GPP networks have been providing those benefits by
> providing a full /64 to every host. I would hate to lose those benefits.
>
>
>
> On Fri, Dec 2, 2016 at 12: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
>
>
>
>
>
>
>