Subject: [Last-Call] [OPSAWG] Last Call: <draft-ietf-opsawg-l3sm-l3nm-10.txt> (A Layer 3 VPN Network YANG Model) to Proposed Standard

From: Julian Lucek <[email-masked]>
Date: Fri, 6 Aug 2021 14:05:58 +0000

I have the following comments:

1/ In the BFD section, the ability to invoke a profile should be moved up a level, i.e. provide a choice between (i) specifying values for the parameters listed and (ii) invoking a profile

   |  +--rw bfd {vpn-common:bfd}?
   |     +--rw desired-min-tx-interval?   uint32
   |     +--rw required-min-rx-interval?   uint32
   |     +--rw detection-multiplier?      uint8
   |     +--rw (holdtime)?
   |     |  +--:(fixed)
   |     |  |  +--rw fixed-value?    uint32
   |     |  +--:(profile)
   |     |  |  +--rw profile-name?   leafref

2/ vpn-network-access is missing the ability to invoke a lag-interface, including listing which are the member-links. (However the L2-NM model has this feature, this could be reused in the L3-NM)

3/ Example A.1 invokes the vpn-instance-profile at the vpn-network-access level (as well as the node level). But the vpn-instance-profile in the example does not contain any parameters that pertain to a vpn-network-access. In any case, it would be good to have a revamped example to show how profiles defined or invoked at different levels interact with or override each other. For example, a situation in which the route-target is the same across all vpn-nodes, but each vpn-node has a unique route-distinguisher. Or a situation in which maximum-routes (among other parameters) is specified in a profile that is defined at the service level. That profile is invoked on all of the nodes, but the maximum-routes parameters is overridden on some nodes, at the node-level or at the vpn-network-access level. 

Finally, many thanks to the authors for this very comprehensive and valuable piece of work.

Julian