[OPSAWG] Zaheduzzaman Sarker's Discuss on draft-ietf-opsawg-vpn-common-10: (with DISCUSS and COMMENT)

[Zaheduzzaman Sarker via Datatracker <[e-mail]>]

Zaheduzzaman Sarker has entered the following ballot position for
draft-ietf-opsawg-vpn-common-10: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-vpn-common/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I would like to discuss the extensibility of the model as described in section
3 regarding 'qos-classification-policy' when UDP is used as substrate. See more
in my comments bellow.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks to the authors for working on this specifications and addressing TSVART
review comments. Thanks Wesley Eddy for your TSVART reviews.

Comments -

* In this specification, UDP match criteria is described and claimed that the
model can be augmented to include more L4 transport protocols. QUIC (RFC9000)
is a new L4 transport protocol and uses UDP as substrate. For such L4 transport
protocols, it might be ambiguous to apply qos classification policy based on
what is defined here. In case of QUIC, it needs to identify from other UDP
traffic that is traversing the network. Read more on QUIC traffic
identification here (
https://quicwg.org/ops-drafts/draft-ietf-quic-manageability.html#name-identifying-quic-traffic).

I think this specification should consider such potential substrate usage of L4
protocols (specially UDP) and hint on the potential augmentations (there might
be several ways to do that) or scope it down to not support such cases.

* May be the commented text in the section 4 for protocol identifiers should be
updated to reflect what is describes in the section 3 for "underlay-transport".
Section 3 talks about underlay transports and how they are set.