RE: Working Group Last Call for <draft-ietf-6man-ipv6-alt-mark>

[Giuseppe Fioccola <[e-mail]>]

Hi Brian,
Thanks a lot for your detailed revision.
Please find my replies inline with [GF].

Regards,

Giuseppe 

-----Original Message-----
From: ipv6 [mailto:[e-mail]] On Behalf Of Brian E Carpenter
Sent: Monday, December 21, 2020 11:29 PM
To: 6man <[e-mail]>
Cc: Bob Hinden <[e-mail]>
Subject: Re: Working Group Last Call for <draft-ietf-6man-ipv6-alt-mark>

Issues:
-------

> 2.  Alternate Marking application to IPv6
...
>       Anyway this does not impact the
>       traffic since the measurement can be done only for the nodes
>       configured to read the Option.

I'm not sure what this means. Does it mean this?:

     This does not affect throughput on nodes that do not recognize
     the option.

But is that true, because of the issues with HbH processing that motivated draft-hinden-6man-hbh-processing? Isn't it possible that this option will force packets onto the "slow path" even in nodes that do not recognize it? The later discussion in section 4 "Use of the AltMark Option" does not mention this.

[GF]: Yes, it is possible. The three high-order bits of the Options Header defined in this draft are 000 and, in theory, as per RFC8200 and draft-hinden-6man-hbh-processing, this means "skip if do not recognize and data do not change en route". RFC8200 also mentions that the nodes only examine and process the HbH Options header if explicitly configured to do so. For these reasons, this HbH Option should not affect the throughput. Anyway, in practice, we are fully aware that the things may be different and it can happen that packets with HbH are forced onto the slow path, and this is a general issue. In the next revision we can include something more on that, even in section 4.

>    An important point that will also be discussed in this document is
>    the the uniqueness of the FlowMonID and how to allow disambiguation
>    of the FlowMonID in case of collision.  [RFC6437] states that the
>    Flow Label cannot be considered alone to avoid ambiguity since it
>    could be accidentally or intentionally changed en route for
>    compelling operational security reasons and this could also happen to
>    the IP addresses that can change due to NAT.  But the Alternate
>    Marking is usually applied in a controlled domain, which would not
>    have NAT and there is no security issue that would necessitate
>    rewriting Flow Labels.  So, for the purposes of this document, both
>    IP addresses and Flow Label should not change in flight and, in some
>    cases, they could be considered together with the FlowMonID for
>    disambiguation.

I think this is a very important point that should probably have its own sub-section 2.1 "Controlled Domain". It answers the question of whether this new option is deployable: yes, in a controlled domain.
(That's why this draft is referenced in RFC8799.)

[GF]: Agree, we can define a new subsection here to highlight the concept. I would also add the reference to RFC8799.

> 4.  Use of the AltMark Option
...
>    In summary, it is possible to list the alternative possibilities:
> 
>    o  Destination Option => measurement only by node in Destination
>       Address.
> 
>    o  Hop-by-Hop Option => every router on the path with feature
>       enabled.
> 
>    o  Destination Option + any Routing Header => every destination node
>       in the route list.

While looking at the 3rd bullet here, I noticed an inconsistency in RFC8200. Section 4.4. of RFC8200 says:

>>>    The Routing header is used by an IPv6 source to list one or more
>>>    intermediate nodes to be "visited" on the way to a packet's
>>>    destination.

So "destination" clearly means the final destination, not the intermediate nodes in the source route. But section 4.1 of RFC8200 ("Extension Header Order") says:

>>>    note 1: for options to be processed by the first destination that
>>>            appears in the IPv6 Destination Address field plus
>>>            subsequent destinations listed in the Routing header.

To avoid ambiguity, I think the first and third bullets in the above list should be modified:

   o  Destination Option not preceding a Routing Header => measurement
      only by node in Destination Address.

   o  Hop-by-Hop Option => every router on the path with feature
      enabled.

   o  Destination Option preceding a Routing Header => every destination
      node in the route list.

[GF]: Good suggestion. The wording you propose is more complete and avoids ambiguity. I will replace the bullets in the next revision of the draft.

> 5.3.1.  Uniqueness of FlowMonID

This section would be more helpful if it discussed the importance of a low rate of ambiguous IDs on the usefulness of the measurements.
Does it really matter if the measurements for 2 flows are confounded 0.1% of the time? Would this cause significant harm to the operator or their clients? Is this harm important enough to justify the complications of avoiding it?

(For ECMP/LAG, RFC6438 page 6 states that rare collisions for the flow label are acceptable, but your case may be different.)

[GF]: Yes, in this section we can introduce that the uniqueness of FlowMonID may not be a problem in some cases. But, for large scale measurements where it is possible to monitor a big number of flows, the disambiguation of the Flow Monitoring Identification field is something to take into account.

Nits:
-----

>    In consequence to the previous document and to the discussion within
>    the community, it is possible to state that the only correct and
>    robust choice that can actually be standardized would be the use of a
>    new TLV to be encoded in the Options Header (Hop-by-Hop or
>    Destination Option).

That sentence is best described as "baroque". I suggest something much simpler, such as:

Consquently, a robust choice is to standardize a new Hop-by-Hop or Destination Option.

[GF]: Ok, I will replace the sentence.

>    Note that the FlowMonID is different from the Flow Label field of the
>    IPv6 Header ([RFC8200]).  Flow Label is used for application service,
>    like load-balancing/equal cost multi-path (LB/ECMP) and QoS.

"Application service" really doesn't describe ECMP or LAG which are traffic engineering mechanisms, and I'm not aware of any real application of the flow label that could be described as QoS management. 

[GF]: I see, Iet me reword this sentence and leave only LB and ECMP.

>  Flow Label cannot be considered alone to avoid ambiguity since it  
> could be accidentally or intentionally changed en route...

The other reason is that since the flow label is pseudo-random, there is always a finite probability of collision. (Although as noted above, for load balancing, statistically rare ambiguity is OK.)

[GF]: Good point. I will also add this argument in the next version.

> 4.  Use of the AltMark Option...
>    ... In this way an unrecognized Hop-by-
>    Hop Option may be just ignored without impacting the traffic.

This duplicates the earlier text about "traffic". Delete?

[GF]: Yes

There are many minor syntax errors; here are a couple of examples chosen at random:

> The Alternate Marking Method has become mature to be implemented...

> [I-D.fioccola-v6ops-ipv6-alt-mark] reported a summary on the possible...

So there is quite a bit of work for the RFC Editor.

Regards
   Brian Carpenter

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------