Hi,
Here are my AD review comments for draft-ietf-opsawg-yang-vpn-service-pm-09,
apologies for the delay.
I think that this document is in good shape and hence most of my comments are
only minor or nits.
Minor level comments:
(1) p 0, sec
The data model for network topologies defined in RFC 8345 introduces
vertical layering relationships between networks that can be
augmented to cover network and service topologies. This document
defines a YANG module for performance monitoring (PM) of both
networks and VPN services that can be used to monitor and manage
network performance on the topology at higher layer or the service
topology between VPN sites.
"the topology at higher layer" doesn't scan particularly well to me, please can
you tweak it.
(2) p 1, sec 1. Introduction
[RFC8969] describes a framework for automating service and network
management with YANG [RFC6020] models.
Please update reference to RFC 7950 for YANG.
(3) p 4, sec 3. Network and VPN Service Performance Monitoring Model Usage
As shown in Figure 1, in the context of the layering model
architecture described in [RFC8309], the network and VPN service
performance monitoring (PM) model can be used to expose a set of
performance information to the above layer. Such information can be
used by an orchestrator to subscribe to performance data.
Perhaps rephase? I.e., is it the performance data that is being used to create
a subscription based on the performance data, or is it just that the model
makes the performance data readily available, which can then be subscribed do?
(4) p 4, sec 3. Network and VPN Service Performance Monitoring Model Usage
In addition, the amount of performance data collected from the
devices can be huge. To avoid receiving a large amount of
operational data of VPN instances, VPN interfaces, or tunnels, the
network controller can specifically subscribe to metric-specific data
using the tagging methods defined in [I-D.ietf-netmod-node-tags].
At the moment, my reading of the ietf-netmod-node-tags draft is that it doesn't
currently allow you do this. I.e., you can't just make a subscription to all
datanodes that have been tagged in a particular way. Hence, I would suggest
removing this paragraph, since it doesn't seem to be directly related to what
is described in this model.
(5) p 5, sec 3.1. Collecting Data via Pub/Sub Mechanism
Some applications such as service-assurance applications, which must
maintain a continuous view of operational data and state, can use the
subscription model specified in [RFC8641] to subscribe to the
specific network performance data or VPN service performance data
they are interested in, at the data source. For example, network or
VPN topology updates may be obtained through on-change notifications
[RFC8641]. For dynamic PM data, various notifications can be
specified to obtain more complete data.
Can you elaborate a bit on what is meant by dynamic PM data please.
(6) p 5, sec 3.1. Collecting Data via Pub/Sub Mechanism
A periodic notification
[RFC8641] can be specified to obtain real-time performance data, a
replay notification defined in [RFC5277] or [RFC8639] can be
specified to obtain historical data
If this data is coming from a device then ideally it would not hold on to much
historical data.
(7) p 6, sec 4.1. Layering Relationship between Multiple Layers of Topology
Figure 3: Example of Topology Mapping Between VPN Service
Topology and Underlying Network
Note, I don't find this diagram brilliantly clear, it is hard to see when the
dotted lines go
but the explanatory text is clear (and probably sufficient).
(8) p 7, sec 4.1. Layering Relationship between Multiple Layers of Topology
Apart from the association between the VPN topology and the underlay
topology, VPN Network PM can also provide the performance status of
the underlay network and VPN services. For example, network PM can
provide link PM statistics and port statistics. VPN PM can provide
statistics on VPN access interfaces, the number of current VRF routes
or L2VPN MAC entry of VPN nodes, and performance statistics on the
logical point-to-point link between source and destination VPN nodes
or between source and destination VPN access interfaces. Figure 4
illustrates an example of VPN PM and the difference between two VPN
PM measurement methods. One is the VPN tunnel PM and the other is
inter-VPN-access interface PM.
By "VPN Network PM", do you mean the "VPN Network PM YANG module", or is this
just referring to performance monitoring in general?
(9) p 7, sec 4.1. Layering Relationship between Multiple Layers of Topology
Apart from the association between the VPN topology and the underlay
topology, VPN Network PM can also provide the performance status of
the underlay network and VPN services. For example, network PM can
provide link PM statistics and port statistics. VPN PM can provide
statistics on VPN access interfaces, the number of current VRF routes
or L2VPN MAC entry of VPN nodes, and performance statistics on the
logical point-to-point link between source and destination VPN nodes
or between source and destination VPN access interfaces. Figure 4
illustrates an example of VPN PM and the difference between two VPN
PM measurement methods. One is the VPN tunnel PM and the other is
inter-VPN-access interface PM.
I wonder if it would be better to move, and perhaps expand, the "Figure 4"
explanation text to below the diagram? If so, then I would add a joining
sentence here, something like:
"VPN PM can be further split into PM for the VPN tunnel and PM at the VPN PE
access node, as illustrated in the following diagram:"
(10) p 8, sec 4.2. Network Level
Network Level -> Network Level PM? If so, please also change the titles for
4.3 and 4.4.
(11) p 8, sec 4.2. Network Level
For network performance monitoring, the container of "networks" in
[RFC8345] is not extended.
I'm confused by what this sentence is meant to convey - did you mean augmented?
In particular, it isn't clear to me how you express PM for the physical (or
underlay networks). Is what you are trying to express that the "service-type"
container is present for VPN service performance monitoring and absence
otherwise? Probably more words required here, and in the YANG module.
(12) p 8, sec 4.2. Network Level
module: ietf-network-vpn-pm
augment /nw:networks/nw:network/nw:network-types:
+--rw service-type!
+--rw service-type? identityref
augment /nw:networks/nw:network:
+--rw vpn-pm-attributes
+--rw vpn-id? vpn-common:vpn-id
+--rw vpn-service-topology? identityref
These two leaves are added under vpn-pm-attributes, but I was wondering if they
are actually PM specific (particularly vpn-id), or would be better directly
added to the network?
(13) p 8, sec 4.2. Network Level
module: ietf-network-vpn-pm
augment /nw:networks/nw:network/nw:network-types:
+--rw service-type!
+--rw service-type? identityref
augment /nw:networks/nw:network:
+--rw vpn-pm-attributes
+--rw vpn-id? vpn-common:vpn-id
+--rw vpn-service-topology? identityref
I'm not sure that you need "attributes" in the name, isn't that implicit? The
same comment applies for "pm-attributes", and whether just "pm" would be
sufficient, or perfhaps "perf-mon" would be more descriptive in the various
container names rather than "pm"?
(14) p 8, sec 4.3. Node Level
"node-type": Indicates the device type of Provider Edge (PE),
As per above, is "node-type" actually PM specific?
(15) p 10, sec 4.4. Link and Termination Point Level
The performance data of a link is a collection of counters and gauges
that report the performance status.
augment /nw:networks/nw:network/nt:link:
+--rw pm-attributes
+--rw low-percentile? percentile
+--rw intermediate-percentile? percentile
+--rw high-percentile? percentile
+--rw measurement-interval? uint32
+--ro pm* [pm-type]
| +--ro pm-type identityref
| +--ro pm-attributes
| +--ro start-time? yang:date-and-time
| +--ro end-time? yang:date-and-time
| +--ro pm-source? identityref
| +--ro one-way-pm-statistics
| | +--ro loss-statistics
| | | +--ro packet-loss-count? yang:counter64
| | | +--ro loss-ratio? percentage
| | +--ro delay-statistics
| | | +--ro unit-value? identityref
| | | +--ro min-delay-value? yang:gauge64
| | | +--ro max-delay-value? yang:gauge64
| | | +--ro low-delay-percentile? yang:gauge64
| | | +--ro intermediate-delay-percentile? yang:gauge64
| | | +--ro high-delay-percentile? yang:gauge64
| | +--ro jitter-statistics
| | +--ro unit-value? identityref
| | +--ro min-jitter-value? yang:gauge64
| | +--ro max-jitter-value? yang:gauge64
| | +--ro low-jitter-percentile? yang:gauge64
| | +--ro intermediate-jitter-percentile? yang:gauge64
| | +--ro high-jitter-percentile? yang:gauge64
I presume that it is intentional delay and jitter statistics can have different
units, rather than always being aligned to the same units?
(16) p 18, sec 5. Network and VPN Service Performance Monitoring YANG Module
typedef percentage {
type decimal64 {
fraction-digits 5;
range "0..100";
}
description
"Percentage.";
Perhaps "Percentage to 5 decimal places?"
(17) p 18, sec 5. Network and VPN Service Performance Monitoring YANG Module
typedef percentile {
type decimal64 {
fraction-digits 2;
range "0..100";
}
description
"The percentile is a value between 0 and 100,
Perhaps value between 0 and 100 to 2 decimal places?
(18) p 24, sec 5. Network and VPN Service Performance Monitoring YANG Module
augment "/nw:networks/nw:network/nw:network-types" {
description
"Defines the service topologies types.";
container service-type {
presence "Indicates network service topology.";
Perhaps expand either in the presence statement, or the documentation what it
means if this container isn't present. I.e., does this mean that the topology
represents the underlying network?
(19) p 24, sec 5. Network and VPN Service Performance Monitoring YANG Module
leaf service-type {
type identityref {
base vpn-common:service-type;
}
Should this leaf be marked as mandatory? I.e., is it okay to mark it as a
service topology without identifying the srevice type?
(20) p 26, sec 5. Network and VPN Service Performance Monitoring YANG Module
augment "/nw:networks/nw:network/nt:link" {
description
"Augments the network topology link with performance
monitoring attributes.";
container pm-attributes {
description
"Container for PM attributes.";
leaf low-percentile {
type percentile;
default "10.00";
description
"Low percentile to report. Setting low-percentile
into 0.00 indicates the client is not interested
in receiving low percentile.";
}
leaf intermediate-percentile {
type percentile;
default "50.00";
description
"Intermediate percentile to report. Setting
intermediate-percentile into 0.00 indicates the client
is not interested in receiving intermediate percentile.";
}
leaf high-percentile {
type percentile;
default "95.00";
description
"High percentile to report. Setting high-percentile
into 0.00 indicates the client is not interested in
receiving high percentile.";
}
leaf measurement-interval {
type uint32 {
range "1..max";
}
units "seconds";
default "60";
description
"Indicates the time interval to perform PM measurement.";
Perhaps "The time interval to perform PM measurements over"?
(21) p 30, sec 6. Security Considerations
* "/nw:networks/nw:network/nw:node/nt:termination-point/nvp:pm-
statistics": Unauthorized access to this subtree can disclose the
operational state information of network termination points or VPN
network accesses.
Perhaps add a sentence to state that the model does not define any RPC or
Actions.
(22) p 38, sec Appendix A. Illustrative Examples
The following shows an example of a percentile measurement for a VPN
link.
Please can you expand the description a bit. I.e., that this is an example of
data that could be returned for for link foo:vpn1-link1 between vpn-node1 and
vpn-node3.
Nit level comments:
(23) p 3, sec 3. Network and VPN Service Performance Monitoring Model Usage
As shown in Figure 1, in the context of the layering model
architecture described in [RFC8309], the network and VPN service
performance monitoring (PM) model can be used to expose a set of
layering/layered
Grammar Warnings (generated by tooling):
Section: 4.4, draft text:
The statistics of the VPN abstract links can be collected based upon VPN OAM
mechanisms, e.g.,OAM mechanisms referenced in [RFC9182], or Ethernet service
OAM [ITU-T-Y-1731] referenced in [I-D.ietf-opsawg-l2nm].
Warning: Put a space after the comma.
Suggested change: ", OAM"
Section: 6, draft text:
Unauthorized access to this subtree may disable the the VPN PM or render the
VPN service topology invalid.
Warning: Maybe you need to remove one determiner so that only the or the is
left.
Suggested change: "the"
Section: 6, draft text:
Some of the readable data nodes in this YANG module may be considered sensitive
or vulnerable in some network environments.
Warning: If the text is a generality, 'of the' is not necessary.
Suggested change: "Some"
Section: 6, draft text:
- /nw:networks/nw:network/nw:node/nt:termination-point/nvp:pm-statistics":
Unauthorized access to this subtree can disclose the operational state
information of network termination points or VPN network accesses.
Warning: Unpaired symbol: '"' seems to be missing
Regards,
Rob
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
