Thinking some more ...
On 22/09/2022 12:24, tom petch wrote:
On 20/09/2022 17:24, The IESG wrote:
The IESG has received a request from the Operations and Management Area
Working Group WG (opsawg) to consider the following document: - 'A
YANG Model
for Network and VPN Service Performance Monitoring'
<draft-ietf-opsawg-yang-vpn-service-pm-10.txt> as Proposed Standard
The problem starts with the title. Does it meane
A YANG Model for Network Monitoring and VPN Service Performance Monitoring'
or perhaps
A YANG Model for Network Performance Monitoring and VPN Service
Performance Monitoring
or perhaps
A YANG Model for Network Service Performance Monitoring and VPN Service
Performance Monitoring'
while if it was
A YANG Model for Monitoring the Perfomance of a Network and a VPN Service
I would be in no doubt and it would be even clearer if it used the
terminology of the Abstract, to whit
A YANG Model for Monitoring the Perfomance of an Overlay VPN Service and
its Underlay Network
Tom Petch
I struggled to understand what this I-D offered until the AD Review
where the AD had issues similar to mine. Even now, I am unclear if I
understand it; the problem is wording and inconsistent use thereof.
In many places, the I-D says
'This document defines a YANG module for performance monitoring (PM) of
both underlay networks and overlay VPN services '
and it is that 'both' that I think starts to lead the reader, or at
least me, up the garden path.
s.4.2 says
The model can be used for performance monitoring both for the
underlay network and the VPN services. The two would be separate
entries in the network list [RFC8345].
and then talks of the effect of the "service" presence container being
absent or present, which would doubtless twitch the nostrils of a YANG
Doctor.
What it is saying, I think, is that the YANG module
- either provides data for PM of a VPN service
- or provides data for PM for the network itself
but cannot do both, except in the sense that the YANG model in a node
may contain multiple entries in the network list one or more of which is
for a VPN service and one or more of which is for a network itself and
that Netconf, e.g., can retrieve data for both in a single 'get'. I
think that the use of 'both' above is a stretch for that use of the
word, more precisely it is either VPN service or network itself.
The rest of the I-D increases my confusion.
s.4
' The performance monitoring data augments the service topology as
shown in Figure 2.'
Figure 2 has no mention of service. Perhaps the reader must infer that
what is meant is
The YANG module for performance monitoring data augments the YANG
module for service topology - i.e. ietf-network, ietf-network-topology -
The presence container alluded to above appears as
' container service {
presence
"Presence of the container indicates a service
topology, absence of the container indicates an
underlay network."; '
The use of service topology here seems at odds with that in s.4.2 but
later, in several places, there is
when '../nw:network-types/nvp:service' {
description
"Augments only for VPN node attributes.";
Well no, the augments only occurs when 'service' is present and that has
just been defined as
'Presence of the container indicates a service topology';
seems contradictory here and in several places.
Also, in most places, it is 'underlay tunnel' or 'underlay-tunnel'
whereas here it is 'underlay network' as it is in the Abstract and that,
for me, again, leads the reader - me - astray.
In a similar vein, I see
leaf start-time { type yang:date-and-time;
config false; description
"The time that the current measurement started.";
The YANG type is date and time so that is 'The date and time ..'. I
often see monitoring at the same time every day which is what the
description might mean but does not.
Likewise
leaf unit-value {
type identityref { base lime:time-unit-type; }
default "lime:milliseconds";
description
"Time units, where the options are s, ms, ns, etc.";
This is taken from RFC8532 where the options are hours minutes seconds
milliseconds microseconds nanoseconds. I think that the reader deserves
a more accurate description.
I see it as a clever idea to have one YANG module in two different roles
determined by a presence container - perhaps too clever for me.
Tom Petch
The IESG plans to make a decision in the next few weeks, and solicits
final
comments on this action. Please send substantive comments to the
last-call@xxxxxxxx mailing lists by 2022-10-04. Exceptionally,
comments may
be sent to iesg@xxxxxxxx instead. In either case, please retain the
beginning
of the Subject line to allow automated sorting.
Abstract
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
underlay networks and overlay VPN services that can be used to
monitor and manage network performance on the topology of both
layers.
The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-opsawg-yang-vpn-service-pm/
No IPR declarations have been submitted directly on this I-D.
_______________________________________________
IETF-Announce mailing list
IETF-Announce@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf-announce
.
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
