[ippm] Re: Éric Vyncke's Discuss on draft-ietf-ippm-asymmetrical-pkts-11: (with DISCUSS and COMMENT)

["Eric Vyncke (evyncke)" <[e-mail]>]

Hello Greg

Thanks for your message and the -13 revision, which actually addresses my concerns.

Nevertheless, this revision has also introduced two non-blocking issues:

  *
SHOULD (in section 3.1) without the required guidance per https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/
  *
The "MAC" expansion includes "address" in section 2.1 😉

I am clearing my DISCUSS within minutes.

Regards

-éric



From: Greg Mirsky <[e-mail]>
Date: Sunday, 15 March 2026 at 07:20
To: Eric Vyncke (evyncke) <[e-mail]>
Cc: The IESG <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: Éric Vyncke's Discuss on draft-ietf-ippm-asymmetrical-pkts-11: (with DISCUSS and COMMENT)

Hi Éric,
Thank you for your thoughtful comments and suggestions. We prepared updates, which I am sharing in my notes below, tagged GIM>>. I attached TXT and HTML versions of the working document along with the diff that highlights all updates applied, addressing DISCUSSES and COMMENTS we received during the IESG reviews.

Regards,
Greg

On Fri, Feb 27, 2026 at 7:19 AM Éric Vyncke via Datatracker <[e-mail]<mailto:[e-mail]>> wrote:
Éric Vyncke has entered the following ballot position for
draft-ietf-ippm-asymmetrical-pkts-11: 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/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ippm-asymmetrical-pkts/



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


# Éric Vyncke INT AD comments for draft-ietf-ippm-asymmetrical-pkts-11
CC @evyncke

Thank you for the work put into this document.

Please find below some blocking DISCUSS points (easy to address), some
non-blocking COMMENT points/nits (replies would be appreciated even if only for
my own education).

I hope that this review helps to improve the document,

Regards,

-éric

Note: this ballot comments follow the Markdown syntax of
https://github.com/mnot/ietf-comments/tree/main, i.e., they can be processed by
a tool to create github issues.

## DISCUSS (blocking)

As noted in
https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/,
a DISCUSS ballot is a request to have a discussion on the points below; I
really think that the document would be improved with a change here, but can be
convinced otherwise.

### Section 2.1.1

MAC addresses are not always 48-bit long... There are 16-bit and 64-bit
addresses in specific layer 2 (e.g., IEEE 802.15.4). So, either the
title/abstract/introduction must be very specific to only handle 48-bit MAC
addresses or (better IMHO) the Sub-TLV should allow different size of MAC
addresses.
GIM>> Thank you for pointing that out to us. We re-worked Section 3.1.1 as follows:
NEW TEXT:
 3.1.1.  Layer 2 Address Group Sub-TLV

   An optional Layer 2 Address Group sub-TLV is a variable-length sub-
   TLV that includes a Layer 2 Address Group Mask and Address Group
   fields used by the Session-Sender to select the Session-Reflectors
   for a response.  The Layer 2 Address Group sub-TLV can convey EUI-48
   (Extended Unique Identifier), EUI-64 ([IEEE-802.3-2022], and a 16-bit
   short address for local identification within a Personal Area Network
   ([IEEE-802.15.4-2024]).  The format of the Layer 2 Address Group sub-
   TLV is presented in Figure 2.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Sub-TLVFlags| Sub-TLV Type  |         Sub-TLV Length          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~           Layer 2 Address Group Mask (variable length)        ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~           Layer 2 Address Group  (varaible length)            ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 2: Layer 2 Address Group Sub-TLV Format

   where:

      Sub-TLV Type is a one-octet field.  IANA is requested to assign
      value TBA2 (Section 8.3).

      Sub-TLV Length is a two-octet field whose value equals the length
      of the Value field of the Layer 2 Address Group sub-TLV in octets.
      Because lengths of MAC Address Group Mask and MAC Address Group
      fields MUST be equal, valid values for the Sub-TLV Length are 4,
      12, and 16.  Any other value MUST be considered by the Session-
      Reflector as a malformed sub-TLV.

   The Value field of the Layer 2 Address Group sub-TLV consists of the
   following fields:

      Layer 2 Address Group Mask: A field that represents the bitmask to
      be applied to all MAC addresses associated with the Session-
      Reflector.  The length of the field is 1/2 the value of the sub-
      TLV Length field.

      Layer 2 Address Group: A field that represents the group to which
      this TLV is addressed.  The length of the field is 1/2 the value
      of the sub-TLV Length field.

   If the Session-Reflector applies the value of the Layer 2 Address
   Group Mask field (using a bitwise AND) to any of its MAC addresses
   with the same length and the result is equal to the value of the
   Layer 2 Address Group field, then the Session-Reflector MUST stop
   processing the Layer 2 Address Group sub-TLV and continue processing
   the received test packet.  If no matches are found, the Session-
   Reflector MUST stop processing the received packet.

Please share your thoughts about the updated text, if it addresses your DISCUSS.


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


## COMMENTS (non-blocking)

### Section 2

While I can understand the value of requesting several 'reflected' packets, but
should there also be an option to send only 1% or 10% or ... of reflected
packets (e.g., via a random selection), notably when using a destination group
multicast address.
GIM>> If that is desired, a Session-Sender can set the value of the Number of the Reflected Packets field in the Reflected Test Packet Control TLV to zero in the STAMP test packet it transmits. Then the Session-Reflector will not reflect the packet but drop the received STAMP test packet.

### Section 2.1.1

Please be specific about how the bitmask is used (I guess a AND operation but
this should not be ambiguous).
GIM>> Thank you for the suggestion to clarify the text. Please let us know if the updated text in Sections 3.1.1 and 3.1.2 is sufficiently clear.
For Layer 2 sub-TLV:
 NEW TEXT:
   If the Session-Reflector applies the value of the Layer 2 Address
   Group Mask field (using a bitwise AND) to any of its MAC addresses
   with the same length and the result is equal to the value of the
   Layer 2 Address Group field, then the Session-Reflector MUST stop
   processing the Layer 2 Address Group sub-TLV and continue processing
   the received test packet.  If no matches are found, the Session-
   Reflector MUST stop processing the received packet.
For Layer 2 sub-TLV:
NEW TEXT:
   When processing this sub-TLV, the Session-Reflector will construct an
   IP mask according to the value, n, in the Prefix Length field.  The
   IP mask will be an IP address (of the family specified by the value
   of the Sub-TLV Length field, according to the semantics above) where
   the n most-significant bits are set to 1 and all other bits are set
   to 0.  Once the mask is constructed, if the Session-Reflector applies
   it (using a bitwise AND) to any of its IP addresses of the same
   family and the result is equal to the value in the IP Prefix field,
   then the Session-Reflector MUST stop processing the Layer 3 Address
   Group sub-TLV and continue processing the received test packet.  If
   no matches are found, the Session-Reflector MUST stop processing the
   received packet.

## NITS (non-blocking / cosmetic)

### Use of SVG graphics

To make a much nicer HTML rendering, suggest using the aasvg tool to generate
SVG graphics. It is worth a try especially if the I-D uses the Kramdown file
format ;-)
GIM>> Thank you for encouraging me to learn SVG. Please check the results in the SVG copy of the draft.