RE: Comments on raft-fz-6man-ipv6-alt-mark-01

Hi Mark and Ole,

Thanks both of your suggestions.
You are right. Using DO for hop by hop action would cause the performance degradation.
But my question is, do we have anyway for the compatibility?
That’s why we want to discuss the way as in RFC7837, maybe as a deployment consideration.

BR,
Tianran

From: Mark Smith [mailto:markzzzsmith@gmail.com]
Sent: Tuesday, November 05, 2019 5:34 PM
To: Ole Troan <otroan@employees.org>
Cc: Tianran Zhou <zhoutianran@huawei.com>; 6man WG <ipv6@ietf.org>
Subject: Re: Comments on raft-fz-6man-ipv6-alt-mark-01

On Tue, 5 Nov 2019, 20:05 Ole Troan, <otroan@employees.org<mailto:otroan@employees.org>> wrote:
Tianran,

> Yes, I know 8200 considered and changed the way to process the HBH.
> Do you mean the following words?
> NOTE: While [RFC2460] required that all nodes must examine and
> process the Hop-by-Hop Options header, it is now expected that nodes
> along a packet's delivery path only examine and process the
> Hop-by-Hop Options header if explicitly configured to do so.
>
> From this I am always confused. We can decide/configure whether to process the HBH. But we cannot decide whether it's processed in fast path or slow path. I think this is one issue raised by the reference
> https://tools.ietf.org/html/draft-ietf-6man-hbh-header-handling-03
> Do I miss some other words in 8200?

Right, HBH processing by a router now has to be explicitly configured.
E.g. if a router didn't support alt mark, it would be no purpose in even parsing the HBH header (unless other options also was configured and supported).

You can of course not control how efficient that implementation implements your option...

> In addition, we did test many asics and devices. They will direct packet to the slow path.
> In addition, in real deployment, there are legacy devices that follow RFC2460.
>
> So our idea is to show alternative options for potential environment.

Sure, and this was discussed a lot in the context of the other RFC.

Hiding the per-hop options inside of destination options, would have pretty bad performance characteristics I would expect.

For HBH a router needs to:
if ipv6->nh == 0
   walk HBH TLVs and process them

For DestOpt a router would need to:
walk EH chain looking for DestOpt:
  walk DestOpt TLVs and make a guess which one is for in-flight versus destination

Yes, the *Destination* Options are for the device holding the packet's *Destination* Address.

Using HBH you use a mechanism engineered for it, using DestOpt you are in middlebox territory. And you will be much more likely to end up conflicting with host functions.

Best regards,
Ole

PS: If you would do a EH performance testing project at the Singapore hackathon I would be all supportive.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org<mailto:ipv6@ietf.org>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------