Re: [spring] Long-standing practice of due-diligence is expected - Re: CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?

[Robert Raszuk <[e-mail]>]

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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spring
>