IETF Logo Mail Archive

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

Tom Herbert <tom@quantonium.net> Fri, 09 February 2018 16:18 UTC

Return-Path: <tom@quantonium.net>
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 3A6411250B8 for <ila@ietfa.amsl.com>; Fri, 9 Feb 2018 08:18:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=quantonium-net.20150623.gappssmtp.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 POMoTayghsJC for <ila@ietfa.amsl.com>; Fri, 9 Feb 2018 08:18:06 -0800 (PST)
Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::22a]) (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 9CE131200FC for <ila@ietf.org>; Fri, 9 Feb 2018 08:18:05 -0800 (PST)
Received: by mail-wr0-x22a.google.com with SMTP id t94so8782118wrc.5 for <ila@ietf.org>; Fri, 09 Feb 2018 08:18:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quantonium-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=l+L8zO1+1KGgNUNgip23KsNDDfISkBBldAn9wxnd6dE=; b=EOunqTW66fizSLXj1sBeHKfW7hqYZEimdmijPAeMDZJ3wJ581WRV3AMpCdI8UMMQ3X lV8L5X3MWTKTc+w79h8sFctLx/XhLsiKC6jtC7YNc4xe7niljK/DcxoNt5GDAT2aw+9R 91dIlS49q3XtIZCEgqua474tlzoVHjHIFq1L5vnAG8rGuDzOZcCfXSDE1f5Hl8y8FW4F o2qjlFQ1jUTk2N4bXxLRSbiRjrUHX7qJK0WOzdXDWbIWB1NMLlRKDNUWYs5vWWV4ari6 sBh3cpr1UvbPh0H/sUVWWZubDWiPga0TQm5dX2z73vmn9zOVDiGRCdXXCL/z01VdUHtI sdmA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=l+L8zO1+1KGgNUNgip23KsNDDfISkBBldAn9wxnd6dE=; b=W9TGjdSebUIwWA4ibbR2ahJri6ghXDnr/FAk3GTGNfHsqPeHxz4QSxJZLnmBpUTgqj GtkwgBN53nXhf322BpEr5a5m5t2zLk/iXLuO5eh4NZrzV5uPLhcJgsVipxnVGe6L+nnF lgEHV2D/+vLGhoO/lvL/Gq5AkXo7Gy8jJEhrFxwfSSXDxnjKnDkNFwjKw4uJ9sRn1H1i Udj8aoTQmUXUVjxH1GFiUV2d01iOAmMdsBX5LtHbp0Qy1bY9odWj6Eh4oDGcD21f52LL Vk4WvEnf8UwNMLROIEx3MkWj2NDW4BZdB8fgbPd5rpoJXZOVkBoTOZEHUnZGUFOZq6DY jNvQ==
X-Gm-Message-State: APf1xPAd/+xZTVUjS05k6M6QfLPKStnX2mop9GOmQMLnLpoZBTVZSfgU YR4ZVv7ypBnL+3GNAKSDUCJCMDrIVaNExg51a+YMIQ==
X-Google-Smtp-Source: AH8x2271faZSnFGjs5+dJ0IkR2s08IgQ8QBIkM+vt16fPTNLXx3LyrfBK1/Gj0eZPULjaurNIWI+SIAk2nZhXYAopIo=
X-Received: by 10.223.134.163 with SMTP id 32mr2991574wrx.250.1518193084006; Fri, 09 Feb 2018 08:18:04 -0800 (PST)
MIME-Version: 1.0
Received: by 10.223.173.66 with HTTP; Fri, 9 Feb 2018 08:18:03 -0800 (PST)
In-Reply-To: <a8c9b2de-ee5b-40b5-9f2e-ad8754c7fc01@gmail.com>
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>
From: Tom Herbert <tom@quantonium.net>
Date: Fri, 09 Feb 2018 08:18:03 -0800
Message-ID: <CAPDqMer4f+BQEzjD-4S3Hy6xXyEjKtsHc-c+iyXP48dwF1gUTg@mail.gmail.com>
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Cc: dmm <dmm@ietf.org>, ila@ietf.org
Content-Type: multipart/alternative; boundary="001a1146a22079173d0564c9dfdd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ila/NOLflIQpL-9vY8SLjhbuuCi6wrU>
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: Fri, 09 Feb 2018 16:18:08 -0000

On Fri, Feb 9, 2018 at 12:09 AM, Alexandre Petrescu <
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>>
>> 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>>>
>> 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? That would be the
common case any way if they are attached to two different providers.


> 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?

Tom

v2.23.0 | Report a Bug | By Email