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

[John Evans <[e-mail]>]

Hi Éric,

Thanks again for your review. We've published -15, which incorporates the
changes discussed. Summary against each point:

DISCUSS:

1. checksum-error IPv4/IPv6 ambiguity: Fixed. The leaf description now
states the counter is applicable only to IPv4; IPv6 has no internet-layer
header checksum.

2. mtu-exceeded placement and semantics: Fixed. mtu-exceeded has moved out
of the rx container and is now a separate container with
fragmentation-not-permitted and fragmentation-permitted-not-performed
counters, distinguishing whether the forwarding node was permitted to
fragment (with references to RFC 791 and RFC 8200). As discussed, no-route
remains on ingress since without a route there is no egress interface to
attribute to.  On the multicast case: per requirement 2, discards are
attributed to the interface where they occur, so replications discarded on
m egress interfaces account on each of those interfaces.

3. invalid-sid scope: As discussed, only SR-aware routers processing the
SID increment this counter; the references to RFC 8402/8660/8754/8986 have
been added to the leaf.

4. parity-error specificity: Fixed. The description now states this means
the ASIC detected corruption in an internal memory, table, buffer, or
metadata structure while processing the packet, and dropped it rather than
forwarding using potentially bad state; a device-internal error, not a
property of the packet.

5. DDoS double counting: As discussed, the model has a no-double-counting
principle (requirement 8): a discard increments exactly one subclass, so
ACL- or null-route-mitigated attacks report under those counters, and the
dos counter covers vendor heuristic-based DoS protection. The leaf now
reads DoS rather than DDoS, per Christopher's related comment.

6. Layer-4 ACL: The acl leaf description now covers Layer 3 and
higher-layer ACLs, so these are in scope of the model rather than a
limitation.

7. Encapsulation/decapsulation discards: As discussed, tunnel processing
falls under forwarding; missing tunnel forwarding state is semantically
no-route from an operator's perspective, and requirement 13 states
attribution relates to the outer header at the point of discard.

8. INT-directorate review: Carlos's points are now addressed; the summary
is in the thread with Carlos [
https://mailarchive.ietf.org/arch/msg/opsawg/YMALJRc6CraKCVdVd3Mx7IGc-rI/]
with the GTSM/RFC 5082/RFC 6192 clarification in the next revision.

COMMENTs:

9. IM in YANG rather than UML/ER: The working group conclusion is now
stated in the new Design Rationale section (Section 4): YANG with RFC 8791
structure extensions keeps the model abstract per RFC 3444 while supporting
different DM realizations (YANG, IPFIX) and lossless translation to the
YANG DM. This is also consistent with draft-ietf-opsawg-rfc5706bis, which
explicitly allows YANG structure extensions for information models.

10. On the "cynical" point: that is in fact the intent: the IM exists so
the same classification can be realized in IPFIX and flow-level discards
correlated with device- and interface-level discards. The Introduction now
says this explicitly, and draft-evans-opsawg-ipfix-discard-class-ie shows
the IPFIX realization.

11. ttl-expired naming: Kept, as the class covers IPv4 TTL, IPv6 Hop Limit,
and MPLS TTL expiry; the description now states all three explicitly.

12. Additional errors-l2-tx leaves and IPv6 extension headers: Not added,
consistent with the granularity rationale now in Section 4: subtypes are
included where deployment experience shows they map to distinct mitigation
actions, and new subtypes can be added by future augmentation without
affecting existing implementations.

13. invalid-label under l2: Kept under l3. An invalid label is a lookup
failure, and the same operational action applies as for an L3 lookup
failure, so it belongs in the same class; errors/l2/rx isolates problems to
the L2 domain (upstream device or link). Reporting label lookup failures
under l2 would trigger the wrong mitigation.
Diff:
https://author-tools.ietf.org/iddiff?url1=draft-ietf-opsawg-discardmodel-14&url2=draft-ietf-opsawg-discardmodel-15

Please let us know if there's anything we missed.

Thanks,
John

On Thu, 9 Jul 2026 at 12:40, John Evans <[e-mail]> wrote:

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