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

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

Hi Gorry,

Sure, I would welcome a PR.

-Alejandro

On Sat, Aug 22, 2026 at 5:43 AM Gorry Fairhurst <[e-mail]>
wrote:

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