> And this is an important difference: some of us don't want > encapsulation/tunneling, we want something that can be part of a > non-encapsulated packet. There are use-cases where CRH used with > encapsulating is the best solution, and there are cases where the packet > itself can be steered without encapsulation. CRH allows both, and therefore > covers more possible use-cases than RFC8663. This makes CRH a building block > that some of us desire.
PS: any IPv6 extension header can be replaced with one or more encapsulations. Even SRv6 can be implemented by encapsulating the packet separately for every segment, like the TOR network does. I don't buy the "you can already do this with encapsulation" argument. If that would become a valid argument then IPv6 innovation is dead. Cheers, Sander
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
