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

[Brian E Carpenter <[e-mail]>]

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.

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

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

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

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.

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

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

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

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