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

From: Tom Herbert <[email-masked]>
Date: Fri, 1 Nov 2019 10:32:28 -0700

Hello,

>From the draft: "Regarding Hop-By-Hop Options Header, if we consider
its real deployment, it is sometimes dropped by legacy devices and not
so used by intermediate nodes.  Destination Options Header is
preferred."

I don't think this is helpful guidance. First of all, it's not just
Hop-by-Hop options that can be dropped, it's pretty much packets with
any extension heades or atypical protocols that might be dropped by
legacy devices-- including packets with Destination Options or Routing
Headers. Neither does it make sense that Destination Options Header is
preferred, as correctly stated in the previous paragraph DO and HBH
address difference use cases (i.e. DO is end to end, and HBH is per
hop). Saying that DO is preferred is equivalent to saying that
end-to-end performance measurements are preferred which I doubt is the
intent. IMO, this whole paragraph could be removed without loss of
content.

"SRH TLV can also be a good choice from this point of view.  The
intermediated nodes that are not in the SID list can consider the SRH
as a green field, they cannot support and bypass or support and dig
into the SRH TLV."

I disagree with the conclusion that SRH TLV is a good choice. The
implicit assumption in this paragraph is that somehow SRH EH is less
likely to be dropped by intermediate nodes than other EH like DO and
HBH. I don't think there's any data to support that. Additionally,
it's not clear what use case an SRH TLV addresses that can't already
be addressed by Destination or HBH options.

Tom

---

From: Ole Troan <[email-masked]>
Date: Fri, 1 Nov 2019 18:46:36 +0100

DestOpt => measurement only  by node in DA
HBH => every router on the path with feature enabled
SRH TLV => every node along the SR path
DestOpt + SRH => every node along the SR path

Cheers 
Ole

> On 1 Nov 2019, at 18:33, Tom Herbert <[email-masked]> wrote:
> 
> Hello,
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Tom Herbert <[email-masked]>
Date: Fri, 1 Nov 2019 10:56:49 -0700

> DestOpt + SRH => every node along the SR path
Ole,

So the last two have identical effects, hence we've introduced the
complexity or redundant protocol mechanisms.

Tom

---

From: Ole Troan <[email-masked]>
Date: Fri, 1 Nov 2019 19:15:47 +0100

> On 1 Nov 2019, at 18:57, Tom Herbert <[email-masked]> wrote:
> 

Yes, that should guide us in making choices here. 

Ole

---

From: Tianran Zhou <[email-masked]>
Date: Tue, 5 Nov 2019 07:37:12 +0000

Hi Tom and Ole,

Thanks for your comments.
Yes, your proposal is a very good guidance for users to choose the mode how to take the alt-mark field.
We will revise to show these considerations.
But I think this is for the idea cases.
We would also like to show some "abnormal" usage for legacy network. :-)
That is to say, using SRH and DO for the hop by hop usage. I see the similar usage in RFC7837.
What's your thoughts?

BR,
Tianran

> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of Ole Troan
> Sent: Saturday, November 02, 2019 2:16 AM
> To: Tom Herbert <[email-masked]>
> Cc: 6man <[email-masked]>
> Subject: Re: Comments on raft-fz-6man-ipv6-alt-mark-01
> 
> 
> 
> >> DestOpt => measurement only  by node in DA HBH => every router on the
> >> path with feature enabled SRH TLV => every node along the SR path
> >>> its real deployment, it is sometimes dropped by legacy devices and
> >>> not so used by intermediate nodes.  Destination Options Header is
> >>> preferred."
> >>>
> >>> Hop-by-Hop options that can be dropped, it's pretty much packets
> >>> with any extension heades or atypical protocols that might be
> >>> dropped by legacy devices-- including packets with Destination
> >>> Options or Routing Headers. Neither does it make sense that
> >>> Destination Options Header is preferred, as correctly stated in the
> >>> previous paragraph DO and HBH address difference use cases (i.e. DO
> >>> is end to end, and HBH is per hop). Saying that DO is preferred is
> >>> equivalent to saying that end-to-end performance measurements are
> >>> preferred which I doubt is the intent. IMO, this whole paragraph
> >>> could be removed without loss of content.
> >>>
> >>> intermediated nodes that are not in the SID list can consider the
> >>> SRH as a green field, they cannot support and bypass or support and
> >>> dig into the SRH TLV."
> >>>
> >>> IETF IPv6 working group mailing list [email-masked] Administrative
> >>> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Ole Troan <[email-masked]>
Date: Tue, 5 Nov 2019 08:51:19 +0100

Hi Tianran,

> That is to say, using SRH and DO for the hop by hop usage. I see the similar usage in RFC7837.

From RFC7837:
   "Hop-by-hop options would have been the best solution for carrying
   ConEx markings if they had met requirement R-3.  There is currently
   some work ongoing in the 6MAN working group to address this very
   issue [HBH-HEADER].  This new behavior would address R-3 and would
   make hop-by-hop options the preferred solution for carrying ConEx
   markings."

The work in 6MAN is done and the definition of HBH is updated in RFC8200.

Best regards,
Ole

---

From: Tianran Zhou <[email-masked]>
Date: Tue, 5 Nov 2019 08:33:03 +0000

Hi Ole,

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?

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. 

Thanks,
Tianran

> From: Ole Troan [mailto:[email-masked]]
> Sent: Tuesday, November 05, 2019 3:51 PM
> To: Tianran Zhou <[email-masked]>
> Cc: Tom Herbert <[email-masked]>; Giuseppe Fioccola
> <[email-masked]>; 6man WG <[email-masked]>
> > We would also like to show some "abnormal" usage for legacy network.
> > :-) That is to say, using SRH and DO for the hop by hop usage. I see the
> similar usage in RFC7837.
> > What's your thoughts?
> 
> From RFC7837:

---

From: Ole Troan <[email-masked]>
Date: Tue, 5 Nov 2019 10:04:17 +0100

Tianran,

> 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...

> 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

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.

---

From: Mark Smith <[email-masked]>
Date: Tue, 5 Nov 2019 20:34:05 +1100

On Tue, 5 Nov 2019, 20:05 Ole Troan, <[email-masked]> wrote:

> > 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
> 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).
>
> Hiding the per-hop options inside of destination options, would have
> pretty bad performance characteristics I would expect.
>

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
>

---

From: Tianran Zhou <[email-masked]>
Date: Tue, 5 Nov 2019 10:05:49 +0000

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:[email-masked]]
Sent: Tuesday, November 05, 2019 5:34 PM
To: Ole Troan <[email-masked]>
Cc: Tianran Zhou <[email-masked]>; 6man WG <[email-masked]>
Subject: Re: Comments on raft-fz-6man-ipv6-alt-mark-01

On Tue, 5 Nov 2019, 20:05 Ole Troan, <[email-masked]<mailto:[email-masked]>> wrote:
Tianran,

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

Best regards,
Ole

[email-masked]<mailto:[email-masked]>

---

From: Giuseppe Fioccola <[email-masked]>
Date: Tue, 5 Nov 2019 10:51:36 +0000

Dear Tom, Ole,
Thank you for your feedback.
Agree, it is better to be general and avoid any definitive conclusion about HBH, DestOpt and SRH TLV.
I will update that paragraph accordingly and will publish a new revision soon.

Regards,

Giuseppe

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Ole Troan
Sent: Friday, November 1, 2019 7:16 PM
To: Tom Herbert <[email-masked]>
Cc: 6man <[email-masked]>
Subject: Re: Comments on raft-fz-6man-ipv6-alt-mark-01

Ole