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
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
