Subject: Éric Vyncke's Discuss on draft-ietf-6man-ipv6-alt-mark-08: (with DISCUSS and COMMENT)

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Thu, 12 Aug 2021 07:02:26 -0700

Éric Vyncke has entered the following ballot position for
draft-ietf-6man-ipv6-alt-mark-08: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6man-ipv6-alt-mark/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thank you for the work put into this document.

As Brian Carpenter kindly reminded me that an Area Director may not put back a
previous argument when the WG consensus was to ignore it, I am updating this
ballot by moving the generic DISCUSS as a COMMENT.

The other two DISCUSS points remains blocking ones but Giuseppe have already
addressed them over email, I am clearing the DISCUSS position as soon as the
revised I-D is posted.

Special thanks to Ole Trøan for his shepherd's write-up, which contains a good
summary of the WG consensus and the SW (?) implementation status. Thanks as
well to Bob Halley for his INT directorate review.

Please find below some blocking DISCUSS points, some non-blocking COMMENT
points (but replies would be appreciated).

I also agree with DISCUSS points by other ADs:
- Lars's one about the size and usefulness of FlowMonID (see my very similar
point) - Roman's one about the inconsistencies about limited domain (from my
point of view, this should not be limited to a single domain)

All in all, I strongly suggest to change the intended status of this document
to 'experimental' as this document builds on experimental RFCs.

I hope that this helps to improve the document,

Regards,

-éric

== DISCUSS ==

-- Section 2 --
  "In the end, [I-D.fioccola-v6ops-ipv6-alt-mark] demonstrated that a
   new Hop-by-Hop or a new Destination Option was the best approach."

The above draft has not been published and is even expired for 2 years now...
so please remove the 'demonstrated' as there is no proof at all ;-)

-- Section 4 --
Please remove "the destination node removes it" as there is no reason to remove
it. Extension headers are usually not presented / used by upper layers anyway.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

--- OLD DISCUSS ----
This discussion already happened in the 6MAN WG but I still have to be
convinced that hop-by-hop is a good idea at all. The fate of packets with HbH
is unknown at best and, IMHO, this is a wrong use of HbH because the
forwarding/processing of packets is NOT influenced at all by the AltMark
option. What is required is a simple 'marking/coloring', which could be at any
place in a packet (including destination option). The only benefit of HbH is
its location just after the IPv6 header.

After all, existing devices can measure and generate IPFIX records in
hardware/fastpath by inspecting at the bare minimum the 5-tuple and many
devices can also parse extension headers in the fast path (of course not
processing HbH in this case). I.e., finding the marking in the Dest Option is
probably much easier and doable in current hardware rather than using HbH as
HbH forces a software processing.

--- END OF OLD DISCUSS ---

-- Section 2.1 --
While I agree with my fellow AD about the inconsistencies of the text around
'limited domain' (and being inconsistent deserves a blocking DISCUSS), I do not
agree with this section as I do not see any harm to extend this marking outside
of a single domain, marked packets with this specification can traverse the
whole Internet without causing any harm and not opening for any attack on the
transit nodes. (See also my point about Hop-by-hop)

E.g., packets from organisation A can traverse networks of organizations B, C,
..., Z to reach another site of organization A and still provide useful
measurements for A without causing harm to B, C, ..., Z. Of course the
survivability of those marked packets is not guaranteed.

-- Section 3.1 --
Is there any reason why the FlowMonID is 20 bit long ? Exactly as the 20-bit
Flow Label of the IPv6 header... See my comments for section 5.3

s/Unrecognized Types MUST be ignored on receipt./Unrecognized Types MUST be
ignored on processing./ as the option should be processed not only by the
destination node.

-- Section 5 --
This section (in a standard track I-D) repeats many things from experimental
RFCs... This is really confusing and, while I am usually not dogmatic, I
support my fellow AD on this point.

Moreover, repeating contents from other docs can only introduce inconsistencies
among docs => suggest to remove section 5.1 and 5.2.

-- Section 5.3 --
The general reasons of using a 20-bit FlowMonID appear quite weak to me with
the risk of collision being very high, e.g., in a DC with thousands of VM and
millions of containers there will be collisions rendering this field useless.
Strongly suggest to make its use optional

---

From: Giuseppe Fioccola <[email-masked]>
Date: Thu, 12 Aug 2021 15:04:44 +0000

Dear Eric,
Thank you! I will revise the draft and post it in the coming weeks.
I will send a note to all the reviewers.

Regards,

Giuseppe 

-----Original Message-----
From: Éric Vyncke via Datatracker <[email-masked]> 
Sent: Thursday, August 12, 2021 4:02 PM
To: The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Éric Vyncke's Discuss on draft-ietf-6man-ipv6-alt-mark-08: (with DISCUSS and COMMENT)

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)

As Brian Carpenter kindly reminded me that an Area Director may not put back a previous argument when the WG consensus was to ignore it, I am updating this ballot by moving the generic DISCUSS as a COMMENT.

The other two DISCUSS points remains blocking ones but Giuseppe have already addressed them over email, I am clearing the DISCUSS position as soon as the revised I-D is posted.

Special thanks to Ole Trøan for his shepherd's write-up, which contains a good summary of the WG consensus and the SW (?) implementation status. Thanks as well to Bob Halley for his INT directorate review.

Please find below some blocking DISCUSS points, some non-blocking COMMENT points (but replies would be appreciated).

I also agree with DISCUSS points by other ADs:
- Lars's one about the size and usefulness of FlowMonID (see my very similar
point) - Roman's one about the inconsistencies about limited domain (from my point of view, this should not be limited to a single domain)

All in all, I strongly suggest to change the intended status of this document to 'experimental' as this document builds on experimental RFCs.

Regards,

-éric

== DISCUSS ==

-- Section 2 --

-- Section 4 --
Please remove "the destination node removes it" as there is no reason to remove it. Extension headers are usually not presented / used by upper layers anyway.

--- OLD DISCUSS ----
This discussion already happened in the 6MAN WG but I still have to be convinced that hop-by-hop is a good idea at all. The fate of packets with HbH is unknown at best and, IMHO, this is a wrong use of HbH because the forwarding/processing of packets is NOT influenced at all by the AltMark option. What is required is a simple 'marking/coloring', which could be at any place in a packet (including destination option). The only benefit of HbH is its location just after the IPv6 header.

After all, existing devices can measure and generate IPFIX records in hardware/fastpath by inspecting at the bare minimum the 5-tuple and many devices can also parse extension headers in the fast path (of course not processing HbH in this case). I.e., finding the marking in the Dest Option is probably much easier and doable in current hardware rather than using HbH as HbH forces a software processing.

--- END OF OLD DISCUSS ---

-- Section 2.1 --
While I agree with my fellow AD about the inconsistencies of the text around 'limited domain' (and being inconsistent deserves a blocking DISCUSS), I do not agree with this section as I do not see any harm to extend this marking outside of a single domain, marked packets with this specification can traverse the whole Internet without causing any harm and not opening for any attack on the transit nodes. (See also my point about Hop-by-hop)

E.g., packets from organisation A can traverse networks of organizations B, C, ..., Z to reach another site of organization A and still provide useful measurements for A without causing harm to B, C, ..., Z. Of course the survivability of those marked packets is not guaranteed.

-- Section 3.1 --
Is there any reason why the FlowMonID is 20 bit long ? Exactly as the 20-bit Flow Label of the IPv6 header... See my comments for section 5.3

s/Unrecognized Types MUST be ignored on receipt./Unrecognized Types MUST be ignored on processing./ as the option should be processed not only by the destination node.

-- Section 5 --
This section (in a standard track I-D) repeats many things from experimental RFCs... This is really confusing and, while I am usually not dogmatic, I support my fellow AD on this point.

Moreover, repeating contents from other docs can only introduce inconsistencies among docs => suggest to remove section 5.1 and 5.2.

-- Section 5.3 --
The general reasons of using a 20-bit FlowMonID appear quite weak to me with the risk of collision being very high, e.g., in a DC with thousands of VM and millions of containers there will be collisions rendering this field useless.
Strongly suggest to make its use optional