Re: [lisp] RFC6830bis and multiprotocol support

Dino Farinacci <farinacci@gmail.com> Thu, 14 December 2017 18:00 UTC

Return-Path: <farinacci@gmail.com>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59944126DFF for <lisp@ietfa.amsl.com>; Thu, 14 Dec 2017 10:00:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 EX0mxbHnHXc8 for <lisp@ietfa.amsl.com>; Thu, 14 Dec 2017 10:00:36 -0800 (PST)
Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::22d]) (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 D3448124BAC for <lisp@ietf.org>; Thu, 14 Dec 2017 10:00:36 -0800 (PST)
Received: by mail-pg0-x22d.google.com with SMTP id e14so3897912pgr.9 for <lisp@ietf.org>; Thu, 14 Dec 2017 10:00:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LuHfFqTDKzUyphdLbWX7znnyUI8BuIypuS3HoX0+gZU=; b=fMlsPuZHwRvq82UCyV8aBXe5taJObrUDbqBHz/KsNJSihCi5BLYnuagUg7sM+rp3hz CkDFGUVte8CMe6664FuIN0Frw71P5tzklk/1/nt0oZsF35eOI6zR3Ai9f3wRmkHn36/T Hbd7UWW1oHbODpO0K+dxJyH1sXFfQQ8Th5sa+gjUrkPpDE/qbUbeeQoPSIgymo0Q82/b 28800sQQjjUaNiDus+fWp5l5pQo7Mc/H/MVMDGsG7797k9cp8kFTYYD3ZUFTcb3Nv4fB 3CUr7fSu3T1vRH/gPIQ9qeQY3opj/uRedUFDWzBa8XB3IddhNlHnwEdbw8PKfYKdxiDl p7zQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LuHfFqTDKzUyphdLbWX7znnyUI8BuIypuS3HoX0+gZU=; b=X5CJ30fQgYEKVRckt3RLAGgVPdwKsJBC4kw6lh2otqugHh1HesCMnHrfpJ1i4cZhUk 58jPTIsgn0UbOnhrR/eL3+JxwXivTpZpJMm77VPVG8OwGECgdApBOIi2t3vkCXHEMOPc VzEENT8Xo9Oy3GeYAibprdEGvoFzI9c749ojgolxs9+h1eReOJtgar87FYF/qUS8EreR 8dkvKshNUwhnTp0IdOpVWky2sxaNjCvi4JHY7d/7OJoy8m3fdCd2zv+S+FxTk8G9BQVc 6hQ6Ibu3roeugik2MiD0/1cPAJGfCrSkeBZnofAOz8cErttXcZxbupoCf7fBLZwE+6tX W31g==
X-Gm-Message-State: AKGB3mI9+zfXovvo/PjdVif6Bq9aHW1fVHQAFY9IEagESaxlziToqtH5 MkCxMGg9B5vkXkB9beCQb1JSko/Y
X-Google-Smtp-Source: ACJfBotY1wMS0b6SFDFCopXme4uUoBr28h1NG4szdspPJbSXUtnu6M3im5xVYK21hSwP/2fxnVC8qA==
X-Received: by 10.99.95.22 with SMTP id t22mr9085225pgb.195.1513274436116; Thu, 14 Dec 2017 10:00:36 -0800 (PST)
Received: from [10.197.31.157] (173-11-119-245-SFBA.hfc.comcastbusiness.net. [173.11.119.245]) by smtp.gmail.com with ESMTPSA id q22sm9455182pfj.94.2017.12.14.10.00.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Dec 2017 10:00:35 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
From: Dino Farinacci <farinacci@gmail.com>
In-Reply-To: <8cbe53a1-90ce-e373-dbca-649e5590e9b3@cisco.com>
Date: Thu, 14 Dec 2017 10:00:34 -0800
Cc: Luigi Iannone <ggx@gigix.net>, "lisp@ietf.org" <lisp@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <B4530266-3BE4-43A7-905F-9FABAF75186E@gmail.com>
References: <211ad1ba-b5fb-b0d5-7001-0f91e89691b7@cisco.com> <0E7372A3-8FB8-47A3-B8EC-72F998824EF2@gigix.net> <ED7ECEA2-4A11-422B-B4A7-76C2E3455761@gmail.com> <8cbe53a1-90ce-e373-dbca-649e5590e9b3@cisco.com>
To: Fabio Maino <fmaino@cisco.com>
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/9YylomeZLhw2hj1PhTwsfb4uKTc>
Subject: Re: [lisp] RFC6830bis and multiprotocol support
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lisp/>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Dec 2017 18:00:39 -0000

It is different but I’m okay with your suggestion.

Dino

> On Dec 14, 2017, at 9:59 AM, Fabio Maino <fmaino@cisco.com> wrote:
> 
> Since there seem to be consensus, can we ask for WG adoption of LISP-GPE and include it as an informative reference as the other drafts that are in 6830bis?
> 
> Can the chairs open a call for adoption in the mailing list, or do we need to wait the next IETF?
> 
> This might be similar to what Dino proposes below.
> 
> Thanks,
> Fabio
> 
> On 12/14/17 9:01 AM, Dino Farinacci wrote:
>> I would prefer to not merge the two documents. Should we say in RFC6830bis that the R-bit is already allocated but don’t way why and make no reference. If no, I go for option A.
>> 
>> Dino
>> 
>>> On Dec 14, 2017, at 2:58 AM, Luigi Iannone <ggx@gigix.net> wrote:
>>> 
>>> His All,
>>> 
>>> happy to see so much consensus :-)
>>> 
>>> <chair hat on>
>>> 
>>> As a chair I have to point out that if you add text in 6830bis to allocate the last bit and refer to draft-lewis-lisp-gpe you are creating an authoritative dependency on a to a document that as for now is not even WG item.
>>> This will block the publication of 6830bis as RFC (remember the intro document…….).
>>> 
>>> There are two possible solutions:
>>> 
>>> A. 6830bis remains unchanged, leaving the P-bit marked as reserved for future use. draft-lewis-lisp-gpe will than allocate this last bit and detail the operations.
>>> 
>>> B. We merge the two documents.
>>> 
>>> I do not have a preference, up to the WG to decide, but better to avoid document dependencies that will block publication.
>>> 
>>> <chair hat off>
>>> 
>>> Ciao
>>> 
>>> L.
>>> 
>>> 
>>> 
>>>> On 29 Nov 2017, at 23:32, Fabio Maino <fmaino@cisco.com> wrote:
>>>> 
>>>> I would like to suggest a way to address mutiprotocol support in RFC6830bis, that may address what was discussed in Singapore.
>>>> This is based on using the last reserved bit in the LISP header as P bit to indicate support for multiprotocol encapsulation, as specified in the LISP-GPE draft (https://tools.ietf.org/html/draft-lewis-lisp-gpe)
>>>> The header, as specified in section 5.1, would look like:
>>>> 
>>>>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>    L   |N|L|E|V|I|P|K|K|            Nonce/Map-Version/Next-Protocol    |
>>>>    I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>    S / |                 Instance ID/Locator-Status-Bits               |
>>>>    P   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>> 
>>>> 
>>>> and the text in section 5.3 that reserves the 6th bit would be replaced by:
>>>> 
>>>>    P: The P-bit is the Next Protocol bit. When this bit is set to
>>>>       1, the V-bit MUST be set to 0 and the Nonce length, when used, is
>>>>       limited to 16 bits. Refer to [draft-lewis-lisp-gpe] for more details.
>>>>       The P-bit is set to 1 to indicate the presence of the 8 bit Next
>>>>       Protocol field encoded as:
>>>> 
>>>>      x x x 0 x 1 x x
>>>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>     |N|L|E|V|I|P|K|K|           Nonce               | Next-Protocol |
>>>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>     |                 Instance ID/Locator-Status-Bits               |
>>>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>> 
>>>> 
>>>> I will have to refresh the LISP-GPE draft, and reflect the allocations of the KK bits according to RFC8061 and Nonce. One of the K bits was used by LISP-GPE to indicate OAM packets, but that same functionality can be done using the Next-Protocol field.
>>>> 
>>>> The use of the P-bit is not compatible with the Map-Versioning feature, but an equivalent function can be specified (if needed) with a Next-Protocol shim header. I can add text to the LISP-GPE draft to reflect that.
>>>> 
>>>> This would address the multiprotocol working item included in the current charter.
>>>> 
>>>> I can very quickly update the LISP-GPE draft to reflect this, but I wanted to hear what the group thinks first.
>>>> 
>>>> Thanks,
>>>> Fabio
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> lisp mailing list
>>>> lisp@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/lisp
>>> _______________________________________________
>>> lisp mailing list
>>> lisp@ietf.org
>>> https://www.ietf.org/mailman/listinfo/lisp
> 
>