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

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

Hello John,

With the three PR listed below, I will then clear my DISCUSS points as they will be completely addressed with the new text.

Please let me know when the PR are merged and a revised I-D is submitted.

Regards,

-éric

From: John Evans <[e-mail]>
Date: Thursday, 23 July 2026 at 18:44
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]>; [e-mail] <[e-mail]>
Subject: Re: Éric Vyncke's Discuss on draft-ietf-opsawg-discardmodel-14: (with DISCUSS and COMMENT)

Hi Éric,

> I am afraid that my DISCUSS #2 still hold as the even if the mtu-exceeded has moved out of the rx container it is still in the errors-l3-rx whose description is `Layer 3 ingress packet error discard counters.`.

On DISCUSS #2: the rx class has a specific operational meaning: discards due to errors in the received packet itself, which localizes the fault upstream and narrows the mitigation to the upstream device or link. mtu-exceeded was moved out of rx because an MTU-exceeded packet is not an errored packet; it is a valid packet exceeding a constraint determined at this device, so the upstream-fault mapping does not apply. Structurally it is reportable on both directions, since the errors tree instantiates under the direction-keyed discards list (e.g., discards[direction="egress"]/errors/l3/mtu-exceeded). You are right, though, that mtu-exceeded was still defined inside a grouping named errors-l3-rx, which misrepresented its contents. We have renamed the grouping to errors-l3 and updated its description to distinguish received-packet errors (the rx container) from discards arising during forwarding at this device, reported per direction: https://github.com/o-pylypenko/draft-ietf-opsawg-discardmodel/pull/148/changes

> Same for DISCUSS #3 it is still unclear whether only the router that needs to process the next SID count this packet error or all SR-aware routers on the path.

On DISCUSS #3: this is a discard counter, not an error-detection counter: a packet is discarded at exactly one node, so it is counted exactly once, by the discarding node. Under SRv6 [RFC8754] that is the node processing the SID (where the packet's destination address matches a locally instantiated SID); transit nodes forward on the destination address without inspecting the SID list, so they neither detect nor discard. Agreed this should be stated rather than implied; the leaf description now says so explicitly in the next revision: https://github.com/o-pylypenko/draft-ietf-opsawg-discardmodel/pull/146/changes

> I am not convinced by the explanation of DISCUSS#5 as some text would have been welcome IMHO.

On DISCUSS #5: agreed, the explanation belonged in the document. The dos leaf description now states this explicitly in the next revision: the counter covers dedicated DoS-protection mechanisms (e.g., vendor heuristics that identify and discard DoS traffic), while attacks mitigated via an ACL or null route are reported under acl or null-route respectively, consistent with the no-double-counting requirement. A discard increments exactly one policy subtype, and the association of an ACL or null route with DoS mitigation is known only to the operator: https://github.com/o-pylypenko/draft-ietf-opsawg-discardmodel/pull/147/changes

Please let us know if anything is still open.

Thanks,
John


On Thu, 23 Jul 2026 at 15:35, Eric Vyncke (evyncke) <[e-mail]<mailto:[e-mail]>> wrote:
Thank you John for your reply with explanations and the revised I-D.

I am afraid that my DISCUSS #2 still hold as the even if the mtu-exceeded has moved out of the rx container it is still in the errors-l3-rx whose description is `Layer 3 ingress packet error discard counters.`.

Same for DISCUSS #3 it is still unclear whether only the router that needs to process the next SID count this packet error or all SR-aware routers on the path.

I am not convinced by the explanation of DISCUSS#5 as some text would have been welcome IMHO.

Thank you also for acting on Carlos' int-dir review.

Regards,

-éric

From: John Evans <[e-mail]<mailto:[e-mail]>>
Date: Thursday, 23 July 2026 at 14:01
To: Eric Vyncke (evyncke) <[e-mail]<mailto:[e-mail]>>
Cc: The IESG <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: Re: Éric Vyncke's Discuss on draft-ietf-opsawg-discardmodel-14: (with DISCUSS and COMMENT)


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]<mailto:[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]<mailto:[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'.