RE: Comments on draft-fz-6man-ipv6-alt-mark-09

Hi Tom,
Thanks for your support and for your comments.
I understand your point, but, in this regard, we should consider the following paragraph from RFC6437:

   "There is no way to verify whether a flow label has been modified en
   route or whether it belongs to a uniform distribution.  Therefore, no
   Internet-wide mechanism can depend mathematically on unmodified and
   uniformly distributed flow labels; they have a "best effort" quality.
   Implementers should be aware that the flow label is an unprotected
   field that could have been accidentally or intentionally changed en
   route (see Section 6)"

This does not suggest to rely fully on the Flow Label.
Maybe we can mention in the next revision of the draft the possibility to use the Flow Label for identification, but we should also highlight this point.
In addition, as listed in Section 5.3 of draft-fz-6man-ipv6-alt-mark-09, FlowMonID adds additional advantages in terms of scalability, flexible flow definition granularity, counters handling simplification...

Regards,

Giuseppe

-----Original Message-----
From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Tom Herbert
Sent: Tuesday, May 19, 2020 5:00 PM
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: 6MAN <6man@ietf.org>
Subject: Re: Comments on draft-fz-6man-ipv6-alt-mark-09

On Mon, May 18, 2020 at 7:39 PM Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>
> Tom,
>
> > It's unclear to me how the FlowMonID is set, how it's used, and why 
> > the Flow Label isn't sufficient for this purpose.
>
> That was proposed by the authors and discarded a long time ago, 
> because the usage was incompatible with RFC6437. I can't remember the 
> details without looking up long-expired drafts and old email. But generally:
> you can't encode semantics in conformant flow labels, because they are 
> pseudo-random.
>
Brian,

AFAICT the FlowMonID is just another type of flow identifier in the packet. For the purposes of correlating flows in the network I believe it is redundant to the flow label and would otherwise add a lot of complexity to implement. I think what you might be referring to are earlier proposals to put the loss signal bits in the flow label and not use an EH-- that idea is indeed infeasible at this point. IMO, we should be able to eliminate FlowMonID from the option, but still need the two signaling bits in the option hence the alt marking option would contain one byte of data.

Tom

> Regards
>    Brian

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------