RE: WG Last Call for draft-ietf-ippm-ioam-ipv6-options

[Haoyu Song <[e-mail]>]

Hi Mark,

Please see inline [HS].

Thanks,
Haoyu
-----Original Message-----
From: Mark Smith <[e-mail]> 
Sent: Wednesday, December 29, 2021 5:26 PM
To: Haoyu Song <[e-mail]>
Cc: Marcus Ihlar <marcus.ihlar=[e-mail]>; [e-mail]; 6man <[e-mail]>
Subject: Re: WG Last Call for draft-ietf-ippm-ioam-ipv6-options

On Thu, 30 Dec 2021 at 08:30, Haoyu Song <[e-mail]> 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".

[HS]  I'm still confused. The draft says "The source address of the outer IPv6 header is that of the IOAM encapsulating node.  The destination address of the outer IPv6 header is the same as the inner IPv6 destination  address". So to me it's not a link-layer encapsulation. It's a new packet different from the original one. If a router forwards packets only based on DA, that's fine. Otherwise, the forwarding behavior can be different. Do I miss something here?


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 <[e-mail]> On Behalf Of Marcus Ihlar
> Sent: Friday, December 17, 2021 7:39 AM
> To: [e-mail]
> 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> tracker.ietf.org%2Fdoc%2Fdraft-ietf-ippm-ioam-ipv6-options%2F&amp;data
> =04%7C01%7Chaoyu.song%40futurewei.com%7C095ac60a5eea46c2251608d9cb3376
> 85%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637764244169572611%7CU
> nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha
> WwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=dEMKFMleDA31SVX9TxkCsGG6R9vmz%2FEPj
> RrHAzvwecY%3D&amp;reserved=0
>
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> tracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-ippm-ioam-ipv6-options-06&a
> mp;data=04%7C01%7Chaoyu.song%40futurewei.com%7C095ac60a5eea46c2251608d
> 9cb337685%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637764244169572
> 611%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTi
> I6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=wITIFHgBev%2BnPyfs73jKKjRaFG
> 5alDMtv1gsqtantxM%3D&amp;reserved=0
>
>
>
> 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
> [e-mail]
> Administrative Requests: 
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Fipv6&amp;data=04%7C01%7Chaoyu.song%40f
> uturewei.com%7C095ac60a5eea46c2251608d9cb337685%7C0fee8ff2a3b240189c75
> 3a1d5591fedc%7C1%7C1%7C637764244169572611%7CUnknown%7CTWFpbGZsb3d8eyJW
> IjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&
> amp;sdata=r1766WzhOMQ7SE4q%2F6EtJkJexJ18xKLx4pCXsFoY8%2F8%3D&amp;reser
> ved=0
> --------------------------------------------------------------------