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: <b6987280-e872-8c36-f7e9-b719453e84f2@cisco.com>
Date: Wed, 13 Dec 2017 15:02:07 -0800
Cc: "lisp@ietf.org" <lisp@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <37D8903D-05CC-4954-B377-DF66D8500725@gmail.com>
References: <b6987280-e872-8c36-f7e9-b719453e84f2@cisco.com>
To: Fabio Maino <fmaino@cisco.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/Mf3ub0u0QdxPSaPrPy3AqUSASlw>
Subject: Re: [lisp] multi-protocol support in RFC6830bis [ Was: RFC6830bis
 and multiprotocol support]
Precedence: list

After I go through Alberto=E2=80=99s response for RFC6833bis and one =
comment from Albert regarding RFC6830bis, I=E2=80=99ll document the =
P-bit and reference this spec in RFC6830bis. I plan to send email this =
week with both updates at one time.

This should be the final updates to both specs. I=E2=80=99d like to =
request last call and possibly complete it before year-end. Is that =
possible chairs?

Dino

> On Dec 13, 2017, at 2:57 PM, Fabio Maino <fmaino@cisco.com> wrote:
>=20
> I have refreshed the LISP-GPE draft =
(https://tools.ietf.org/html/draft-lewis-lisp-gpe) to be bit-to-bit =
compatible with the data plane encoding in RFC6830bis, as discussed in =
the thread started on Nov. 29 =
(https://mailarchive.ietf.org/arch/msg/lisp/Dq18xxxQoDUkLX1Z_MCKaHZC1I4/?q=
id=3Da7da0673ad7ed2a161aa5f4334f96f19).=20
> As a summary of the long thread:=20
> - bit 5 is allocated as P-bit to indicate the presence of an 8-bit =
Next Protocol field
>=20
> - the Next Protocol field shares 8 bits with the Nonce/Map-Version =
field
>=20
> - when the P-bit is set, the Nonce/Map-Version features are still =
available with shorter (16-bit vs 24-bit) Nonce/Map-Version fields
>=20
> Thanks,
>=20
> Fabio
>=20
>=20
> -------- Forwarded Message --------
>=20
> Subject:	[lisp] RFC6830bis and multiprotocol support
> Date:	Wed, 29 Nov 2017 14:32:40 -0800
> From:	Fabio Maino <fmaino@cisco.com>
> To:	lisp@ietf.org <lisp@ietf.org>
>=20
> I would like to suggest a way to address mutiprotocol support in =
RFC6830bis, that may address what was discussed in Singapore.=20
> 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).=20=

> The header, as specified in section 5.1, would look like:=20
>=20
>        =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    L   |N|L|E|V|I|P|K|K|            Nonce/Map-Version/Next-Protocol    =
|
>    I \ =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    S / |                 Instance ID/Locator-Status-Bits               =
|
>    P   =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>=20
>=20
> and the text in section 5.3 that reserves the 6th bit would be =
replaced by:=20
>=20
>    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=20
>       limited to 16 bits. Refer to [draft-lewis-lisp-gpe] for more =
details.=20
>       The P-bit is set to 1 to indicate the presence of the 8 bit Next=20=

>       Protocol field encoded as:
>=20
>      x x x 0 x 1 x x
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |N|L|E|V|I|P|K|K|           Nonce               | Next-Protocol |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                 Instance ID/Locator-Status-Bits               |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>=20
>=20
> 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.=20
>=20
> 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.=20
>=20
> This would address the multiprotocol working item included in the =
current charter.=20
>=20
> I can very quickly update the LISP-GPE draft to reflect this, but I =
wanted to hear what the group thinks first.=20
>=20
> Thanks,
> Fabio
>=20
>=20
>=20
>=20
>=20
>=20
>=20