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
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
