Hi Joel On 19.10.2024 22:58, Joel Halpern wrote:
I am not sure Iunderstand Eliot's disagreement. Or Brian's. While the cases you were envisioning when the term was first coined may have been pure L3, the practical requirements operators have articulated is explicitly to be able to fail closed, to avoid accidentally allowing limited domain protocols into their operating domain. Whether you call that L2.5 (MPLS) or L3 (SRv6) the need doesn't change.
My point is not that I object to "fail closed' in principle, but (a) it would be better to have a more detailed threat model so that it is clear what is being defended against, and (b) that the proposed means to do so may not scale to other innovations in L3. Now maybe we can balance that with the idea that there should not be too many innovations at L3, I suppose, but we think should happen and what actually happens may diverge.
I also worry that we are trying to legislate a defense against "evil bits". Regardless of whether a protocol feature makes use of a new ethertype, providers still have to defend against garbage being thrown at them by neighbors.
Finally were we to apply this logic above L3 to IANA port allocations, and someone wanted to request a new port for a new protocol feature, we'd tell them to jump in a lake. Especially with a 16 bit field.
Eliot
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
