Re: Adoption call criteria for CRH? [was: Re: CRH and RH0]

[Robert Raszuk <[e-mail]>]

Hi Mark,

*Ad *A* & *B* *

No mapping is needed. And I am not talking about variable length IDs in
data plane either. I am talking about exact match locators only without any
mapping. All what is needed is described in our vSID draft. Just borrow
from it :)

Flexible and well thought through choice of encoding does not need to mean
complex data plane .. in fact quite the opposite.

*Ad *C* *

The fact that the problem is not new - does it make it acceptable to
produce more technology with the same problem ? Btw I had a offline chat
with Fred and I think we have an easy fix for it. In fact two cases of it.

*Ad *D* *

Very debatable. Also very much depends if you want segment endpoints to be
able to execute some additional instructions or just blindly forward. That
is one of the fundamental differences here from SRv6.

Not for me to argue either way - just making an observation. Also in all
use cases I see there is no "Complex packet handing" - just basic
forwarding even by encapsulated destination.

*Ad *E* *

Cool.

Rgs,
R.


On Mon, May 18, 2020 at 11:38 PM Mark Smith <[e-mail]> wrote:

> On Tue, 19 May 2020 at 00:42, Robert Raszuk <[e-mail]> wrote:
> >
> > Hi Tom,
> >
> > Well what I do not like about CRH is this:
> >
> > *A* Requirement for mapping of SIDs to IPv6 addresses - see the header
> may look simple in the draft as the does not talk about mapping. Handwaving
> of config by hand or controller I do not buy.
> >
>
> What is wrong with mapping?
>
> > *B* Two size will not fit all. Maybe if there is CRH type and we have
> 8,12, 16,24,32 bit SIDs it could be optimal for most deployments
> >
>
> Variable length identifiers in the forwarding plane has been tried
> multiple times in the past and abandoned. See RFD 675, Internet
> Engineering Note 21, etc.
>
> "There had been debates during the 1976
> year about address size and proposals ranged from 32 to 128 bit to
> variable length address structures. No convergence appeared and, as the
> program manager at DARPA, I felt it necessary to simply declare a
> choice. At the time (1977), it seemed to me wasteful to select 128 bits
> and variable length address structures led to a lot of processing
> overhead per packet to find the various fields of the IP packet format.
> So I chose 32 bits." - Vint Cerf -
> https://mailman.nanog.org/pipermail/nanog/2010-April/020488.html
>
>
> I would prefer CR had a singe size of 24 bits, as that would seem to
> me to be the Goldilocks size for local network use (16 million
> values), and per RFC 5505, "Anything that can be configured can be
> misconfigured.".
>
> However I don't know enough about ASICs to judge whether or not 24
> bits could be acceptably accommodated for all cases, so I accept 2
> sizes, 16 and 32 bits.
>
> > *C* No mention what happens when node in the SID list is down ... modern
> networks do not tolerate outages required to signal all the way to the
> ingress to redo computation and start repair from there. This is BAD
> NETWORK DESIGN.
> >
>
> This problem exists with any source routing, and has existed for many
> decades in IPv6, IPv4, MPLS and Token Ring source routing. ICMPv6,
> routing protocol signalling, BFD, etc. are all existing solutions to
> this problem.
>
> > *D* Separation of destination actions into Destination Options Header.
> For some it may be a plus - for me this is minus.
> >
>
> RFC8200 compliance.
>
> Separating hop-by-hop and destination option processing is good design
> because forwarding needs to be as simple and as fast as possible.
>
> Complex packet handling should be left to End-hosts because they're
> only performing actions for themselves, so the cost of complex
> processing is limited to the end-host that is exclusively benefiting
> from it.
>
> Complex packet handing in the network spreads the complexity costs to
> all end-hosts attached to the network, even those that don't and may
> never benefit from it.
>
> > *E* Unlike say SRH RFC this draft does not even mention once that to
> impose CRH packets should be encapsulated.
> >
>
> While I think it is implicit in RFC8200, it probably should be
> explicitly mentioned with a reference to RFC 2473, which shows how to
> add new information through EHs to an existing packet via tunnel
> encapsulation.
>
> Regards,
> Mark.
>
>
>