Hi, All fine and your use case is valid. I never said it is not.
* But first it makes all those claims that solutions under discussion are not to be used in Internet moot. * Second you can use subset of SRH just fitted to your need end to end without any encapsulation * Last if I were you I would just use RbR idea I proposed and move on :) Honestly since it uses plain old IPv6 FIB with just a little cli you could find it actually may work fine on shipping hardware already. Is there anything better then to meet your functionality without rolling in new features and software ? Moreover make it work across any vendor and across Internet ? Beats me why you guys keep arguing for pushing CRH. Many thx, Robert. On Thu, May 28, 2020 at 4:58 PM Sander Steffann <[email protected]> wrote: > Hi Robert, > > > There can be a lot of acronymous or names invented but under the hood it > 16, 32 or 20 bit opaque bit string in both CRH and SR-MPLS which is mapped > to a rewrite string. No more no less. > > So far so good > > > And rfc8663 precisely automated such rewrite to UDP encapsulation. > > 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. > > Cheers, > Sander > > _______________________________________________ > spring mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/spring >
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
