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

[Gorry Fairhurst <[e-mail]>]

On 17/08/2026 17:43, Alejandro Sedeño wrote:
> 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

Alejandro,

Thank you for your efforts that bring this to conclusion. I understand 
that the consensus was to produce just a frame transport and not a full 
LAN emulation, so I wouldn't expect more text to explain how to perform 
LAN emulation.

For what it is worth, I do think the language used by Michael were a 
shade more detailed and useful than my own comments, and if it's 
possible to update the wording slightly to expose the nuances  from the 
review, I do think this would be well worth a revision. For example: 
Noting PTP (TSN is important to some application scenarios!) and Q-in-Q 
(another niche scnario beyond Q) would alert people to think a little 
more before they simply try to hack solutions.

If you'd like, I can offere a PR based on this review. If not, that's 
also OK.

Just let me know (this email was purposely not sent to the list, to let 
you reply as best you think).

Gorry

>
>
> 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
>
>