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

[Lars Eggert <[e-mail]>]

Hi,

On 2021-10-21, at 16:49, Giuseppe Fioccola <[e-mail]> 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.

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

>    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***"?

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

Thanks,
Lars