Warren, other authors, Thank you for your thoughts.
&TL;DR I worry that you have selected the wrong design pattern as we are talking about *features* and not protocols.
Failing closed at the application and transport layers make a whole lot of sense, and that is why you get a "connection rejected" in TCP (there is a historical story about that for the (possibly virtual) bar if anyone would like to buy me a (possibly virtual) drink). This isn't possible in L3, which is why we are having the the discussion; and I do agree that this topic is worthy of a LOT of discussion, and maybe even some debate.
Were this a new version of IP or some new layer like MPLS, then an ethertype would seem appropriate. It's a very coarse mechanism to indicate either one supports a protocol or one does not.
But what is really at issue here amounts to selection of L3 *features*, and how we handle feature compatibility. Features by their nature can be used in combinatoric patterns. Using ethertypes for feature compatibility has some issues. If you want to use more than one feature, then you have the miserable choice of "tough noogies" or assigning a different ethertype for each feature combination.
Also, the draft needs to be more clear about its intent. Should we be expecting that packets transit the network without the ethertype changing or should we be thinking about domains a'la MPLS? Both have costs associated with them.
* In the case of a single ethertype across a path, we risk not only an explosion of ethertype allocations, but an explosion of end-to-end IPs; and that would be Very Bad. I don't think this is where you are going, but you should be explicit. * If the ethertype will be managed at the border level, we should expect misconfiguration to cause leakages from time to time, as happens, for instance, with BGP non-transitive attributes. Also, if a feature becomes dominant, I don't think you can expect it to remain off by default, especially if it does not require configuration. Let me stop there for now. Eliot On 18.10.2024 16:58, Warren Kumari wrote:
Hi there all,A few of us (Andrew Alston, Éric Vyncke, Suresh Krishnan, Donald Eastlake and myself) have been working on a mechanism to make "limited domains" protocols safe(r) to deploy.The 50,000ft [0] view is that fail-closed domains are inherently easier to protect than fail-open, and so the document provides some mechanisms which protocol designers can use to achieve this when designing new protocols.We'd really like some review and feedback: https://datatracker.ietf.org/doc/draft-wkumari-intarea-safe-limited-domains/What do you think of the approach? What do you think of the document? Is it clear and understandable? Does it help solve the issue(s)? etc…W[0]: AKA 15.24km for those who weird folk who enjoy complicating their lives by counting in tens instead of furlongs or shackles or shaftments or other simple systems like that._______________________________________________ Int-area mailing list --int-area@ietf.org To unsubscribe send an email toint-area-le...@ietf.org
OpenPGP_0x87B66B46D9D27A33.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ Int-area mailing list -- int-area@ietf.org To unsubscribe send an email to int-area-le...@ietf.org
