Last Call Review of draft-ietf-opsawg-vpn-common-09
review-ietf-opsawg-vpn-common-09-tsvart-lc-eddy-2021-07-30-00

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-art@ietf.org if you reply to or forward this review.

This document basically looks good to me, though I have a small number of
comments:

(1) I think this comment impacts only the narrative and not the YANG model
itself.  The list of possible underlay-transport values seems to be a mixture
of expected types of encapsulations, but then a couple of things at the end
that are signaling and not encapsulations per-se.  The last 2 entries in the
list on page 6 are what seem out of place to me - RSVP and BGP.  I don't think
it's quite correct to refer to these two as the underlay-transport.

(2) This is a YANG model question, that I'm unsure of.  I want to make sure
that in the match-type when match-flow is used that a combination of L3 and L4
attributes can be used.  It appears like either L3 or L4 can be indicated,
mutually exclusive, but I don't quite understand how it would then be possible
to properly represent the combination of IP, transport protocol, and ports that
identify a flow.  It seems like a list of criteria from both L3 and L4
components is what's needed to express a flow, rather than a choice of L3 or L4.