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

Hi Tom,

Thanks for your comment. Please see inline:

From: Tom Herbert [mailto:tom@herbertland.com]
Sent: Monday, May 24, 2021 11:34 PM
To: Dongjie (Jimmy) <jie.dong@huawei.com<mailto:jie.dong@huawei.com>>
Cc: Ole Troan <otroan@employees.org<mailto:otroan@employees.org>>; 6MAN <6man@ietf.org<mailto:6man@ietf.org>>
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) <jie.dong@huawei.com<mailto:jie.dong@huawei.com>> 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.

[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

> -----Original Message-----
> From: otroan@employees.org<mailto:otroan@employees.org> [mailto:otroan@employees.org<mailto:otroan@employees.org>]
> Sent: Friday, May 21, 2021 4:58 PM
> To: Dongjie (Jimmy) <jie.dong@huawei.com<mailto:jie.dong@huawei.com>>
> Cc: 6man@ietf.org<mailto:6man@ietf.org>
> 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:
> >
> >
> 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.
>
> 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

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