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

On Wed, May 26, 2021 at 8:20 AM Dongjie (Jimmy) <jie.dong@huawei.com> wrote:
>
> 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>
> Cc: Ole Troan <otroan@employees.org>; 6MAN <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> 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?

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

>
>
>
> Best regards,
>
> Jie
>
>
>
> Tom
>
>
>
>
>
> Best regards,
> Jie
>
> > -----Original Message-----
> > From: otroan@employees.org [mailto:otroan@employees.org]
> > Sent: Friday, May 21, 2021 4:58 PM
> > To: Dongjie (Jimmy) <jie.dong@huawei.com>
> > Cc: 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
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------