[OPSAWG]Re: Éric Vyncke's Discuss on draft-ietf-opsawg-discardmodel-14: (with DISCUSS and COMMENT)

[John Evans <[e-mail]>]

Hi Eric,

Thank you for your feedback.

I have replied to Carlos's comments - copied below.

On your other comments:

> ### Section 4.1
> is ambiguous as there is no check-sum in the IPv6 header.

Now clarified:
https://github.com/o-pylypenko/draft-ietf-opsawg-discardmodel/blob/0e94aa53e555c438828a92cdc7fbe7cd999f3385/yang/ietf-packet-discard-reporting-common.yang#L375

> MTU exceeded does not happen when receiving a packet but when transmitting
> (i.e., after forwarding) a packet on (an)other interface(s).

The egress interface is the constraint, however, the practical
implementation that we see across vendors is that the discards occur on
ingress, once the egress interface has been determined.  Operationally, the
mitigation can be ambiguous (is the MTU too small or the packet too big). We
have changed the model to move mtu-exceeds from under /rx:
https://github.com/o-pylypenko/draft-ietf-opsawg-discardmodel/pull/91/changes

> Same for "no-route".

No route discards have to be on ingress as there is no route to be able to
determine the egress interface.

> `leaf invalid-sid` it is unclear whether only routers whose address is the
> destination address have to count or other routers in the path (which
should
> not check) also have to count.

Only SR-aware routers will increment this when encountered.

> "The number of packets discarded due to parity errors."` does it mean
that the
> device CPU experimented a parity error during the receiving/forwarding of
the
> packet ? Please be specific.

A parity error means that the ASIC detected corruption in an internal
memory, table, buffer, or metadata structure used while processing the
packet, and dropped the packet rather than forwarding it using potentially
bad state.

It does not mean the packet had an L2 CRC error, bad IP checksum, invalid
header, or protocol error. It is not a property of the packet on the wire.
It is a device-internal forwarding error.

We updated the description to clarify:
https://github.com/o-pylypenko/draft-ietf-opsawg-discardmodel/pull/122/changes

> I wonder how to ``"The number of packets discarded due to Distributed
> Denial-of-Service (DDoS) protection policies."` as many DDoS are
mitigated by
> routing to a null-route or layer-3 ACL, which are different counters.
Should it
> be counted twice ?

We have a design principle of not double counting discards.  In this
example, we would report it as ACL or null route discards as only the
network operator knows the intent of that ACL or null route and can make
the association.  A number of vendors have implemented heuristics to
identify and discard DDoS traffic, which is what this class is intended for.

> ### Lack of layer-4 ACL
> I am puzzled by the absence in the model and in the text about layer-4 ACL

We have updated the description accordingly:
https://github.com/o-pylypenko/draft-ietf-opsawg-discardmodel/pull/114/changes

> ### Lack of encapsulation/decapsulation discard
> Probably due a misreading of mine, but I see no discard counters when
> en/decapsulating a tunneled packet ?

This was a point of discussion and we decided not to define dedicated
encap/decap discard classes: tunnel processing falls under forwarding, so
when the required forwarding state is missing, semantically it is the same
as no-route from an operator's perspective. Section 5.3 requirement 13 also
says that tunnel endpoint attribution relates to the outer header.

> ### Lack of addressing the INT-directorate review
> As I second most of Carlos Pignataro's int-dir review, I am elevating
them to a
> DISCUSS level: please address Carlos' issues.

I have replied to Carlos's comments - copied below.

> To be pendantic, I am really surprised (dare I say shocked) by the use of
a
> data modeling language to specify an information model rather than UML or
ER
> diagrams. See also RFC 3444.

This was a point of much discussion in the working group, the conclusion of
which is noted in Section 4:

   The IM is defined using YANG [RFC7950], with Data Structure
   Extensions [RFC8791], allowing the model to remain abstract and
   decoupled from specific implementations in accordance with [RFC3444].
   This abstraction supports different DM implementations, such as YANG
   or IPFIX [RFC7011], while ensuring consistency across
   implementations.

Please note that draft-ietf-opsawg-rfc5706bis also says:

    While an Information Model is typically described in English text (or
    sometimes UML) to define the conceptual management requirements,
    authors may choose to express it using YANG Data Structure Extensions
    [.RFC8791] as described in Section 5.3.1. Using YANG for the
    Information Model can make it easier to link abstract concepts to
    concrete data types in the corresponding Data Model, helping maintain
    consistency between high-level design and practical deployment.

> If I was cynical, I would hint that it is more to have more
implementations
> having 'something' like the information while not implementing exactly
the YANG
> data model... But, this is only my personal feeling.

That is exactly the point, i.e. so that we can represent the same
information model in ipfix and correlate discards at the device or
interface level with the impacted flows.  Please also see:
https://datatracker.ietf.org/doc/html/draft-evans-opsawg-ipfix-discard-class-ie-02
.

> While I am sure that some people will disagree with me (hence a COMMENT
and not
> a DISCUSS), `leaf invalid-label ` should be in errors-l2-rx as MPLS is
more a
> layer-2 (e.g., labels are valid only on a link) especially when a label is
> flagged as 'invalid'.

Our approach has been to define the classification scheme working backwards
from the operations actions that we need to take, so there is a clean
mapping from class to action.  errors-l2-rx essentially isolates
the problem to the L2 domain; adding invalid-label to the class would break
that isolation.

> s/leaf ttl-expired/leaf hop-limit-expired/ after all we are in 2026.

Because the class is intended to cover IPv4 TTL expiry, IPv6 Hop Limit
expiry, and MPLS TTL expiry I propose keeping ttl-expired as the
established operational counter name and have updated the description to
say explicitly that it reports packets discarded because the packet
lifetime expired during forwarding, including IPv4 TTL, IPv6 Hop Limit, and
MPLS TTL expiry:
https://github.com/o-pylypenko/draft-ietf-opsawg-discardmodel/pull/123/changes

> `grouping errors-l2-tx ` would benefit from more leaves (e.g., interface
down,
> no carrier, exceeded transmission attemps, buffer full, ...).
> Should something more specific about IPv6 extension headers be added in
> addition of `leaf invalid-packet ` ?

As per the reply to Carlos:

We took the current level of discard taxonomy granularity as a design
decision.  The intent was to provide enough classification to support
common operational mitigation decisions. This is discussed in Section 6.4.1:

   1.  The number and granularity of discard classes defined in the IM
       represent a compromise.  It aims to provide sufficient detail to
       enable appropriate automated actions while avoiding excessive
       detail, which may hinder quick problem identification.
       Additionally, it helps to limit the quantity of data produced per
       interface, constraining the data volume and device CPU impacts.
       While further granularity is possible, the defined schema has
       generally proven to be sufficient for the task of mitigating
       unintended packet loss.

cheers

John
---

Reply to Carlos:

Hi Carlos,

Thank you for your feedback.

1. No ICMP generation/suppression signal tied to discard events.
   ...
   Recommend either modeling
   ICMP-sent/suppressed state explicitly, or stating the omission is a
   deliberate scope decision with rationale.

It was a design decision to report the key discards and not the protocol
interactions associated with discards.
We have updated the draft to clarify:
https://github.com/o-pylypenko/draft-ietf-opsawg-discardmodel/pull/78/changes

2. Address-family model does not cleanly represent MPLS/SRv6 traffic,
   only its discards.

We treated this as a deliberate modelling trade-off rather than an
omission. There are many possible ways to define the tree, including a
protocol-rooted or address-family-rooted hierarchy where MPLS, SR-MPLS,
IPv4, IPv6, and SRv6 each have their own traffic and discard subtrees. The
current model instead keeps forwarding family and causal discard class
largely orthogonal.  This is discussed in 6.2.2

   2.  There are many possible ways to define the discard classification
       tree.  For example, an approach is to use a multi-rooted tree,
       rooted in each protocol.  Instead, a better approach is to define
       a tree where protocol discards and causal discard classes are
       accounted for orthogonally.  This decision reduces the number of
       combinations of classes and has proven sufficient for determining
       mitigation actions.


That said, if operators find that the current all identity loses useful
information for mitigation or RCA, a future augmentation could add more
specific address-family identities such as mpls, sr-mpls, and srv6, while
preserving the current causal discard taxonomy.

3. `mtu-exceeded` does not distinguish DF-driven discard (IPv4 DF=1,
   IPv6 always) from fragmentable IPv4 (DF=0).

We have added this - please see:
https://github.com/o-pylypenko/draft-ietf-opsawg-discardmodel/pull/91/changes

4. The discard taxonomy (Section 4.2) is not fully 1:1 with the YANG
   identities. Internet-area instances of this gap:

We took the current level of discard taxonomy granularity as a design
decision.  The intent was to provide enough classification to support
common operational mitigation decisions, while avoiding a protocol-specific
tree. This is discussed in Section 6.4.1: the model deliberately treats
protocol context and discard cause as largely orthogonal, rather than
defining a separate leaf for every protocol-specific discard mechanism.

   1.  The number and granularity of discard classes defined in the IM
       represent a compromise.  It aims to provide sufficient detail to
       enable appropriate automated actions while avoiding excessive
       detail, which may hinder quick problem identification.
       Additionally, it helps to limit the quantity of data produced per
       interface, constraining the data volume and device CPU impacts.
       While further granularity is possible, the defined schema has
       generally proven to be sufficient for the task of mitigating
       unintended packet loss.


Nonetheless, we agree that the examples you list are useful candidates for
further discussion and for possible future augmentation of the module.

5. `checksum-error` (errors-l3-rx) does not note that IPv4 has a header
   checksum and IPv6 does not (RFC 791 vs. RFC 8200) -- applicability by
   address family could be stated.

Added:
https://github.com/o-pylypenko/draft-ietf-opsawg-discardmodel/blob/0e94aa53e555c438828a92cdc7fbe7cd999f3385/yang/ietf-packet-discard-reporting-common.yang#L375

6. `invalid-sid` lacks an informative reference to SRv6 architecture
   (RFC 8402 / RFC 8986).

Added:
https://github.com/o-pylypenko/draft-ietf-opsawg-discardmodel/blob/0e94aa53e555c438828a92cdc7fbe7cd999f3385/yang/ietf-packet-discard-reporting-common.yang#L470

7. No neighbor-resolution-failure (ARP/ND unresolved) discard subtype;
   doesn't map cleanly to `no-route` or `internal`.

Added:
https://github.com/o-pylypenko/draft-ietf-opsawg-discardmodel/pull/85/changes

8. Foundational IP references (RFC 791, RFC 8200) are absent despite
   heavy dependence on IP-layer semantics (TTL, header validity, MTU).
   RFC 4884, RFC 5082, RFC 6192, RFC 5085, and RFC 8029 should also be
   added as informative references if the comments are useful.

That's OK per the IESG statement on the matter:
https://datatracker.ietf.org/doc/statement-iesg-iesg-statement-normative-and-informative-references-20060419/.
Especially, this part

"It is not considered necessary to cite basic specifications that may be
safely assumed to be known to practitioners (for example, RFC 791 need not
be cited in every specification that mentions IPv4)."

9. Section 1 scope reads "limited to reporting packet loss at Layer 3
   and frames discarded at Layer 2" but MPLS/SRv6 discard reasons are
   present throughout; please tighten the scope statement.

Tightened:
https://github.com/o-pylypenko/draft-ietf-opsawg-discardmodel/pull/78/changes


10. `invalid-vlan`/`invalid-mac` are Ethernet-specific; note
    applicability for non-Ethernet L2 technologies.

Noted:
https://github.com/o-pylypenko/draft-ietf-opsawg-discardmodel/blob/0e94aa53e555c438828a92cdc7fbe7cd999f3385/yang/ietf-packet-discard-reporting-common.yang#L330
https://github.com/o-pylypenko/draft-ietf-opsawg-discardmodel/blob/0e94aa53e555c438828a92cdc7fbe7cd999f3385/yang/ietf-packet-discard-reporting-common.yang#L338




On Tue, 7 Jul 2026 at 13:30, Éric Vyncke via Datatracker <[e-mail]>
wrote:

> Éric Vyncke has entered the following ballot position for
> draft-ietf-opsawg-discardmodel-14: 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-opsawg-discardmodel/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
>
> # Éric Vyncke INT AD comments for draft-ietf-opsawg-discardmodel-14
> CC @evyncke
>
> Thank you for the work put into this document.
>
> Please find below some blocking DISCUSS points, some non-blocking COMMENT
> points/nits (replies would be appreciated even if only for my own
> education).
>
> Other thanks to Carlos Pignataro, the Internet directorate reviewer (at my
> request), please consider this int-dir review (Ready with issues):
>
> https://datatracker.ietf.org/doc/review-ietf-opsawg-discardmodel-14-intdir-telechat-pignataro-2026-07-03/
> (and I have yet to read a reply by the authors)
>
> 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 4.1
>
> ```
>       leaf checksum-error {
>         type yang:counter64;
>         description
>           "The number of received packets discarded due
>            to a checksum error.";
>       }
> ```
> is ambiguous as there is no check-sum in the IPv6 header. Be specific and
> states that it only applies to IPv4/MPLS.
>
> ```
>     leaf mtu-exceeded {
>         type yang:counter64;
>         description
>           "The number of received packets discarded due to
>            MTU exceeded.";
>       }
> ```
> MTU exceeded does not happen when receiving a packet but when transmitting
> (i.e., after forwarding) a packet on (an)other interface(s). Same for
> "no-route". The problem is even more complex when the forwarded packet is a
> multicast one where it can be forwarded on n egress interfaces but cannot
> for m
> egress interfaces.
>
> `leaf invalid-sid` it is unclear whether only routers whose address is the
> destination address have to count or other routers in the path (which
> should
> not check) also have to count.
>
> `"The number of packets discarded due to parity errors."` does it mean
> that the
> device CPU experimented a parity error during the receiving/forwarding of
> the
> packet ? Please be specific.
>
> I wonder how to ``"The number of packets discarded due to Distributed
> Denial-of-Service (DDoS) protection policies."` as many DDoS are mitigated
> by
> routing to a null-route or layer-3 ACL, which are different counters.
> Should it
> be counted twice ?
>
> ### Lack of layer-4 ACL
>
> I am puzzled by the absence in the model and in the text about layer-4 ACL
> support as they are often used. There should be at least some text in the
> introduction and abstract about this limitation.
>
> ### Lack of encapsulation/decapsulation discard
>
> Probably due a misreading of mine, but I see no discard counters when
> en/decapsulating a tunneled packet ? And/or how it can be differentiated
> from a
> forwarding operation.
>
> ### Lack of addressing the INT-directorate review
>
> As I second most of Carlos Pignataro's int-dir review, I am elevating them
> to a
> DISCUSS level: please address Carlos' issues.
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
>
> ## COMMENTS (non-blocking)
>
> ### Section 4 (and its sub-section)
>
> To be pendantic, I am really surprised (dare I say shocked) by the use of a
> data modeling language to specify an information model rather than UML or
> ER
> diagrams. See also RFC 3444.
>
> Even more 'data model' flavour are the specific data types such as `type
> yang:counter64;`, which clearly belongs to a data model and not an
> information
> model.
>
> Suggest renaming section 4 as a YANG *data* model (as well as changing the
> title & abstract to remove 'information model').
>
> If I was cynical, I would hint that it is more to have more implementations
> having 'something' like the information while not implementing exactly the
> YANG
> data model... But, this is only my personal feeling.
>
> ### Section 4.1
>
> s/leaf ttl-expired/leaf hop-limit-expired/ after all we are in 2026.
>
> `grouping errors-l2-tx ` would benefit from more leaves (e.g., interface
> down,
> no carrier, exceeded transmission attemps, buffer full, ...).
>
> Should something more specific about IPv6 extension headers be added in
> addition of `leaf invalid-packet ` ?
>
> While I am sure that some people will disagree with me (hence a COMMENT
> and not
> a DISCUSS), `leaf invalid-label ` should be in errors-l2-rx as MPLS is
> more a
> layer-2 (e.g., labels are valid only on a link) especially when a label is
> flagged as 'invalid'.
>
>
>
>