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: Wed, 11 Aug 2021 06:29:18 -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.

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

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.

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

-- 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: Wed, 11 Aug 2021 14:28:19 +0000

Dear Eric,
Thank you for your review. 
Please find my answers inline tagged as [GF].

Regards,

Giuseppe

-----Original Message-----
From: Éric Vyncke via Datatracker <[email-masked]> 
Sent: Wednesday, August 11, 2021 3:29 PM
To: The IESG <[email-masked]>
Cc: [email-masked]; [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.)

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.

[GF]: As mentioned, it is not built on experimental RFCs. RFC 8321 and RFC 8889 are informative references and not all the techniques described in these two RFCs are applicable to this document. Indeed the detailed methodology is described with reference to the specific application to IPv6. Also note that the experiment, started in 2010, is done as also reported in RFC 8321 (https://datatracker.ietf.org/doc/html/rfc8321#section-5.1)

Regards,

-éric

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

[GF]: The draft defines the AltMark data that can be encapsulated in the IPv6 Options Headers (Hop-by-Hop or Destination Option). HbH is the only choice if you want to perform hop-by-hop measurement otherwise you can use DOH but only for end-to-end measurement. I think that the application to controlled domain helps to mitigate the issue you raised about the unknown fate of packets with HbH. It is limited to the controlled domain.

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.

[GF]: Maybe DOH can be the first choice in the beginning. But it is worth mentioning that there is some ongoing work in 6MAN to redefine HBH procedures in order to make HBH options more practical (e.g. https://datatracker.ietf.org/doc/draft-hinden-6man-hbh-processing/). During IETF 111, it was supported as candidate for the adoption. Our draft could also leverage the outcome of draft-hinden-6man-hbh-processing for future applications. As an example it suggests to change RFC 8200 so that first HBH option MUST be processed in Fast Path. For this reason it would be better to not preclude future improvements of HbH processing.

-- Section 2 --

[GF]: Sure I will remove the statement and the reference to draft-fioccola-v6ops-ipv6-alt-mark (as also suggested by Alvaro).

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

[GF]: Ok, will do.

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

[GF]: Note that in the next version I will clarify the definition of controlled domain. A controlled domain is a managed network and it does not necessarily mean that it is a single administrative domain. It can also include multiple organizations. The requirement is that it must be possible to control the domain boundaries and eventually use IPsec if the traffic traverse the Internet. I would clarify this in Section 2.1.

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

[GF]: We tried to find a compromise. The FlowMonID could be set in two ways: (a) by a Controller, that knows the topology and can set the value properly to avoid/minimize ambiguity, or (b) by the source node, that can set it pseudo-randomly with some chance of collision. So, we picked up 20 bit since this value implies a low rate of ambiguous FlowMonIDs that can be considered acceptable in most of the applications. I can clarify the rationale in the next version.

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.

[GF]: Sure. Will do.

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

[GF]: As mentioned above, not all the techniques described in RFC 8321 and RFC 8889 are applicable to this document. Indeed the detailed methodology is described with reference to the application to IPv6 and to the deployment experience.

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

[GF]: As said, we considered that a low rate of ambiguous FlowMonIDs can be considered acceptable in most of the applications. Indeed with 20 bits the number of combinations is 1048576! There are companion documents on the control plane mechanisms of AltMark (e.g. draft-ietf-idr-sr-policy-ifit, draft-chen-pce-pcep-ifit). In this way the Controller can configure the FlowMonID value properly.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Aug 2021 08:58:36 +1200

Hi Éric,

On 12-Aug-21 01:29, Éric Vyncke via Datatracker wrote:

...> == DISCUSS ==
> convinced that hop-by-hop is a good idea at all. 

Excuse my bluntness, but that doesn't seem OK as part of a DISCUSS. The IESG's
own rules say this at https://www.ietf.org/about/groups/iesg/statements/iesg-discuss-criteria/#stand-undisc :

>> 3.2.  DISCUSS Non-Criteria
...
>> Reiteration of the issues that have been raised and discussed as part of WG or IETF Last Call, unless the AD believes they have not been properly addressed. 

so an AD's personal conviction is not a valid DISCUSS criterion if the matter has already been debated and reached rough consensus.

I'm not disputing your technical arguments at all, which seem to fall under the list of valid DISCUSS criteria. It's just the phrase you used to introduce them.

> transit nodes. (See also my point about Hop-by-hop)

I think they can do harm if the measurement packets happen to follow a path on which a firewall drops packets containing unrecognised HbH options. 
Adding such packets to an existing flow would then break the flow.

   Brian

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Thu, 12 Aug 2021 05:36:33 +0000

Hello Brian,

No excuse required for being blunt ;-) especially when you are right. I will update later today my ballot by moving this point to the COMMENT section (even if the point itself is valid as you wrote below).

About the limited domain, I kind of disagree with you. The fate of HbH outside a 'domain' is well known indeed but should the IETF redefine the extension headers part of RFC 8200 for 'limited domain only' on the same basis ? Of course not ;-)

Regards

-éric

-----Original Message-----
From: Brian E Carpenter <[email-masked]>
Date: Wednesday, 11 August 2021 at 22:58
To: Eric Vyncke <[email-masked]>, The IESG <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Éric Vyncke's Discuss on draft-ietf-6man-ipv6-alt-mark-08: (with DISCUSS and COMMENT)

    Hi Éric,

    ...> == DISCUSS ==

    ...

       Brian

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Thu, 12 Aug 2021 06:16:02 +0000

Giuseppe,

Thank you very for your quick reply.

As you positively answered my DISCUSS points and as I will remove shortly the first one (per my reply to Brian Carpenter), expect me to update my ballot position to no objection before the formal IESG telechat.

I will also reply later about your replies if needed

Regards

-éric

-----Original Message-----
From: Giuseppe Fioccola <[email-masked]>
Date: Wednesday, 11 August 2021 at 16:28
To: Eric Vyncke <[email-masked]>, The IESG <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: Éric Vyncke's Discuss on draft-ietf-6man-ipv6-alt-mark-08: (with DISCUSS and COMMENT)

    Dear Eric,

    Regards,

    Giuseppe

    -----Original Message-----
    From: Éric Vyncke via Datatracker <[email-masked]> 
    Sent: Wednesday, August 11, 2021 3:29 PM
    To: The IESG <[email-masked]>
    Cc: [email-masked]; [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)

    Regards,

    -éric

    == DISCUSS ==

    -- Section 2 --

    -- Section 4 --

    [GF]: Ok, will do.

    -- Section 2.1 --

    -- Section 3.1 --

    [GF]: Sure. Will do.

    -- Section 5 --

    -- Section 5.3 --

---

From: Giuseppe Fioccola <[email-masked]>
Date: Thu, 12 Aug 2021 12:32:38 +0000

Hi Eric,
Thanks a lot for that.

Regards,

Giuseppe

-----Original Message-----
From: Eric Vyncke (evyncke) <[email-masked]> 
Sent: Thursday, August 12, 2021 8:16 AM
To: Giuseppe Fioccola <[email-masked]>; The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Éric Vyncke's Discuss on draft-ietf-6man-ipv6-alt-mark-08: (with DISCUSS and COMMENT)

Giuseppe,

Regards

-éric

-----Original Message-----
From: Giuseppe Fioccola <[email-masked]>
Date: Wednesday, 11 August 2021 at 16:28
To: Eric Vyncke <[email-masked]>, The IESG <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: Éric Vyncke's Discuss on draft-ietf-6man-ipv6-alt-mark-08: (with DISCUSS and COMMENT)

    Dear Eric,

    Regards,

    Giuseppe

    -----Original Message-----
    From: Éric Vyncke via Datatracker <[email-masked]> 
    Sent: Wednesday, August 11, 2021 3:29 PM
    To: The IESG <[email-masked]>
    Cc: [email-masked]; [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)

    Regards,

    -éric

    == DISCUSS ==

    -- Section 2 --

    -- Section 4 --

    [GF]: Ok, will do.

    -- Section 2.1 --

    -- Section 3.1 --

    [GF]: Sure. Will do.

    -- Section 5 --

    -- Section 5.3 --