Subject: A draft on the encapsulation of end-to-end IETF network slice information in IPv6 data plane

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Fri, 21 May 2021 02:42:05 +0000

Hi WG,

Recently we published a draft on the encapsulation of end-to-end IETF network slice information in IPv6 data plane:

https://datatracker.ietf.org/doc/html/draft-li-6man-e2e-ietf-network-slicing

This document defines the mechanism of encapsulating the end-to-end network slice related identifiers in IPv6 packet, which is aligned with the framework as defined in draft-li-teas-e2e-ietf-network-slicing.

Your review and comments are welcome.

Best regards,
Jie

From: Teas [mailto:[email-masked]] On Behalf Of Dongjie (Jimmy)
Sent: Thursday, May 13, 2021 10:54 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [Teas] A draft on the framework for end-to-end IETF network slicing

Hi WG,

Recently we published a draft on the framework for end-to-end IETF network slicing: https://datatracker.ietf.org/doc/html/draft-li-teas-e2e-ietf-network-slicing

This document describes the scenarios of end-to-end network slicing, and the framework of network slice mapping between different network segments and network domains. Multiple network slice related identifiers are defined to covers different network scopes.

The network slice related identifiers of different network scopes can be instantiated with MPLS or IPv6 data plane, which are further described in the following drafts:

https://datatracker.ietf.org/doc/draft-li-mpls-e2e-ietf-network-slicing/

https://datatracker.ietf.org/doc/html/draft-li-6man-e2e-ietf-network-slicing

https://datatracker.ietf.org/doc/html/draft-li-spring-sr-e2e-ietf-network-slicing

Your review and comments are welcome. (Comments on the specific data plane draft can go to the corresponding WG mail list).

Best regards,
Jie

---

From: [email-masked]
Date: Fri, 21 May 2021 10:57:55 +0200

Hi Jie,

> This document defines the mechanism of encapsulating the end-to-end network slice related identifiers in IPv6 packet, which is aligned with the framework as defined in draft-li-teas-e2e-ietf-networ…

What are the benefits of using an IPv6 extension header to carry the meta data?
In contrast to embedding it in a tunnel header (like what GRE, Geneve, etc, etc does).

Best regards,
Ole

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Mon, 24 May 2021 11:25:39 +0000

Hi Ole, 

Thanks for your comment. 

It is expected that the identifiers defined in this draft will be parsed or processed by some network nodes along the path, rather than only the endpoints, thus maybe it is more convenient to carry them in the IPv6 header. This could also reduce the overhead of introducing other tunnel layers to the IPv6 network. 

Best regards,
Jie

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, May 21, 2021 4:58 PM
> To: Dongjie (Jimmy) <[email-masked]>
> Cc: [email-masked]
> Subject: Re: A draft on the encapsulation of end-to-end IETF network slice
> information in IPv6 data plane
> 
> Hi Jie,
> 
> > Recently we published a draft on the encapsulation of end-to-end IETF
> network slice information in IPv6 data plane:
> >
> >
> > This document defines the mechanism of encapsulating the end-to-end
> network slice related identifiers in IPv6 packet, which is aligned with the
> framework as defined in draft-li-teas-e2e-ietf-network-slicing.
>

---

From: Tom Herbert <[email-masked]>
Date: Mon, 24 May 2021 08:33:38 -0700

On Mon, May 24, 2021, 4:26 AM Dongjie (Jimmy) <[email-masked]> wrote:

> Hi Ole,
>
> Thanks for your comment.
>
> It is expected that the identifiers defined in this draft will be parsed
> or processed by some network nodes along the path, rather than only the
> endpoints, thus maybe it is more convenient to carry them in the IPv6
> header. This could also reduce the overhead of introducing other tunnel
> layers to the IPv6 network.

A HBH option to provide acillary information for IPIP encapsulation makes a
lot of sense to me, however this proposed format wouldn't be extensible to
carry other type of information that might be of interest beyond a four
byte ID.

A way to make the format extensible could simply be to add a sixteen bit
flags that can indicate flag-fields like in GRE or GUE. This allow other
optional fields in option. Since HBH EH needs to be eight bytes anyway,
there's no additional overhead if this is only HBH option. Also, this is a
way to pack data into one option as opposed to using separate options (so
less overhead and limiting number of options in HBH EH is a good thing).

Tom

> > In contrast to embedding it in a tunnel header (like what GRE, Geneve,
> etc,
> > etc does).
> >
> > Best regards,
> > Ole
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 24 May 2021 17:52:29 +0200

On 2021-05-24, at 17:33, Tom Herbert <[email-masked]> wrote:
> 
> Also, this is a way to pack data into one option as opposed to using separate options (so less overhead and limiting number of options in HBH EH is a good thing).

I’m not sure the HBH concept can be saved, but the packing you suggest means that a recipient has to understand all the bits in order to be able to process all the packed fields in the HBH option.
That makes it hard to incrementally start using another bit with elective semantics (you wouldn’t care if understanding the bit is critical anyway).

Grüße, Carsten

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 26 May 2021 15:20:24 +0000

Hi Tom,

Thanks for your comment. Please see inline:

From: Tom Herbert [mailto:[email-masked]]
Sent: Monday, May 24, 2021 11:34 PM
To: Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>
Cc: Ole Troan <[email-masked]<mailto:[email-masked]>>; 6MAN <[email-masked]<mailto:[email-masked]>>
Subject: Re: A draft on the encapsulation of end-to-end IETF network slice information in IPv6 data plane

On Mon, May 24, 2021, 4:26 AM Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Ole,

Thanks for your comment.

A HBH option to provide acillary information for IPIP encapsulation makes a lot of sense to me, however this proposed format wouldn't be extensible to carry other type of information that might be of interest beyond a four byte ID.

[Jie] For different types of information to be carried in HBH, one approach is to define them as different HBH options.

A way to make the format extensible could simply be to add a sixteen bit flags that can indicate flag-fields like in GRE or GUE. This allow other optional fields in option. Since HBH EH needs to be eight bytes anyway, there's no additional overhead if this is only HBH option. Also, this is a way to pack data into one option as opposed to using separate options (so less overhead and limiting number of options in HBH EH is a good thing).

[Jie] The approach you suggested is to introduce optional fields in one HBH option, and use flags to indicate their existence. This could reduce the number of options and may have a better packing efficiency, while how to introduce new fields based on this approach may need some further consideration. With separate options, the processing behavior and the length of each option can be determined from the option type and option length fields. Can similar function be provided with the one packed option approach?

Best regards,
Jie

Tom

Best regards,
Jie

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
> To: Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>
> Cc: [email-masked]<mailto:[email-masked]>

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 26 May 2021 15:25:29 +0000

Hi Carsten, 

I share the similar opinion with you on the packed HBH option approach. Some mechanism to determine how to process or skip an unknown field in the option needs to be considered. 

Best regards,
Jie

> From: Carsten Bormann [mailto:[email-masked]]
> Sent: Monday, May 24, 2021 11:52 PM
> To: Tom Herbert <[email-masked]>
> Cc: Dongjie (Jimmy) <[email-masked]>; 6MAN <[email-masked]>
> > Also, this is a way to pack data into one option as opposed to using separate
> options (so less overhead and limiting number of options in HBH EH is a good
> thing).
> 
> I’m not sure the HBH concept can be saved, but the packing you suggest
> means that a recipient has to understand all the bits in order to be able to
> process all the packed fields in the HBH option.
> That makes it hard to incrementally start using another bit with elective
> semantics (you wouldn’t care if understanding the bit is critical anyway).
> 
> Grüße, Carsten

---

From: Tom Herbert <[email-masked]>
Date: Wed, 26 May 2021 09:12:47 -0700

On Wed, May 26, 2021 at 8:20 AM Dongjie (Jimmy) <[email-masked]> wrote:
> Cc: Ole Troan <[email-masked]>; 6MAN <[email-masked]>

Hi Jie,

Yes, in flag-fields if a given flag is set then that indicates the
presence of a field of specific length. The optional data is well
ordered and the length of each possible option is fixed (multi-bit
flags can be used to allow a few different lengths for select
options). The big advantage of flag-fields over a traditional TLV list
is that flag-fields have a strict order of fixed length fields whereas
TLVs have combinatorial ordering and variable length fields-- so
flag-fields are more amenable to hardware. For instance the 16 bit
flags could be run through a TCAM to parse all the present options in
O(1) time; TLVs require serial processing to parse so are at least
O(n) parsing and also have overhead of type and length fields.

If the supposition of draft-hinden-6man-hbh-processing-00 is correct
in that restricting the HBH options to one option will promote support
of HBH options in hardware implementation, then using flag-fields in
that one option to encode different options in a hardware friendly
manner would be consistent with the goals. In the case of HBH options,
most that are defined are going to be ignored if unrecognized, so we
could carry that to sub-options. Since flag-fields are well ordered,
new options are added as contiguous flags to existing options. An
implementation would support N flags (e.g. the first N defined
options) and any flags beyond the first N would be ignored.

Tom