Dear authors,
I reviewed the first part of the draft, up to the IM.
This draft reads easily. Good job.
Some feedback/questions.
- Abstract
This document defines an Information Model and specifies a
corresponding YANG data model for packet discard reporting. The
Information Model provides an implementation-independent framework
for classifying packet loss — both intended (e.g., due to policy) and
unintended (e.g., due to congestion or errors) — to enable automated
network mitigation of unintended packet loss. The YANG data model
specifies an implementation of this framework for network elements.
PROPOSAL: an implementation of this information model
- terminology section
Packet Discard total = Intended Discards total + Unintended Discards total?
Why do I ask? Because, when I read "Intended discards are packets dropped due",
I was thinking: should it be
"Intended discards are Packet Discard dropped due"? And then, Discard
dropped... this is redundant.
Maybe it doesn't read nice, but I was wondering whether Intended/Unintended
Discards definitions should be based on the Packet Discard one?
Also, make it clear what the definition is.
For example, in "Device discard counters do not by themselves establish
operator", what is the definition: the Device Discard or Device Discard Counters?
Reading the "Device discard counters" entry, it doesn't look like a definition.
You see how I used capitalized definition to make it clearer what the
definition is.
-
FEATURE-DISCARD-CLASS: The type or class of discards, which is
crucial for selecting the appropriate of mitigation - for example:
error discards may require taking faulty components out of
service; no-buffer discards may require traffic redistribution;
intended policy discards typically require no automated action
... no automated action, except trying to sell a better service ... which
requires automation :-)
-
FEATURE-DISCARD-SCOPE: Determines which devices, interfaces, and/or
flows are impacted.
...
While FEATURE-DISCARD-SCOPE, FEATURE-DISCARD-RATE, and FEATURE-
DISCARD-DURATION are implicitly supported by MIB-II [RFC2863] and the
YANG Data Model for Interface Management [RFC8343],
I disagree with this broad statement: flows are not handled by those two
references
-
structure packet-discard-reporting:
+-- control-plane {control-plane-stats}?
| +-- traffic* [direction]
| | ...
| +-- discards* [direction]
| ...
* Component:
- control-plane: discards of traffic to or from a device's
control plane.
With control plane policing (CoPP) in mind, I was thinking that it would be
applicable to incoming traffic only.
Would you have an example of outgoing control plane traffic, which would be
recognized a control plane traffic, not simply outgoing interface errors.
-
4.2. Sub-type Definitions
In some entries, you wrote "in the received packet"
So there are applicable only to the ingress direction?
In some entries, I was expecting "in the received packet" but I don't see it
discards/error/l3/rx/ttl-expired
discards/error/l3/no-route/
Interestingly, the YANG leaf mentioned "received packets"
leaf ttl-expired {
type yang:counter64;
description
"The number of received packets discarded due to
expired TTL.";
}
Some consistency would help.
- in the IM YANG model, I am surprised that you had to define those identities
identity address-family {
description
"Defines a type for the address family.";
}
identity ipv4 {
base address-family;
description
"Identity for an IPv4 address family.";
}
identity ipv6 {
base address-family;
description
"Identity for an IPv6 address family.";
}
identity all {
base address-family;
description
"Identity for all address families.";
}
I would have been expecting that it was defined already in an existing IETF
YANG modules.
The YANG doctors will tell.
-
| | | +-- address-family-stat* [address-family]
| | | +-- address-family identityref
| | | +-- packets? yang:counter64
| | | +-- bytes? yang:counter64
| | | +-- unicast
| | | | +-- packets? yang:counter64
| | | | +-- bytes? yang:counter64
| | | +-- multicast
| | | +-- packets? yang:counter64
| | | +-- bytes? yang:counter64
broadcast and anycast discards are not valuable to you?
NITS:
OLD:
For example, [RFC7270] provides support for
reporting discards per flow in IP Flow Information Export (IPFIX)
[RFC7011] using forwardingStatus
NEW:
For example, [RFC7270] provides support for
reporting discards per flow in IP Flow Information Export (IPFIX)
[RFC7011] using the forwardingStatus IPFIX Information Element
Regards, Benoit
_______________________________________________
OPSAWG mailing list -- [email protected]
To unsubscribe send an email to [email protected]
