Re: [ippm] WG Last Call for draft-ietf-ippm-ioam-ipv6-options

On Thu, 30 Dec 2021 at 08:30, Haoyu Song <haoyu.song@futurewei.com> wrote:
>
> Hi IPPM and 6MAN,
>
>
>
> After reading the draft, I have one question. My understanding is that the proposed approach basically uses IP-in-IP encapsulation and encapsulates the IOAM option in the outer IPv6 header. While the in-band measurement is intended for the inner IPv6 packet, I’m concerned on how the requirement C1 can be met. For example, I’m not sure how the forwarding and ECMP can behave identically with and without the outer IPv6 header (i.e., for the overlay and underlay networks).
>

I think this is another example of where thinking IP-in-IP is
something special and different makes things confusing. "IP
tunnelling" is no more than a link-layer encapsulation. An "IP tunnel"
is a virtual layer 2 point-to-point link.

Original IPv6 packet forwarding through the IOAM domain would still
use information in the original packet (DA minimum, and whatever else
is considered for ECMP). The addition of the encapsulated updated IOAM
information and the outer IP header to get it to the next hop occurs
after that, as the packet goes down to the link-layer when link-layer
encapsulation occurs. IOAM conceptually occurs at "layer 2.5".

Since the IOAM domain is contiguous IPv6 nodes, meaning they're all
link-layer adjacent, imagine instead using bare Ethernet to carry the
IOAM information to the next IOAM hop, with the IOAM information added
when the original IPv6 packet is passed down for link-layer
encapsulation:

Packet With IOAM:

[Ethernet] - [IOAM] - [original IPv6 packet A]

Packet Without IOAM:

[Ethernet] - [original IPv6 packet A]

Now substitute [Outer IPv6] for [Ethernet] above. Except, don't do
that often, it is far less confusing with "IP tunnels" if you imagine
the link-layer encapsulation format is a typical layer 2 frame
different from the original link-layer payload IPv6 packet.

(I've started to think using native Ethernet as above would be better
when possible for IOAM instead of IPv6-in-IPv6 -
draft-weis-ippm-ioam-eth-04 defines an Ethertype. IPv6-in-IPv6 could
be used when there is no native link-layer type field defined to carry
IOAM e.g. [Bluetooth]-[IPv6]-[IOAM]-[original IPv6 packet A]).

Regards,
Mark.

>
>
> Thanks,
>
> Haoyu
>
>
>
> From: ippm <ippm-bounces@ietf.org> On Behalf Of Marcus Ihlar
> Sent: Friday, December 17, 2021 7:39 AM
> To: ippm@ietf.org
> Subject: [ippm] WG Last Call for draft-ietf-ippm-ioam-ipv6-options
>
>
>
> Hello IPPM,
>
> This email starts a Working Group Last Call on draft-ietf-ippm-ioam-ipv6-options.
>
>
>
> https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-ipv6-options/
>
> https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-ipv6-options-06
>
>
>
> Please provide feedback by replying to this email with your reviews and if you think this document is ready to progress, by Friday, January 14.
>
>
>
> Best Regards,
>
> Marcus & Tommy
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------