Hi Rob,
Many thanks for your thoughtful review. Please see inline. Thanks, Bo -----邮件原件----- 发件人: Rob Wilton (rwilton) [mailto:[email protected]] 发送时间: 2022年9月9日 18:43 收件人: [email protected] 抄送: [email protected] 主题: AD review of draft-ietf-opsawg-yang-vpn-service-pm-09 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. Bo: Thanks for pointing this out. Is this better that we simply change to “the underlay topology”? (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. Bo: Thanks. Will do. (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? Bo: Thanks for the suggestion. How about: The model makes the performance data readily available, which can then be subscribed by the client application, such as an orchestrator. (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. Bo: Thanks and agree with your suggestion. Will remove this paragraph. (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. Bo: Thanks for pointing this out. How about we change: For dynamic PM data, e.g. VRF routes or MAC entries, link metrics, and interface metrics, various notifications can be specified to obtain more complete data. (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. Bo: Is it better that we change to “can be specified to obtain historical data in a limited period of time.”? E.g. in some implementation, a controller can store PM data for a year? (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). Bo: Thanks. We can remove the lines if it doesn't help. (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? Bo: "VPN Network PM" mean "VPN Network PM YANG module". How about we rephrase: Apart from the association between the VPN topology and the underlay topology, VPN Network PM YANG module can also provide the performance status of the underlay network and VPN services. For example, network PM the module can provide link PM statistics and port statistics of a underlay network. And it can also provide VPN PM statistics, which can be further split into PM for the VPN tunnel and PM at the VPN PE access node, as illustrated in the following diagram. such as 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 the module VPN PM and shows the difference between two VPN PM measurement methods. One is including the VPN tunnel PM and the other is inter-VPN-access interface PM. // The newly added text are blue. Figure 4 illustrates an example of VPN PM and two VPN PM measurement methods including the VPN tunnel PM and the inter-VPN-access interface PM. VPN PM can also provide statistics on VPN access interfaces, the number of current VRF routes or L2VPN MAC entry of VPN node (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:" Bo: Agree with the suggestion. Please take a look at the previous one, which has been combined. (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. Bo: Thanks. Will change to “Network Level Performance Monitoring Augmentation”. (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. Bo: Thanks for pointing this out. Your understanding is exactly what we're trying to convey. How about we change to As VPN Network PM YANG module includes two types of PM augmentation, the underlay networks PM is augmented on [RFC8345] when the "service-type" presence container is not defined , and the VPN PM is augmented on [RFC8345] when the "service-type" presence container is defined. For the underlay network performance monitoring, the container of "networks" in [RFC8345] is not augmented. (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? Bo: Agree with your suggestion. Will remove the top-level container “vpn-pm-attributes”. (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"? Bo: Thanks. Will modify all the top-level containers to "perf-mon". (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? Bo: Thanks. Will change as previous one. (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? Bo: Agree. Will change the jitter to gauge32. (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?" Bo: Thanks and agree with the suggestion. (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? Bo: Agree the suggestion. Thanks. (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? Bo: Thanks the suggestion. How about the change: “VPN PM is indicated through this presence containers. When the container is not present, 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? Bo: Yes. Thanks for the suggestion. (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"? Bo: Agree with the suggestion. Thanks. (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. Bo: Thanks. Will add the sentence. (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. Bo: Thanks. Will rephrase as “This is an example of data that could be returned for a 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 Bo: Thanks for catching this. Fixed. 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" Bo: Fixed. 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" Bo: Fixed. 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" Bo: Fixed. 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 Bo: Fixed. Regards, Rob
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
