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

[Tom Herbert <[e-mail]>]

On Mon, May 18, 2020 at 2: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.
>
I know from a SW implementation POV it's generally best for fields to
be 2^n bytes in size and have natural alignment to that size (i.e.
offset % 2^n == 0). Fortunately, most IETF L3 and L4 protocols follow
these conventions. For completeness, and because we could encode ILA
or ILNP identifiers, it would be nice to have a 64-bit size also IMO.

> > *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.

Note this is implied in the term "source routing". It is only the
source node that can set a routing header. IP-IP encapsulation works
because the encapsulator is the source of the packet as far as the
network is concerned. The CRH protocol format is properly agnostic to
whether the header is being created at the original source or by some
node encapsulating the packet in flight. It might be worth mentioning
since it does seem like a pretty common use case.

Tom

>
> Regards,
> Mark.
>
>
> > Thx,
> > R.
> >
> > On Mon, May 18, 2020 at 4:26 PM Tom Herbert <[e-mail]> wrote:
> >>
> >>
> >>
> >> On Wed, May 13, 2020 at 1:12 PM Robert Raszuk <[e-mail]> wrote:
> >> >
> >> > John,
> >> >
> >> > May I add one more perspective to this.
> >> >
> >> > 6man just standardized SRH. Why SRH content can not be filled by controller and used for the very same purpose as authors intend to use CRH for ?
> >> >
> >> > Oh one may say there is no compression there ... If so I recommend to take a look at uSID and vSID proposals.
> >> >
> >> Hi Robert,
> >>
> >> I took a look at these proposals. It's very obvious that the format of CRH is significantly simpler than either of these and is simpler than SRH as well. Complexity in protocol format correlates to how amenable the protocol is to feaible implementation (in HW and SW), how well it can be secured, and how efficient in terms of wire overhead and processing overhead.
> >>
> >> It is interesting to note that figure Figure 3 in draft-decraene-spring-srv6-vlsid-03 would be identical to Figure 1 in draft-bonica-6man-comp-rtg-hdr-22 if the Last Entry, Flags, Tag, and TLVs fields were removed. Since these fields aren't used in the common case, they are easily compressed by simply removing them. So the material difference between the formats is how the length of SIDs is determined. In CRH this is explicit in the routing type, there is one type for 16-bit SID format and one type for 32-bit format.. AFAICT in vSID the SID length is more like a negotiated parameter that per destination address that uses the same routing type as SRH. While the vSID method might be more flexible and allow arbitrary SID lengths, it leads to more complexity since the routing header can no longer be parsed without external information. For instance, if a management device snoops packets in the path it wouldn't be able to parse the SID list without participating in the protocol that distributes the length information. Similarly, if a legacy SRH receiver receives a vSID header it seems like it would parse it incorrectly.
> >>
> >> In any case, I don't see why the vSID and CRH proposals couldn't be unified or why SR wouldn't be able to use CRH to convey compressed SIDs.
> >>
> >> Tom
> >>
> >> > Is it in good interest of anyone deploying segment routing to have to deal with N different non interoperable headers ? Does it make anyone's life easier ?
> >> >
> >> > Kind regards,
> >> > Robert.
> >> >
> >> > PS. So my own side observation lead me to believe it is not about "too early to ask for adoption" ... it is actually "way too late"
> >> >
> >> > On Wed, May 13, 2020 at 10:01 PM John Scudder <jgs=[e-mail]> wrote:
> >> >>
> >> >> I’m a little confused about this conversation and I’d like to ask the chairs for clarification. My actual questions are at the end of this long(ish) message, and can be summarized as (1) does 6man require consent from SPRING before defining routing headers, and (2) what criteria are the chairs using to decide when an adoption call is OK?
> >> >>
> >> >> It seems to me there are at least two, only vaguely related, conversations going on. One of them is a debate about the assertion that 6man can’t even consider taking up CRH unless SPRING approves it. The other is a more free-wheeling line of questioning about “what is CRH for anyway”?
> >> >>
> >> >> I presume both of these relate to Ron’s request for an adoption call. Here’s what the minutes from the interim have:
> >> >>
> >> >> > Bob: Thank you Ron. I think it's too early for adoption call.
> >> >> >
> >> >> > Ron: What is needed to get to adoption call.
> >> >> >
> >> >> > Bob: I can't answer right now.
> >> >> >
> >> >> > Ron: Can I ask on list?
> >> >> >
> >> >> > Bob: OK.
> >> >> >
> >> >> > Ole: Related to what's going on in spring.
> >> >>
> >> >> Too bad we have no audio recording, but that’s not too far from my recollection. Anyway, I don’t think I’ve seen this answered on list yet, so I’m asking again.
> >> >>
> >> >> Regarding the SPRING-related process stuff:
> >> >>
> >> >> I have quite a bit of history with how SPRING was chartered; I was one of the original co-chairs and helped write the charter, god help me. I can tell you for certain there was no intent that SPRING should have exclusive ownership of source routing in the IETF, the name isn’t a power-grab, it’s a clever backronym, as we do in the IETF. If one entity in the IETF were to take charge of all source routing, that sounds more like a new area than a WG. But don’t take my word for it, go read the various iterations of the charter. As anyone who’s looked at the Segment Routing document set can tell, Segment Routing is one, very specific, way of doing source routing. As Ketan and others have pointed out, it’s a pile of architecture plus the bits and pieces to instantiate that architecture. That is fine, but the idea that merely because a technology might be used to instantiate part of that architecture, it’s owned by SPRING, is overreach. Just because a sandwich is a filling between two pieces of starch, doesn’t mean every filling between two pieces of starch is a sandwich. [1]
> >> >>
> >> >> But at any rate, the question for the chairs is: do you think 6man needs SPRING’s permission in order to consider adopting CRH? Does 6man need permission from SPRING for all routing headers, or just some, and if it’s just some, what characterizes them?
> >> >>
> >> >> Regarding the more general “what is CRH for anyway” stuff:
> >> >>
> >> >> This seems to me to be exactly the kind of discussion one would normally have in the context of an adoption call. Why is it not being had in that context? To rewind back to the interim, if it’s still “too early for adoption call”, what has to happen for it not to be too early?
> >> >>
> >> >> Thanks,
> >> >>
> >> >> —John
> >> >>
> >> >> [1] https://cuberule.com
> >> >> --------------------------------------------------------------------
> >> >> IETF IPv6 working group mailing list
> >> >> [e-mail]
> >> >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >> >> --------------------------------------------------------------------
> >> >
> >> > --------------------------------------------------------------------
> >> > IETF IPv6 working group mailing list
> >> > [e-mail]
> >> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >> > --------------------------------------------------------------------
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------