search

ietf-wg-masque / draft-ietf-masque-connect-ethernet

MASQUE for Ethernet
Other
3 stars 2 forks source link

Special consideration for Ethernet PAUSE frames #7

Closed asedeno closed 2 months ago

asedeno commented 7 months ago

More from PWE3:

https://www.rfc-editor.org/rfc/rfc4448.html#section-4.4.5

In a standard Ethernet network, the flow control mechanism is optional and typically configured between the two nodes on a point-to-point link (e.g., between the CE and the PE). IEEE 802.3x PAUSE frames MUST NOT be carried across the PW. See Appendix A for notes on CE-PE flow control.

https://www.rfc-editor.org/rfc/rfc4448.html#appendix-A.2 has the specific notes on PAUSE frame.

This does not seem common anymore. We probably still don't want to proxy it. Otherwise emitting or reacting to PAUSE frames do not appear to be in scope for this draft.

achernya commented 7 months ago

I think we should not respect PAUSE frames. That can be left to a future extension if we can define a semantic that makes sense. (PAUSE frames can result in DoS if used incorrectly)

mirjak commented 2 months ago

In the draft we say:

This document defines a tunnelling mechanism that is conceptually an Ethernet link. Implementations might need to handle some of the responsibilities of an Ethernet switch or bridge if they do not delegate them to another implementation such as a kernel. Those responsibilities are beyond the scope of this document

I think his includes also any handling of PAUSE frames. In other words proxy may decide to forward or not forward a PAUSE frame but it's independent of connect-ethernet functionality to decided that.

The only thing we could do is to explicitly name the PAUSE as an example for frames that could be considered. However, currently the document as no dependency on the content of the ethernet frames that being proxies and I think it would be important to keep it that way. That's actually also something we could explicitly mention.