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

Alexandre Petrescu <alexandre.petrescu@gmail.com> Sat, 10 February 2018 13:33 UTC

Return-Path: <alexandre.petrescu@gmail.com>
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 7DBD1127873; Sat, 10 Feb 2018 05:33:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.632
X-Spam-Level:
X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, 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 x2GZklduspsx; Sat, 10 Feb 2018 05:33:22 -0800 (PST)
Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09614120727; Sat, 10 Feb 2018 05:33:21 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w1ADXJ7q161880; Sat, 10 Feb 2018 14:33:19 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id CDA422024E1; Sat, 10 Feb 2018 14:33:19 +0100 (CET)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id BDB432013C0; Sat, 10 Feb 2018 14:33:19 +0100 (CET)
Received: from [132.166.84.51] ([132.166.84.51]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w1ADXIQU009391; Sat, 10 Feb 2018 14:33:19 +0100
To: Tom Herbert <tom@quantonium.net>
Cc: dmm <dmm@ietf.org>, ila@ietf.org
References: <151750859755.24445.6929673804211867286.idtracker@ietfa.amsl.com> <CAPDqMerbX4UJ-mK-A-f=im=1h0Yz-52QfWLLgVDkybtSShNp5Q@mail.gmail.com> <CAKD1Yr0Xpi=3mn8VfQ3eRm4ZWWDfYd10e+y3EUcY2rX-FaYbXw@mail.gmail.com> <e31d671d-97e5-bb34-0017-6bba78fbe52e@gmail.com> <CAPDqMepVHPg-DePV0HSMG429G=3Dwwauy71NPYCq1em_GN8L5Q@mail.gmail.com> <a8c9b2de-ee5b-40b5-9f2e-ad8754c7fc01@gmail.com> <CAPDqMer4f+BQEzjD-4S3Hy6xXyEjKtsHc-c+iyXP48dwF1gUTg@mail.gmail.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <17e22313-6426-2895-6f08-abe177e98dfb@gmail.com>
Date: Sat, 10 Feb 2018 14:33:18 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <CAPDqMer4f+BQEzjD-4S3Hy6xXyEjKtsHc-c+iyXP48dwF1gUTg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ila/VPZYd1VIRI-TgOFXpY9yLe1CSw8>
Subject: Re: [Ila] [DMM] 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: Sat, 10 Feb 2018 13:33:24 -0000


Le 09/02/2018 à 17:18, Tom Herbert a écrit :
> 
> 
> On Fri, Feb 9, 2018 at 12:09 AM, Alexandre Petrescu 
> <alexandre.petrescu@gmail.com <mailto:alexandre.petrescu@gmail.com>> wrote:
> 
> 
> 
>     Le 07/02/2018 à 18:29, Tom Herbert a écrit :
> 
> 
> 
>         On Wed, Feb 7, 2018 at 8:49 AM, Alexandre Petrescu
>         <alexandre.petrescu@gmail.com
>         <mailto:alexandre.petrescu@gmail.com>
>         <mailto:alexandre.petrescu@gmail.com
>         <mailto:alexandre.petrescu@gmail.com>>>
>         wrote:
> 
> 
> 
>         Le 06/02/2018 à 05:52, Lorenzo Colitti a écrit :
> 
>         On Fri, Feb 2, 2018 at 6:27 AM, Tom Herbert <tom@quantonium.net
>         <mailto:tom@quantonium.net> <mailto:tom@quantonium.net
>         <mailto:tom@quantonium.net>> <mailto:tom@quantonium.net
>         <mailto:tom@quantonium.net> <mailto:tom@quantonium.net
>         <mailto:tom@quantonium.net>>>> wrote:
> 
>         We like like to request that the dmm WG consider ILA as a
>         candidate protocol for the 3GPP "Study on User Plane Protocol in
>         5GC".
> 
> 
>         Echoing Tom's earlier comment about this: I think the address
>         assignment sections (6.3 and 8.3) should be reworded to clarify that
>         for general purpose hosts, best practice is not to use singleton
>         addresses, but always to provide a /64 prefix.
> 
> 
>         I would say a prefix yes, but prefer a /63 and shorter.
> 
>         Alex,
> 
>         I'm curious as to why you'd need even shorter prefixes.
> 
> 
>     This is an optional accessory.
> 
> 
>     A /63 prefix is beneficial for a Mobile Router, or 'IoT Router', for
>     local area tethering, or for in-vehicle networks.  It gets a /63 from
>     the ISP and makes two /64s out of it.  One for its WiFi interface and
>     one for its Ethernet interface.
> 
> Alex,
> 
> Why not just get a /64 for WIFI and one for Ethernet?

YEs, makes sense.

In that case we talk about providing multiple /64s to end-user.

> That would be the 
> common case any way if they are attached to two different providers.

But this does not make sense.

In this optional accessory case, we dont want the user terminal to 
connect to two providers in order to get two /64s.  We want it to 
connect it one LTE provider and get at least two /64s for the same 
connection.

> 
>     If it only gets a /64 then it cant make other /64s out of it and it
>     can't route.
> 
> 
> I'm a bit amused by the phrase "only gets a /64". Assigning a /64 to a 
> device is the equivalent of assigning four billion IPv4 address spaces 
> after all! Why not just carve up a /64 into bunch of /96s or something 
> like that for down stream allocation?

That carving out can be made, yes.

But what to do with a /96?  A router could put that /96 in an RA, but a 
Host receiving it can not make an address out of it.

Alex

> 
> Tom