[OPSAWG]Re: Ketan Talaulikar's Discuss on draft-ietf-opsawg-discardmodel-14: (with DISCUSS)

[John Evans <[e-mail]>]

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/changes

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="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=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 14:12, Ketan Talaulikar <[e-mail]> 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 PM John Evans <[e-mail]> wrote:
>
>> Hi Ketan,
>>
>> Thank you for your feedback.
>> ---
>>
>> *1) It is not clear to me whether this document considers MPLS traffic as
>> 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. 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.
>>
>>
>> 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, while
>> 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 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 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 MUST
>> 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/changes
>>
>
> KT> Thanks.
>
>
>> ---
>>
>>
>>
>>
>>
>>
>> *3) Regarding unclear normative MUST in the following text:9, When there
>> are multiple reasons for discarding a packet, the ordering ofdiscard class
>> 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/0e94aa53e555c438828a92cdc7fbe7cd999f3385/draft-ietf-opsawg-discardmodel.md?plain=1#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 PCP
>> bitsor 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 asclass[id="0"], which represents the default class.*
>>
>> Clarified here accordingly:
>> https://github.com/o-pylypenko/draft-ietf-opsawg-discardmodel/blob/0e94aa53e555c438828a92cdc7fbe7cd999f3385/draft-ietf-opsawg-discardmodel.md?plain=1#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 also
>> 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/changes
>>
>
> KT> This works.
>
> Thanks,
> Ketan
>
>
>
>>
>>
>> cheers
>>
>> John
>>
>> On Tue, 7 Jul 2026 at 19:31, Ketan Talaulikar via Datatracker <
>> [e-mail]> 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/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 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-MPLS 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. 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 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.
>>>
>>> 4) Regarding 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
>>> reported as
>>> class[id="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.
>>>
>>>
>>>
>>>
>>>
>>>