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

["Scharf, Michael" <[e-mail]>]

For what it is worth, it is correct that my example 2 (i.e., PCP value) is already mentioned in the document using the term “priority”; sorry, I missed that.

But I also mentioned the DEI value. I am not an IEEE terminology expert, but in Ethernet deployments I am familiar the term “priority” would typically refer to the up to 8 classes in the PCP value, and not the DEI value. So, I believe that the current text does not address at least this DEI aspect of example 2.

Of course, the more relevant TSV-ART aspect is the difficulty to realize a constant bandwidth over the tunnel (issue 1).

There are widely deployed “L2VPN“ solutions that (try to) offer a somewhat constant bandwidth over tunnels, e.g., by traffic engineering. Readers running into this draft with that “L2VPN” background may not immediately realize what it implies to communicate over a congestion-controlled tunnel.

Michael




Von: Gorry Fairhurst <[e-mail]>
Gesendet: Samstag, 22. August 2026 11:43
An: Alejandro Sedeño <[e-mail]>; Scharf, Michael <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]
Betreff: Re: draft-ietf-masque-connect-ethernet-12 telechat Tsvart review

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]<mailto:[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]<mailto:[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