VPN PM: The string type definition of “pm-source” needs to be considered - from IETF 111 presentation

[lana-wu]

Revision 01: https://datatracker.ietf.org/doc/draft-ietf-opsawg-yang-vpn-service-pm/ OPSAWG meeting discussion： augment /nw:networks/nw:network/nt:link: +--rw pm-attributes +--rw low-percentile? percentile +--rw middle-percentile? percentile +--rw high-percentile? percentile +--ro pm-source? string From chair Joe: pm-source is a string. Would an identity be better? Robert Wilton: if there are potentially multiple sources then maybe a leaflist or identities would also make sense

[boucadair]

The comment from Joe makes sense. This should be linked with the examples provided in the draft:

"pm-source": Indicates the performance monitoring source. The data for the topology link can be based, e.g., on BGP-LS [RFC8571]. The statistics of the VPN abstract links can be collected based upon VPN OAM mechanisms, e.g., OAM mechanisms specified in [I-D.ietf-opsawg-l3sm-l3nm], or Ethernet service OAM specified in [I-D.ietf-opsawg-l2nm]. Alternatively, the data can be based upon the underlay technology OAM mechanisms, for example, GRE tunnel OAM.

[lana-wu]

Propose to add new “Identity” to address this comment:

identity pm-source-type { description "Base identity from which specific performance monitoring mechanism types are derived."; }

identity pm-source-bgpls { base pm-source-type; description "Indicate BGP-LS as the performance monitoring metric source"; reference "RFC8571"; }

identity pm-source-twamp { base pm-source-type; description "Indicate Two-Way Active Measurement Protocol(TWAMP) as the performance monitoring metric source."; reference "RFC5357"; }

identity pm-source-y-1731 { base pm-source-type; description "Indicate Ethernet OAM Y.1731 as the performance monitoring metric source."; reference "ITU-T Y.1731"; }

[boucadair]

Looks good to me.

One minor nit: s/Indicate/Indicates

Thank you.

[vlopezalvarez]

Based on the current state of https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-l2nm and https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-l3sm-l3nm: +--rw oam | +--rw bfd {vpn-common:bfd}?

+--rw ethernet-service-oam | +--rw md-name? string | +--rw md-level? uint8 | +--rw cfm-802.1-ag | +--rw y-1731* [maid]

Is it possible to point to TWAMP or BGP-LS that are not defined in the service? We may consider extending the LxNM OAM modes in this draft or in a separate document.

[lana-wu]

@vlopezalvarez This PM draft is defined to establish the PM metric association with VPN and basic network topology. BGP-LS and TWAMP is used to obtain the PM metrics of network topology links. To make this clear, I can add some text to describe. Regarding BFD and 8021.ag OAM definition, these two are fault management tools, which do not support the PM function.

[vlopezalvarez]

Thanks @lana-wu. My point is that OAM defined in VPN model should have a relationship with the OAM tests that you are running to get PM metrics. If you set up a VPN service that you want to monitor with TWAMP, then you can have in the VPN model a way to hook it with this OAM test you want to run to retrieve PM metric.

Regarding BGP-LS, I agree with your comment is not an active measurement, but for TWAMP or other protocols as described in rfc7276 we may consider it.

[lana-wu]

@vlopezalvarez Looking at the LxNM draft, I find OAM defined under "vpn-network-access", which is different with this issue. This issue is about the PM metric of logic links between “vpn-node”. I am wondering whether this PM mechanism between “vpn-node” is in the scope of LxNM or not?

[boucadair]

Fixed in -02