[Tsv-art] Re: draft-ietf-masque-connect-ethernet-12 telechat Tsvart review

[Alejandro Sedeño <[e-mail]>]

Hi Michael,

Thanks for the review. We discussed mentioning other Ethernet features in
the Working Group and the consensus was to declare them out of scope.
We prefer not to start writing an extensive list of these features.

Section 9.2 already mentions associating the frame with the appropriate
priority when reapplying 802.1Q tags.

-Alejandro


On Fri, Aug 14, 2026 at 12:20 PM Michael Scharf via Datatracker <
[e-mail]> wrote:

> Document: draft-ietf-masque-connect-ethernet
> Title: Proxying Ethernet Frames in HTTP
> Reviewer: Michael Scharf
> Review result: Ready with Issues
>
> 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
> [e-mail] 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
>
>
>