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

On Tue, May 19, 2020 at 8:48 AM Giuseppe Fioccola
<giuseppe.fioccola@huawei.com> wrote:
>
> 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)"

Hi Giuseppe,

Unless AH is present (the common case) the whole IP header and
extension headers, including any HBH and Destination Options, are also
unprotected and best effort delivery. We even have to consider that IP
addresses can change (for instance NAT can change addresses in the
middle of UDP flow lifetime).

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

I don't see any scalability for a 20 bit identifier that is supposed
to be unique throughout the network. As I mentioned this can simply be
combined with the source and destination IP addresses to form a
3-tuple. The 3-tuple can then be hashed to produce a single most
unique flow identifier that is suitable lookups. In this manner the 20
bit field is sufficient and nodes can autonomously set it without any
synchronization. This is how we commonly deal with the flow label
today and other cases of flow classification using a flow hash.

Even if the FlowMonID remains, the likely thing a host implementation
would do is just to set the FlowMonID identically to the flow label.
Do you see any reason why this won't work?

Tom

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