RE: Lars Eggert's Discuss on draft-ietf-6man-ipv6-alt-mark-08: (with DISCUSS and COMMENT)

Hi Lars,
I just submitted the new version. Please check whether the revised section 5.3 clarifies and addresses your concerns.

Regards,

Giuseppe

-----Original Message-----
From: ipv6 <ipv6-bounces@ietf.org> On Behalf Of Giuseppe Fioccola
Sent: Friday, October 22, 2021 9:55 AM
To: Lars Eggert <lars@eggert.org>
Cc: ipv6@ietf.org; draft-ietf-6man-ipv6-alt-mark@ietf.org; Bob Hinden <bob.hinden@gmail.com>; The IESG <iesg@ietf.org>; 6man-chairs@ietf.org
Subject: RE: Lars Eggert's Discuss on draft-ietf-6man-ipv6-alt-mark-08: (with DISCUSS and COMMENT)

Hi Lars,
My replies inline as [GF].
I will submit a new version soon to address your comments.

Regards,

Giuseppe

-----Original Message-----
From: Lars Eggert <lars@eggert.org> 
Sent: Friday, October 22, 2021 9:26 AM
To: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>
Cc: Bob Hinden <bob.hinden@gmail.com>; draft-ietf-6man-ipv6-alt-mark@ietf.org; ipv6@ietf.org; The IESG <iesg@ietf.org>; 6man-chairs@ietf.org
Subject: Re: Lars Eggert's Discuss on draft-ietf-6man-ipv6-alt-mark-08: (with DISCUSS and COMMENT)

Hi,

On 2021-10-21, at 16:49, Giuseppe Fioccola <giuseppe.fioccola@huawei.com> wrote:
> Please note that we just published a new revision of the draft. In section 5.3 we have clarified the recommended deployment mode based on matching FlowMonID with source and destination addresses.

I'm looking at the diff at https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-ipv6-alt-mark-11.

There is now this paragraph in Section 5.3:

>    The value of 20 bits has been selected for the FlowMonID since it is
>    a good compromise and implies a low rate of ambiguous FlowMonIDs that
>    can be considered acceptable in most of the applications.  Indeed,
>    with 20 bits the number of combinations is 1048576.

You only get ~1M concurrent flows with centralized assignment of the FLowMonIDs. With uncoordinated local randomized assignment, you'll get much less, esp. since you'll want to require very low collision probabilities (do the math). The tradeoffs here are important to explain in detail, so that deployers realize they need to either look into using a controller and/or combining the FlowMonID with additional header fields.

[GF]: I agree. I will clarify that for local random assignment the collision probability is different (50% chance of collision for 1206 flows). For this reason, the draft can also recommend the centralized solution.

>    The requirement
>    of the controlled domain also reduces the probability of FlowMonID
>    collisions, since the AltMark Option is not spread over the internet.

I don't understand how this is true. The collision probability only depends on flow creation rates?

[GF]: To avoid misunderstanding I can omit this sentence.

>    A consistent approach MUST be used in the implementation to avoid the
>    mixture of different ways of identifying.

I think you mean "A consistent approach MUST be used ***in deployment***"?

[GF]: Yes, I will revise.

>    By considering source and destination
>    addresses together with the the FlowMonID it can be possible to
>    monitor 1048576 concurrent flows per host pairs.  This allows finer
>    granularity and therefore adds even more flexibility to the flow
>    identification.

Again, this ~1M concurrent flows per host pair only holds for centralized assignment via a controller, not for randomized assignment.

[GF]: yes, as above.

Thanks,
Lars

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