Re: [Int-area] ILA and int-area

Tom Herbert <tom@herbertland.com> Wed, 17 May 2017 15:07 UTC

Return-Path: <tom@herbertland.com>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3580D12EC74 for <int-area@ietfa.amsl.com>; Wed, 17 May 2017 08:07:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.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 lQr-Y8cCdXqm for <int-area@ietfa.amsl.com>; Wed, 17 May 2017 08:07:13 -0700 (PDT)
Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (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 06C1C12EB3E for <int-area@ietf.org>; Wed, 17 May 2017 08:00:21 -0700 (PDT)
Received: by mail-qk0-x22e.google.com with SMTP id y201so12238108qka.0 for <int-area@ietf.org>; Wed, 17 May 2017 08:00:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=c+B0kzw0J3gsDq1yBgLRdAqmFvsszr4JC5TeXoTBHFo=; b=tOefdlLgkhpdhtdzmUibaxX399rp0S5qkVYbX4SLs0pgbNJudpYGNVPCI+uFS9dB9t dvlmtKz/Ws75LMMkL2gT2NWkvghYfUYJIJawcEg0bH5oyj3nNJfVrGlsz7M/LiU3II9k ESbghMHSLXV9S5CR18f03FOCvzX2BsI9OV0QEIXcvkiEQyiKpyNsvmcsQRkB/VQ0CekL i44lzvCfCupFVHQYtL6C1HVFxiaBWTg1TCxdl4EuaHJ593qW+9F6LQltpi95XFElV9ft /KKoVrhzV109Qj2U5DgsDvjK6XmohKpLSeCLPg2nwt5h4kc+/V/nBEfZnJng1o2uXO/k hxYg==
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=c+B0kzw0J3gsDq1yBgLRdAqmFvsszr4JC5TeXoTBHFo=; b=afq6ccZnIQ9TLt6vxKeW9Y28+3d5vEV8s4z0OvqRDYn+HDT0KdiXip0wYskQZqmZLu CSTR7GGh5BdPCWD9FzZbt/Syp/jb0hAU+UZjoOT2lT+xY/Xuc1eHlU3l08UwEa8tHcPP ZBEEUEildVPGCQRC+w/nGTtjmysfqQWIBDFdPMUGq5odfcqYk7HZ3Uv/L7Ag7N8UkBvM px8MZzE/08GhdOtsAGHj8U6cefoHoUxXdRbo17xVqzeDw+J1x1RnFNTDakpmFdoUtY3T x65sJMo+HgoNhYNA08TB/gpqIEjEuGcQsTVNbH+pE299u18ULChK7JgKGe3hjjT2yHRk y6QQ==
X-Gm-Message-State: AODbwcCrAeWjuktgcL10xQ3LOXI4aG5YYSroGC7RQQZkLK3kn5pu6tAy LCtaHPAOD9PG+Q9mfW5s1bw8SocFnCu1
X-Received: by 10.55.197.92 with SMTP id p89mr3182806qki.34.1495033220032; Wed, 17 May 2017 08:00:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.97.10 with HTTP; Wed, 17 May 2017 08:00:19 -0700 (PDT)
In-Reply-To: <79a48d82-014a-f1dc-6fef-a2c9a492281d@gmail.com>
References: <CALx6S34A5k_DtEb7YWQs=Y79p4rCpe-9Hg3_YiqbOSyWzqepYA@mail.gmail.com> <79a48d82-014a-f1dc-6fef-a2c9a492281d@gmail.com>
From: Tom Herbert <tom@herbertland.com>
Date: Wed, 17 May 2017 08:00:19 -0700
Message-ID: <CALx6S35ro_BhAFw2F9g+4tUtFw7herSgn9ikfyGsG+iNJ-YNZg@mail.gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: "int-area@ietf.org" <int-area@ietf.org>, Petr Lapukhov <petr@fb.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/3lr4PFcLXXg0ypUpgEnMnLYzArw>
Subject: Re: [Int-area] ILA and int-area
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 May 2017 15:07:18 -0000

On Tue, May 16, 2017 at 10:29 PM, Brian E Carpenter
<brian.e.carpenter@gmail.com> wrote:
> On 14/05/2017 05:42, Tom Herbert wrote:
>> Hello,
>>
>> At the Chicago WG meeting I made a request that ILA be taken up as a
>> WG item in int-area. The WG chairs and AD requested that we raise a
>> discussion on the list about what else is needed to be done for ILA
>> (Identifier Locator Addressing draft-herbert-nvo3-ila-04). The
>> question was also raised if int-area is the right WG for ILA or if it
>> should have a BOF.
>
> I think it's fine for int-area to take this up, as long as 6man
> is alerted.
>
> A few somewhat random comments:
>
> Is there any particular reason you chose a /64 routing prefix,
> rather than say /72 or /80? I don't see any dependency on SLAAC,
> so there's no reason to care about /64, right? I assume you would
> use DHCPv6 or some other method of assigning addresses to VMs.
>
The 64 bit was for convenience since that is what ILNP had and in the
DC we wanted enough identifier bits to be able to do identifier
assignment based on a timestamp as described in appendix B. There's no
hard requirement for it. I think we could just say an ILA domain can
define lengths of identifier and locators as they see fit-- as long as
its consistent and unambiguous within the domain there shouldn't be an
issue.

> If you used /72 or /80 you'd have flexibility with a ULA prefix to
> insert a subnet field.
>
>> The format of an ILA address with a global unicast locator is:
>>
>>    |<--------------- Locator --------------->|
>>    |3 bits| N bits        | M bits  | 61-N-M | 64 bits              |
>>    +------+-------------+---------+---------------------------------+
>>    | 001  | Global prefix | Subnet  | Host   |      Identifier      |
>>    +------+---------------+---------+--------+----------------------+
>
> Why is this restricted to 2000::/3?

Probably shouldn't be. If locator length isn't fixed like above, then
probably should just describe it by properties of being routable to
physical hosts.

>
>> The format of an ILA address with a unique local IPv6 unicast locator
>> is:
>>
>>    |<--------------- Locator --------->|
>>    | 7 bits |1|  40 bits   |  16 bits  |          64 bits           |
>>    +--------+-+------------+-----------+----------------------------+
>>    | FC00   |L| Global ID  | Host      |        Identifier          |
>>    +--------+-+------------+-----------+----------------------------+
>
> The first byte is confusing; presumably you're trying to express
> fd00::/8 so why not put 11111101 ?
>
> I agree that the flow label would be tricky to use for this sort of
> purpose, but I have a couple of comments anyway:
>
>>   o The flow label is only twenty bits, this is too small to be a
>>     discriminator in forwarding a virtual packet to a specific
>>     destination. Conceptually, the flow label might be used in a
>>     type of label switching to solve that.
>
> Perhaps, but 6man fairly comprehensively rejected that type of usage.
> In practice it's excluded by section 4 of RFC6437.
>
>       o The flow label is not considered immutable in transit,
>         intermediate devices may change it.
>
> That's not phrased quite right. RFC6437 section 2 says:
>
> "  Once set to a non-zero value, the Flow Label is expected to be
>    delivered unchanged to the destination node(s).  A forwarding node
>    MUST either leave a non-zero flow label value unchanged or change it
>    only for compelling operational security reasons as described in
>    Section 6.1.
>
>    There is no way to verify whether a flow label has been modified en
>    route..."
>
> You could in fact have an operational guarantee that within an
> administrative domain, no middleboxes will change the flow label.
> So something like this is more accurate:
>
>      o  The flow label is not protected against changes in transit.
>
Yes, the flow label concept came up in some early dicussions.

>>    o Intermediate devices must not insert extension headers
>>      [RFC2460bis].
>
> I think you could say:
>
>       o Current specifications do not allow intermediate devices to
>         insert extension headers [RFC2460bis].
>
Good point.

> Regards
>    Brian