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

"Sri Gundavelli (sgundave)" <sgundave@cisco.com> Tue, 06 February 2018 06:25 UTC

Return-Path: <sgundave@cisco.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 0E42B126CB6; Mon, 5 Feb 2018 22:25:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.529
X-Spam-Level:
X-Spam-Status: No, score=-14.529 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 3ogINN14Dz9n; Mon, 5 Feb 2018 22:25:56 -0800 (PST)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 835901200C1; Mon, 5 Feb 2018 22:25:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12716; q=dns/txt; s=iport; t=1517898356; x=1519107956; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=58HLFKo4N/rR3u00fAkaPO4g4BkYoM0Xb/Trz83AmMs=; b=G0DGwRpVCpTT70p9tpLY8uxM6LWO+1lFW5B7Pl2uughZ/M3b5jYSU/Gs XFvVA+k9SorJbToIdTihU+aG0lkZ2T+O0Dl/eTTDjbuAL/uFYDIl4KCHj vTv/1OU8SkOqOaCLY0Gr/56WYAEcqHqYy8UmPPSjtPNuK/SY3lpPQEjGy w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DXAQBzSXla/5BdJa1dGQEBAQEBAQEBAQEBAQcBAQEBAYJZeIFWKAqcL4ICkXOHDgNcCoU7AoJOVxUBAQEBAQEBAQJrKIUjAQEBAwF3AgULAgEIEQECAQIBJwcyFAMGCAIEDgWJUVwIu3iFAIN/gXgBAQEBAQEBAwEBAQEBAQEBAR+EaoIVgVeBZwGDLoMvBIIPBhCFRgWTFJEUApVwlDqXTgIRGQGBOwE1IzKBHnAVgwOEd3iOD4EXAQEB
X-IronPort-AV: E=Sophos;i="5.46,467,1511827200"; d="scan'208,217";a="134435932"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Feb 2018 06:25:55 +0000
Received: from XCH-ALN-007.cisco.com (xch-aln-007.cisco.com [173.36.7.17]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id w166PtJG004996 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 6 Feb 2018 06:25:55 GMT
Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-ALN-007.cisco.com (173.36.7.17) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 6 Feb 2018 00:25:54 -0600
Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1320.000; Tue, 6 Feb 2018 00:25:54 -0600
From: "Sri Gundavelli (sgundave)" <sgundave@cisco.com>
To: Tom Herbert <tom@quantonium.net>
CC: Lorenzo Colitti <lorenzo@google.com>, "ila@ietf.org" <ila@ietf.org>, dmm <dmm@ietf.org>
Thread-Topic: [DMM] Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt
Thread-Index: AQHTnxNXtngAOynE/Uaws1ah07/Rqw==
Date: Tue, 06 Feb 2018 06:25:54 +0000
Message-ID: <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>
In-Reply-To: <CAPDqMerANSChdLHvhCcKbdz4fQixh2Q_SZd3Grnq750fdP=SSg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.7.7.170905
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.20.188.60]
Content-Type: multipart/alternative; boundary="_000_D69E82AC2A3DE1sgundaveciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ila/Uuyytx9A-g2VoPkhtlyOFbaBM3g>
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 06:25:59 -0000

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?

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.

-----


From: Tom Herbert <tom@quantonium.net<mailto:tom@quantonium.net>>
Date: Monday, February 5, 2018 at 9:13 PM
To: Sri Gundavelli <sgundave@cisco.com<mailto:sgundave@cisco.com>>
Cc: Lorenzo Colitti <lorenzo@google.com<mailto:lorenzo@google.com>>, "ila@ietf.org<mailto:ila@ietf.org>" <ila@ietf.org<mailto:ila@ietf.org>>, dmm <dmm@ietf.org<mailto: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<mailto: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<mailto:dmm-bounces@ietf.org>> on behalf of Lorenzo Colitti <lorenzo@google.com<mailto:lorenzo@google.com>>
Date: Monday, February 5, 2018 at 8:52 PM
To: Tom Herbert <tom@quantonium.net<mailto:tom@quantonium.net>>
Cc: "ila@ietf.org<mailto:ila@ietf.org>" <ila@ietf.org<mailto:ila@ietf.org>>, dmm <dmm@ietf.org<mailto: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<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.