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

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

Hi Michael,

Regarding DISCUSS 1, how about adding a warning that advanced Ethernet
features requiring precision timing, constant bandwidth, or similar
constraints may not function as expected when proxied over a
congestion-controlled path? I would still prefer not to name such features,
since starting such a list invites adding to it.

Would mentioning that stripping and reapplying 802.1Q tags should only
occur if the PCP and DEI values are not being used, or if they can safely
be reapplied as constants, resolve DISCUSS 2 for you?

Thanks,
-Alejandro

On Sat, Aug 22, 2026 at 6:15 AM Scharf, Michael <
[e-mail]> wrote:

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