Telechat Review of draft-ietf-masque-connect-ethernet-12
review-ietf-masque-connect-ethernet-12-tsvart-telechat-scharf-2026-08-14-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 defines a mechanism to tunnel Ethenet frames over HTTP and
basically allows building a simple Layer 2 VPN (L2VPN).

The document is well-written. Relevant transport protocol interactions such as
multiple competing congestion control loops and/or multiple error recovery
mechanisms are sufficiently addressed in the document.

The document also addresses MTU issues. The document does not specifically
discuss Ethernet Jumbo frames, but this may be OK for a non-standard Ethernet
frame format.

Yet, it is a bit surprising that the document does not discuss how the HTTP
encapsulation of Etherrnet frames interacts with quite a number of widely used
Ethernet switch mechanisms. As far as I can see, the document basically assumes
that the HTTP proxy has features typical for unmanaged Ethernet switches or
simple managed switches, e.g., typical SOHO Ethernet deployments.

But there are many other Ethernet features. Here are some examples of more
advanced Ethernet features:

1. Precision Time Protocol (PTP) support (e.g., IEEE 1588, IEEE 802.1AS, or
Ethernet TSN features)

2. Use of the Priority Code Point (PCP) in the VLAN tag

3. Multiple VLAN tags or Q-in-Q, i.e., IEEE 802.1Q Tunneling

... (there is really _a lot_ more in specific use cases of Ethernet)

Other examples have already been mentioned e.g. in the RTG area review, most
notably MACsec (IEEE 802.1AE). I believe that Link Layer Discovery Protocol
(LLDP) topology discovery is also quite widely supported in modern switches. In
special environments (e.g., Datacenter networks, Carrier/Metro Ethernet,
Industrial Ethernet, Automotive Ethernet, Audio/Video Systems, ...), many
further Ethernet features exist, possibly even defined outside IEEE.

According to Section 7, Ethernet switch or bridge functions are outside the
scope of the document. There is some discussion on STP/RSTP in that section,
but it is unclear why the discussion is limited only to loop prevention.

I believe the document could spell out much more explicitly that without proper
implementation in the HTTP proxy, well-known Ethernet mechanisms may not work
over the tunnel as expected, or may require additional mechanisms and/or
protocol extensions beyond what is specified in the document.

1. For instance, the document could add warning signs that sending Ethernet
frames over a congestion-controlled tunnel could significantly affect the
accuracy of PTP time synchronization, and it may affect other Ethernet features
that basically assume running over an Ethernet link with constant bandwidth,
e.g., Ethernet TSN.

2. In the discussion of stripping the VLAN tag in Section 9.2, it could be
mentioned that also a PCP value (and maybe even the DEI flag) could have to be
reconstructed as well.

3. The document could spell out that Q-in-Q encapsulation is not considered
when discussing VLANs.

etc.

I assume that other IETF contributors are more familiar with L2VPNs and
advanced Ethernet features than myself, and they could add details, or correct
me. Some RFCs related to other L2VPN solutions (e.g., RFC 9291) also provide
quite a bit of background material.

This is basically all about more precisely specifying what is _not_ in scope of
the document, possibly unlike in other L2VPN services. As far as I can see, the
defined protocol does not need to be modified for a simple L2VPN service for
SOHO deployments or the like.

Michael