Return-Path: X-Original-To: opsawg@mail2.ietf.org Delivered-To: opsawg@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id BDEA811D487FC for ; Thu, 23 Jul 2026 03:42:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1784803326; bh=1+hm8JflFjya4infgTUTdVt7NiGk8ejChgxn+gqw1K0=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=KrQHIPqm2Q/MtHrDYJFmGcSbIxIFt2RgWlwR9g3GW8DIrpijc+30Wo0poNtRtX1IA 7jCPtrauz9kvBhD+h1PErnlnoKMFLkIBN15mIFaZqIbdnrTBZpCE0evnk36Udm6ubI YzWKfy15JYjjIEEiLSImusbiMiHyqQT9017FLsiE= X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -1.088 X-Spam-Level: X-Spam-Status: No, score=-1.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ARSNlpFfXePw for ; Thu, 23 Jul 2026 03:42:05 -0700 (PDT) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id CB04211D487E1 for ; Thu, 23 Jul 2026 03:42:05 -0700 (PDT) Received: by mail-lj1-x234.google.com with SMTP id 38308e7fff4ca-39c9452243cso3679811fa.3 for ; Thu, 23 Jul 2026 03:42:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1784803325; cv=none; d=google.com; s=arc-20260327; b=O3DYDl5LmHdGlcTxFOpCKKwShr9ORZRVoCk6+D3sJX3t4I5+JrHD3AlvY4hyPFzabt vduEN052Sob/QAwYCAUMzyDRcskdIOTKYukkGehCOPmw0ydAukhI0w0YKpdi0mHDghBv g3EUigXhHc+Nt9/NNH4qV+Fkm8baFvVwmOrMRIPB0wKQZHiUdbCiVxZmOKMyZ27ERgFC rSOxN+RLRdUUC2ulUiFITD6XKVhWpR0gTilqZLtdUkhIqtciRolqX4Vn1PgNkyaOr09+ NIeOfxebOnDyrst/X+uPeyMVM6BsRHo+i4ylb7D/Ym6BmxpOK3seUh5GNmCm5fF9J55C 2I+g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=xfMprLhJGcmtuRTFZpGaiuXYqRhcyCUqIDX5DDNBXn0=; fh=U7sBKK6xNhU6FxmnKJgHXmwbDXnanyD4364Q2auZYi0=; b=n3B/4HbVOFXX33m7Bal6SZIyNzl+FZDItz9y/EQm9oZV/42YFxOgEzj6n0J08/gMDm 3JWhSvYi0NrVuv0Lx6O2nD/IK1lQX92x5vTTMiCffga3BFXNI1vAxxKpwSDEfubs2ci7 dFzozDaTpGtpPjbkHziHvUdSqJtiXvsZUIUN7LdsJRpiCRmL1BO6y+bNyi/DDRU/rymF 4wZ1LqIQCOtL/Di8JD1E4Jw5RAOH0ISTODnUzsdlhAzVce0M5YgSs3p5k+swZAR0PiO6 sFq7c9ePvysvFkLzXHplih61VOCWkb6O/U90ch50QNDA2/+DjMMSw49FKIVH9UsEgPPr /aTg==; darn=ietf.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1784803325; x=1785408125; darn=ietf.org; h=content-type:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to :content-type; bh=xfMprLhJGcmtuRTFZpGaiuXYqRhcyCUqIDX5DDNBXn0=; b=o1TWKuGRPBs4lB0lbx1QG+qBkYZtv9GH+zQjARL6HgOMfXlPfWBhCfU5gNKoSBqRxU a5AWnHNhj0tPMXvZ5aGpLuH7Zo+SrgMOLk19u8cbs9hV0NrTLlSqqoD1L54F3fm+yiGW 2dbZxqfXbMGY951ZmzN//6DRLOpItoxKA4U4F0l5HHmXgl10eWQkbZCCUy7L8MAoSdiJ p5CzO0xMWgBBGjHnwS0+sKAmrfWzU5Z4rXroYDGcp5F4NmUNYAjmMD5JeN8p8zFr+5aC 5khnHP/i4mSwJLZRXynSu84W57TC2hla4MayJF2J+Rhp3sbrNsPd1Rc4KPA8LQw9xfyc 4hIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784803325; x=1785408125; h=content-type:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=xfMprLhJGcmtuRTFZpGaiuXYqRhcyCUqIDX5DDNBXn0=; b=RwSNYb/8qXvHoaPZ3sqc7WZ7H6ZAvFRd7oxKsnNSmENJNI7RQD8tNKByqatYtdz66A 6xb0YBAiiqKnHBC/KbAjEzJ7uSANlG0ZBN7k0pQxB6z82pK9npV2CejHaLMZYCUwywG2 FuMUawBYez212wBQRu02CpyfPU0mtv3pzo8ijVarPVc+AsJbYO2zrvs+piWZvBjoYAEg 6QEpfR1zdoCBvwyh48FA6whdBkZh3uDed0YotmQCNd/n160XMkVjYIdty+1GKwqKW6yj cwtR/7Rho1IOmpBy3WuwO/pI1lSN8tsLCa5MSEAvPifPhatc+4r6b9GO6Vg7OrjFJUkV EH4w== X-Forwarded-Encrypted: i=1; AHgh+RrOzKE9+pXNiD0xhbzKvBqvFvnH0L2gL5OLouNnqF15/RWXohhXzCK/q5HeeyD8Q03wTYuNOAo=@ietf.org X-Gm-Message-State: AOJu0YzJLze3x1q0BkIwa/uu8kDsj6/hMpef6UapVFCMApHMJ8jR3cXM hAi3c4C+Y4dsdLZAWHqR0LsxLFok89gRyLyhBbqt9hRcOy4o4RODfalYzVdWAmNuAmbCQDAMPML Jj6rQQqnddMrb+tMqaLhAtkrykKMzrIw= X-Gm-Gg: AR+sD13Nl3361C6MRvdrLYwt1VrXJxg/7NSWxVUXcWtCA8bNPm2v1lfbV/e6jqcwz41 Gg7A9ChF0V7Hnw6xM/UGdHLKKuh64PHG77okzPGk2LSVBVFr0jpIMXuEydJ39Ml+ZUdz9hckOjO dZIcAjCKv3v0wii9URw4CoPPzToV5BJ7tw501dUV/A/kmq5MrFqspPLiHdDgV/z133/RQo9kZTa l7NL8CAk6dmy9YCvkcCksq1SliY34NUBG7bChv/L3Qe6IG60p64aXdbXaeRpxjVpKK19H0h5Eta s5I4icUjeMEQOwfPGaqOwnLMpSYKTw55V7GGQ/VGpzykZmx0wbW1FZLyPVDZvw== X-Received: by 2002:a2e:a544:0:b0:39c:a346:8a45 with SMTP id 38308e7fff4ca-39f07f32c4bmr4547161fa.39.1784803324198; Thu, 23 Jul 2026 03:42:04 -0700 (PDT) MIME-Version: 1.0 References: <178344907947.427229.13566876556189523276@dt-datatracker-57b5d8f849-v5cht> In-Reply-To: From: John Evans Date: Thu, 23 Jul 2026 11:41:52 +0100 X-Gm-Features: AUfX_myR5ANoK82-fg-BPrG7-8f61ewtbGVpQdU83u5Ofg8_mXae0jwrgFJ-uvU Message-ID: To: Ketan Talaulikar Content-Type: multipart/alternative; boundary="0000000000002205c2065744e836" Message-ID-Hash: LC4ZALKHRVTTGO46WC7ZOI32V7KO4WIG X-Message-ID-Hash: LC4ZALKHRVTTGO46WC7ZOI32V7KO4WIG X-MailFrom: john.evans.uk@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-opsawg.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: The IESG , draft-ietf-opsawg-discardmodel@ietf.org, opsawg-chairs@ietf.org, opsawg@ietf.org X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BOPSAWG=5DRe=3A_Ketan_Talaulikar=27s_Discuss_on_draft-ietf-opsaw?= =?utf-8?q?g-discardmodel-14=3A_=28with_DISCUSS=29?= List-Id: OPSA Working Group Mail List Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --0000000000002205c2065744e836 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ketan, Thanks again for your comments. We've published -15. Summary against each of your comments: 1. MPLS and encapsulation coverage: MPLS-forwarded packets are accounted for at Layer 3: the model classifies by processing stage, and label lookup is part of forwarding lookup, which is why invalid-label sits under errors/l3, no-ILM under no-route, and MPLS TTL expiry under ttl-expired. SRv6 is covered under ipv6, and tunnel encapsulations by the outer header (requirement 13). 2. Requirement 5 now scopes the rule to discards. 3. Discard ordering: Discard ordering: We have reworded requirement 9 in the next revision so that the normative requirement is that the ordering be unambiguous, with discard-order-capability as the SHOULD mechanism and other documented mechanisms as MAY where implementation constraints require: https://github.com/o-pylypenko/draft-ietf-opsawg-discardmodel/pull/142/chan= ges 4. Requirement 10 now defines class[id] as the QoS class assigned by the forwarding implementation using Diffserv, IEEE 802.1Q PCP, MPLS TC, or another mechanism, with class[id=3D"0"] as the default when no QoS classification is used. 5. What is meant by "origin"? This is an error from an earlier edit - now corrected Diff: https://author-tools.ietf.org/iddiff?url1=3Ddraft-ietf-opsawg-discardmodel-= 14&url2=3Ddraft-ietf-opsawg-discardmodel-15 Please let us know if there's anything we missed. Thanks, John On Thu, 9 Jul 2026 at 14:12, Ketan Talaulikar wrote= : > Hi John, > > Thanks for your responses. Please see my follow-up questions and > clarifications on a couple of points that remain open for discussion. > > > On Thu, Jul 9, 2026 at 5:39=E2=80=AFPM John Evans wrote: > >> Hi Ketan, >> >> Thank you for your feedback. >> --- >> >> *1) It is not clear to me whether this document considers MPLS traffic a= s >> L2 orL3 (it is somewhat L2.5). * >> >> Carlos raised this too: >> >> 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. T= he >> 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. >> >> >> To explain the reasoning more clearly we propose to add a design >> rationale section. >> >> 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, whil= e >> preserving the current causal discard taxonomy. >> > > KT> The point that I raise is somewhat different. Since every packet > discard (and successful processing) MUST be accounted for, it is importan= t > to specify where and how MPLS forwarded packets will be covered. This can > be perhaps done by stating they are accounted for as L3 packets (as I > assume was the intention). Coming to SRv6, it seems straightforward to > assume they are covered under IPv6. Similarly, VXLAN or GENEVE should be > covered under IPv4/IPv6 depending on the outer header type. The > augmentation you suggest could cover MPLS-specific (or other technology > specific) processing that results in discards. However, the model already > accounts for invalid-label and no-route discards (which cover > no-label/ILM?). My point is that the goal for covering every discard (a > normative MUST) will not be met without classifying where MPLS and these > other encapsulation technologies are covered. The model also lacks a > "protocol-specific" or "other" discard counter to account for items not > currently covered but which may be augmented in the future. > > > >> --- >> >> >> *2) Regarding the following text:5. A frame accounted for at Layer 2 MUS= T >> NOT be accounted for at Layer 3 andvice versa. This is to avoid double >> counting.* >> >> Clarified here accordingly: >> https://github.com/o-pylypenko/draft-ietf-opsawg-discardmodel/pull/115/c= hanges >> > > KT> Thanks. > > >> --- >> >> >> >> >> >> >> *3) Regarding unclear normative MUST in the following text:9, When there >> are multiple reasons for discarding a packet, the ordering ofdiscard cla= ss >> reporting MUST be defined. Typically, this can be exposed by >> animplementation by means of discard-order-capability.I am not sure what >> "MUST be defined" means. It sounds vague for something thatis a MUST.* >> >> This is with the discard ordering capability in the YANG model. >> Clarified here accordingly: >> https://github.com/o-pylypenko/draft-ietf-opsawg-discardmodel/blob/0e94a= a53e555c438828a92cdc7fbe7cd999f3385/draft-ietf-opsawg-discardmodel.md?plain= =3D1#L497 >> > > KT> This is an improvement. Since MUST is used to promote > interoperability, I wonder if its use is proper here if the way this is > done is not specified. Especially, when the document defines only one way > of reporting: discard-order-capability. Would saying 'SHOULD use > discard-order-capability, but MAY use something else similar for ... xyz > (e.g., implementation constraint)' be a better way? > > >> --- >> >> >> >> >> *4) Regarding the following text, what about QoS based on IEEE 802.1Q PC= P >> bitsor based on MPLS EXP bits ? What about QoS marking based on other th= an >> DSCP?10. If Diffserv [RFC2475] is not used, no-buffer discards MUST be >> reported asclass[id=3D"0"], which represents the default class.* >> >> Clarified here accordingly: >> https://github.com/o-pylypenko/draft-ietf-opsawg-discardmodel/blob/0e94a= a53e555c438828a92cdc7fbe7cd999f3385/draft-ietf-opsawg-discardmodel.md?plain= =3D1#L498 >> > > KT> Great! > > >> >> --- >> >> >> >> >> >> >> *5) Could you clarify what is meant by "origin" here?14. Traffic to the >> device control plane (to-CPU) has its own class. Trafficfrom the device >> control plane (from-CPU) is accounted for by origin,independent of the >> forwarding mechanism (e.g., any egress policer ittraverses), and MUST al= so >> be accounted for in the same way as other egresstraffic.* >> >> This is an error from an earlier edit - now corrected: >> >> https://github.com/o-pylypenko/draft-ietf-opsawg-discardmodel/pull/113/c= hanges >> > > KT> This works. > > Thanks, > Ketan > > > >> >> >> cheers >> >> John >> >> On Tue, 7 Jul 2026 at 19:31, Ketan Talaulikar via Datatracker < >> noreply@ietf.org> wrote: >> >>> Ketan Talaulikar 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-posit= ions/ >>> 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: >>> ---------------------------------------------------------------------- >>> >>> Thanks to the authors and the WG for their work on this document. >>> >>> There are a few topics that I would like to discuss. >>> >>> 1) It is not clear to me whether this document considers MPLS traffic a= s >>> L2 or >>> L3 (it is somewhat L2.5). Some aspects of L3 apply like "no route" but >>> for MPLS >>> it should be "no ILM". Then again there is some coverage for SR-MPLS an= d >>> invalid-label under layer 3 so I am assuming it is considered under L3? >>> In any >>> case, I was looking for some clarity and if discards for MPLS traffic >>> would >>> benefit from their separate counters as opposed to putting them under >>> L3. Under >>> L3, there is also address-family that covers IPv4 and IPv6 but not MPLS= . >>> There >>> are also cases where the MPLS label is disposed and inner IP packet >>> processed >>> so we get multiple processing stages (see related point on double >>> counting >>> further below). Same happens on the egress direction as well. >>> >>> 2) Regarding the following text: >>> >>> 5. A frame accounted for at Layer 2 MUST NOT be accounted for at Layer = 3 >>> and >>> vice versa. This is to avoid double counting. >>> >>> I am assuming this is regarding discards. AFAIK packet reception would >>> get >>> counted at both L2 and L3 layers? There are also some other similar >>> requirements for avoiding double counting which are not very clear to >>> me. If we >>> take example of encapsulations (MPLS, IP-in-IP, etc.) then there can be >>> multiple layers of encapsulation that get disposed or imposed as the >>> packet >>> traverses a router. How are they going to get accounted for in a manner >>> that >>> avoids double counting? >>> >>> 3) Regarding unclear normative MUST in the following text: >>> >>> 9, When there are multiple reasons for discarding a packet, the orderin= g >>> of >>> discard class reporting MUST be defined. Typically, this can be exposed >>> by an >>> implementation by means of discard-order-capability. >>> >>> I am not sure what "MUST be defined" means. It sounds vague for >>> something that >>> is a MUST. >>> >>> 4) Regarding the following text, what about QoS based on IEEE 802.1Q PC= P >>> bits >>> or based on MPLS EXP bits ? What about QoS marking based on other than >>> DSCP? >>> >>> 10. If Diffserv [RFC2475] is not used, no-buffer discards MUST be >>> reported as >>> class[id=3D"0"], which represents the default class. >>> >>> 5) Could you clarify what is meant by "origin" here? >>> >>> 14. Traffic to the device control plane (to-CPU) has its own class. >>> Traffic >>> from the device control plane (from-CPU) is accounted for by origin, >>> independent of the forwarding mechanism (e.g., any egress policer it >>> traverses), and MUST also be accounted for in the same way as other >>> egress >>> traffic. >>> >>> >>> >>> >>> >>> --0000000000002205c2065744e836 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ketan,

Thanks again for your comment= s.=C2=A0=C2=A0We've= =C2=A0published -15. Summary=C2=A0against each of your comments:

1.= =C2=A0MPLS and encapsulation coverage: MPLS-forwarded packets are accounted= for at Layer 3: the model classifies by processing stage, and label lookup= is part of forwarding lookup, which is why invalid-label sits under errors= /l3, no-ILM under no-route, and MPLS TTL expiry under ttl-expired. SRv6 is = covered under ipv6, and tunnel encapsulations by the outer header (requirem= ent 13).

2.=C2=A0Requirement 5 now scopes the rule= to discards.

3.=C2=A0Discard ordering:=C2=A0Discard ordering: We have reworded = requirement 9 in the next revision so that the normative requirement is tha= t the ordering be unambiguous, with discard-order-capability as the SHOULD = mechanism and other documented mechanisms as MAY where implementation const= raints require:=C2=A0https://github.com/o-pylypenko/draft-ietf-opsawg-discardmodel= /pull/142/changes

4.=C2=A0Requirement 1= 0 now defines class[id] as the QoS class assigned by the forwarding impleme= ntation using Diffserv, IEEE 802.1Q PCP, MPLS TC, or another mechanism, wit= h class[id=3D"0"] as the default when no QoS classification is us= ed.

5.=C2=A0What is mea= nt by "origin"?=C2=A0This is an error from an earlier edit - now corrected

= Diff:=C2=A0https://author-tools.ietf.org/iddiff?url1=3Ddraft-ietf-opsawg= -discardmodel-14&url2=3Ddraft-ietf-opsawg-discardmodel-15

Pl= ease let us know if there's anything we missed.

Thanks,
John<= span style=3D"background-color:transparent">

On Thu, 9 Jul 2026= at 14:12, Ketan Talaulikar <ketant.ietf@gmail.com> wrote:
Hi= =C2=A0John,

Thanks for your responses. Please see my fol= low-up questions and clarifications on a couple of points that remain open = for discussion.


On Thu, Jul 9, 2026 at 5:39=E2=80=AFPM = John Evans <john.evans.uk@gmail.com> wrote:
Hi Ketan,

Thank= you for your feedback.
---
1) It is not clear to me= whether this document considers MPLS traffic as L2 or
L3 (it is somewha= t L2.5).=C2=A0

Carlos raised this too:

=
We treated this as a deliberate modelling trade-off rather than an omi= ssion. There are many possible ways to define the tree, including a protoco= l-rooted or address-family-rooted hierarchy where MPLS, SR-MPLS, IPv4, IPv6= , and SRv6 each have their own traffic and discard subtrees. The current mo= del instead keeps forwarding family and causal discard class largely orthog= onal.=C2=A0 This is discussed in 6.2.2

   2.  There are many possible ways t=
o 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.

To explain the reasoning mor= e clearly we propose to add a design rationale section.

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

KT> The point that I raise is somewhat different. = Since every packet discard (and successful processing) MUST be accounted fo= r, it is important to specify where and how MPLS forwarded packets will be = covered. This can be perhaps done by stating they are accounted for as L3 p= ackets (as I assume was the intention). Coming to SRv6, it seems straightfo= rward to assume they are covered under IPv6. Similarly, VXLAN or GENEVE sho= uld be covered under IPv4/IPv6 depending on the outer header type. The augm= entation you suggest could cover MPLS-specific (or other technology specifi= c) processing that results in discards. However, the model already accounts= for invalid-label and no-route discards (which cover no-label/ILM?). My po= int is that the goal for covering every discard (a normative MUST) will not= be met without classifying where MPLS and these other encapsulation techno= logies are covered. The model also lacks a "protocol-specific" or= "other" discard counter to account for items not currently cover= ed but which may be augmented in the future.

=C2= =A0
---
2) Regarding the following text:
5. A frame accou= nted for at Layer 2 MUST NOT be accounted for at Layer 3 and
vice versa.= This is to avoid double counting.

=

KT> Thanks.
=C2=A0
---
3) Regarding unclear normative MUST in the following text:

= 9, When there are multiple reasons for discarding a packet, the ordering of=
discard class reporting MUST be defined. Typically, this can be exposed= by an
implementation by means of discard-order-capability.
I am not = sure what "MUST be defined" means. It sounds vague for something = that
is a MUST.

This is with the discard or= dering capability in the YANG model.

= KT> This is an improvement. Since MUST is used to promote interoperabili= ty, I wonder if its use is proper here if the way this is done is not speci= fied. Especially, when the document defines only one way of reporting: disc= ard-order-capability. Would saying 'SHOULD use discard-order-capability= , but MAY use something else similar for ... xyz (e.g., implementation cons= traint)' be a better way?
=C2=A0
---
4) Regard= ing the following text, what about QoS based on IEEE 802.1Q PCP bits
or = based on MPLS EXP bits ? What about QoS marking based on other than DSCP?
10. If Diffserv [RFC2475] is not used, no-buffer discards MUST be rep= orted as
class[id=3D"0"], which represents the default class.<= /b>


<= div>KT> Great!
=C2=A0

---
5) Cou= ld you clarify what is meant by "origin" here?

14. Traffic= to the device control plane (to-CPU) has its own class. Traffic
from th= e device control plane (from-CPU) is accounted for by origin,
independen= t of the forwarding mechanism (e.g., any egress policer it
traverses), a= nd MUST also be accounted for in the same way as other egress
traffic.

This is an error from an earlier edit - now= corrected:
=

KT> This works.

Thanks,
Ketan

=C2=A0

=
cheers

John

On Tue, 7 Jul 2026= at 19:31, Ketan Talaulikar via Datatracker <noreply@ietf.org> wrote:
Ketan Talaulikar 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/dra= ft-ietf-opsawg-discardmodel/



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

Thanks to the authors and the WG for their work on this document.

There are a few topics that I would like to discuss.

1) It is not clear to me whether this document considers MPLS traffic as L2= or
L3 (it is somewhat L2.5). Some aspects of L3 apply like "no route"= ; but for MPLS
it should be "no ILM". Then again there is some coverage for SR-M= PLS and
invalid-label under layer 3 so I am assuming it is considered under L3? In = any
case, I was looking for some clarity and if discards for MPLS traffic would=
benefit from their separate counters as opposed to putting them under L3. U= nder
L3, there is also address-family that covers IPv4 and IPv6 but not MPLS. Th= ere
are also cases where the MPLS label is disposed and inner IP packet process= ed
so we get multiple processing stages (see related point on double counting<= br> further below). Same happens on the egress direction as well.

2) Regarding the following text:

5. A frame accounted for at Layer 2 MUST NOT be accounted for at Layer 3 an= d
vice versa. This is to avoid double counting.

I am assuming this is regarding discards. AFAIK packet reception would get<= br> counted at both L2 and L3 layers? There are also some other similar
requirements for avoiding double counting which are not very clear to me. I= f we
take example of encapsulations (MPLS, IP-in-IP, etc.) then there can be
multiple layers of encapsulation that get disposed or imposed as the packet=
traverses a router. How are they going to get accounted for in a manner tha= t
avoids double counting?

3) Regarding unclear normative MUST in the following text:

9, When there are multiple reasons for discarding a packet, the ordering of=
discard class reporting MUST be defined. Typically, this can be exposed by = an
implementation by means of discard-order-capability.

I am not sure what "MUST be defined" means. It sounds vague for s= omething that
is a MUST.

4) Regarding the following text, what about QoS based on IEEE 802.1Q PCP bi= ts
or based on MPLS EXP bits ? What about QoS marking based on other than DSCP= ?

10. If Diffserv [RFC2475] is not used, no-buffer discards MUST be reported = as
class[id=3D"0"], which represents the default class.

5) Could you clarify what is meant by "origin" here?

14. Traffic to the device control plane (to-CPU) has its own class. Traffic=
from the device control plane (from-CPU) is accounted for by origin,
independent of the forwarding mechanism (e.g., any egress policer it
traverses), and MUST also be accounted for in the same way as other egress<= br> traffic.





--0000000000002205c2065744e836--