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

Tom Herbert <tom@quantonium.net> Tue, 06 February 2018 19:05 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 8F8B212D872 for <ila@ietfa.amsl.com>; Tue, 6 Feb 2018 11:05:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 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, URIBL_BLOCKED=0.001] 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 7XdSO4WPLc2S for <ila@ietfa.amsl.com>; Tue, 6 Feb 2018 11:05:10 -0800 (PST)
Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::22f]) (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 6C97F12D87D for <ila@ietf.org>; Tue, 6 Feb 2018 11:04:52 -0800 (PST)
Received: by mail-wr0-x22f.google.com with SMTP id t94so3094571wrc.5 for <ila@ietf.org>; Tue, 06 Feb 2018 11:04:52 -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=1W5yKRqz7T8v0G2mg4+03GykF5tOYMMlfweRK5hWiZM=; b=Efwh7QUkstRu4dlG9FHG2JyGPnxv8bm2DN5Moq+KKHUwqbOtPeZkyLBClLsn13NABv F6BHx97eRFFvd4vxjoK35pU+XWoT6OAttiO6iYe/BD52y3eDfbbWv0FLBKbt7NT1+g3K aKO1HgGj65LmctoqXDt1DJLgGDcOsLt3aqLbvJ5Bbq0oUM7B8VCl+j3+glSI6IMtHp4s RiPAXZxdiIRwaDHVJ8hd2KgNJUC0dyluPTnW2pIfDW/wWz+7VITQsiBRA0laH2z+yFGv lDd/sRqbEHmrBr6aXXDx/EWo9t30GJi8MECHhd20mse0qJMj1Yh8kkAGcEzWyecAbqvG 6NOA==
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=1W5yKRqz7T8v0G2mg4+03GykF5tOYMMlfweRK5hWiZM=; b=pt8DUWolWRbxRB3GVCedYud1mPS47J9aLz2u5EFk1rMi+5+Ba7Jh9eGwlzw5NoydPm 5UL1ChYZpzN+dzS5GyEF6Kqvxda4aoWHncARP0CYmjRFzsglzYhH1Rma+UfuMaDBv1rH MB6GeGX9b2oAwoOAYrOi+catJt+fX6Hz0pUISFGHV+e0nWuNoHzROZs7wX2X6aLfaBPI 167y1+cy2t00sobwMmLvdsKntOGpX0Zu4ZevqYf99uFMz4HDJWLmijE5FfgR6u16VOKm 1REz+8e2rfU/WF4hi2uSLayurPXrgYnTjiwd2iTeXKZj8iRRn2AMmask5ligiHj2WDDS Dm3A==
X-Gm-Message-State: APf1xPBuxochXmuRHM8uVqtnppGCTVFFI5OYJnMTxv8/HLJHF98iGWzJ bK+eFHvmCm67Huc712Rgs3LwcPvf7La4fJ2CV0yWvg==
X-Google-Smtp-Source: AH8x2250wuPvcsTt4yRtNGZLIVDRE5cDHnvUy/HKvpEO/YuYeQwy2kJTaeLNzYI9gxa4lcdVezPOq/b3R0YuHLo9vVo=
X-Received: by 10.223.130.234 with SMTP id 97mr3196787wrc.144.1517943890878; Tue, 06 Feb 2018 11:04:50 -0800 (PST)
MIME-Version: 1.0
Received: by 10.223.173.66 with HTTP; Tue, 6 Feb 2018 11:04:49 -0800 (PST)
In-Reply-To: <D69E82AC.2A3DE1%sgundave@cisco.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> <D69E7528.2A3DA3%sgundave@cisco.com> <CAPDqMerANSChdLHvhCcKbdz4fQixh2Q_SZd3Grnq750fdP=SSg@mail.gmail.com> <D69E82AC.2A3DE1%sgundave@cisco.com>
From: Tom Herbert <tom@quantonium.net>
Date: Tue, 06 Feb 2018 11:04:49 -0800
Message-ID: <CAPDqMeqH1UbVOWM9qmGov3ieL0ObR5N3kM8DFVk_6ozkYNFeag@mail.gmail.com>
To: "Sri Gundavelli (sgundave)" <sgundave@cisco.com>
Cc: Lorenzo Colitti <lorenzo@google.com>, "ila@ietf.org" <ila@ietf.org>, dmm <dmm@ietf.org>
Content-Type: multipart/alternative; boundary="001a114b2dce67b64505648fda2b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ila/0JH8m6IMxUgjqmJA34nENMNXkXI>
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: Tue, 06 Feb 2018 19:05:13 -0000

HI Sri,

On Mon, Feb 5, 2018 at 10:25 PM, Sri Gundavelli (sgundave) <
sgundave@cisco.com> wrote:

> Tom:
>
> Thanks! That sounds like some  interesting trick. But, let me make sure I
> understood this correctly.  So, the
>
identifier space for the MN is encoded in the upper 64-bits. Now, the UE
> can use those bits to generate any Identifier from that space, and use it
> with the SIR prefix to form the 128 bit address.  Bear with me, let me use
> an example
>
> MN1 is assigned a prefix  *2001:ABCD:CAFÉ*:   / 48
> MN2 is assigned a prefix  *2001:ABCD:FOOD*:  /48
>
> The SIR Prefix for that ILA domain is  2001:DB8::/64
>
> So, the SIR Addresses can be formed using the  16-bit identifier space
> left from the /48 prefix assignment? UE can form any identifier from bit
> space?
>
> No, we want allow a full /64 assignment since that is being already
deployed.


> I can’t figure out the scheme from this below text in 6.3.2. I think I am
> missing the context here. May be you guys discussed this before.
>

>
----
>
>    To support /64 prefix assignment with ILA, the ILA identifier can be
>    encoded in the the upper sixty-four bits of an address and the lower
>
>    sixty-four bits are ignored by ILA. Since only a subset of bits are
>    available, a level of indirection can be used so that ILA transforms
>    the upper sixty four bits to contain both a locator and an index into
>    a locator (ILA-N) specific table. The entry in the table provides the
>    original sixty-four bit prefix so that ILA to SIR address
>    transformation can be done.
>
> -----
>
>
The SIR prefix and identifier are encoded in the upper 64 bits. Assuming
the network has a /24, and address for /64 assignment might have this
format.

Network                    SIR/identifier                 IID
    24 bits                   40 bits                           64 bits
------------------------|------------------------------|--------------------------------------------------|

The IID part is arbitrarily assigned by the device, so that is ignored by
ILA. All routing, lookups, and transformations (excepting checksum neutral
mapping)  are based in upper sixty-four bits.

For SIR->ILA  transformation, a lookup is done on the upper sixty four
bits. That returns a locator that would have format something like:

 Network                   Locator                 Locator_index

    24 bits                   20 bits                  20 bits
------------------------|-----------------------|--------------------------|

The packet is forwarded and routed to the ILA addressed by locator (/44
route). ILA, the locator index is used as a key to an ILA-N specific  table
that returns the 40 bit SIR/identifier. This value is then written in the
packet do ILA->SIR transformation thereby restoring the original address.

The locator index is not globally unique, it is specific to each ILA-N.
When a node attaches to an ILA-N, an index is chosen so that the table is
populated at the ILA-N and the ILA mapping includes the locator and index.
When a node detaches from on ILA, it's entry in the table is removed and
the index can be reused after a holddown period to purge stale mappings.

Tom



> From: Tom Herbert <tom@quantonium.net>
> Date: Monday, February 5, 2018 at 9:13 PM
> To: Sri Gundavelli <sgundave@cisco.com>
> Cc: Lorenzo Colitti <lorenzo@google.com>, "ila@ietf.org" <ila@ietf.org>,
> dmm <dmm@ietf.org>
> Subject: Re: [DMM] Fwd: New Version Notification for
> draft-herbert-ila-mobile-00.txt
>
>
>
> On Mon, Feb 5, 2018 at 9:07 PM, Sri Gundavelli (sgundave) <
> sgundave@cisco.com> wrote:
>
>> > best practice is not to use singleton addresses, but always to provide
>> a /64 prefix.
>>
>> But, how does that work with ILA's approach of identifier management?
>> With the previously IETF recommended approaches in RFC5213 and even in 3GPP
>> architecture, per RFC3315, the network assigned  a set of unique prefixes
>> for each MN, allowed the MN to generate the identifiers.  Even CGA
>> addressing worked with the per-MN prefix model.
>>
>> But, with ILA there is no concept of prefix assignment. Will ILA network
>> now generate a identifier block for each MN?  Is DHCPv6 the only approach?
>>
>> Sri, see section 6.3.2. That describes encoding the identifier in the
> upper sixty-four bits and using an indirection table to accommodate network
> prefixes.
>
> Tom
>
> If that block is not summarizable, will it not result in mapping table
>> size getting multiple many times?
>>
>>
>> Sri
>>
>>
>>
>>
>>
>> From: dmm <dmm-bounces@ietf.org> on behalf of Lorenzo Colitti <
>> lorenzo@google.com>
>> Date: Monday, February 5, 2018 at 8:52 PM
>> To: Tom Herbert <tom@quantonium.net>
>> Cc: "ila@ietf.org" <ila@ietf.org>, dmm <dmm@ietf.org>
>> Subject: Re: [DMM] Fwd: New Version Notification for
>> draft-herbert-ila-mobile-00.txt
>>
>> On Fri, Feb 2, 2018 at 6:27 AM, Tom Herbert <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.
>>
>
>