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

[Greg Mirsky <[e-mail]>]

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