RE: Size of CR in CRH

["Templin (US), Fred L" <[e-mail]>]

Bob, my estimate of scale may have been a bit overblown; there are only 7 billion
people on the planet so "countless billions" of routers may still be a long way off.
That said, about a routing protocol I believe we can get what we need out of
standard BGP as long as the routers don't move around very much.

Thanks - Fred

> -----Original Message-----
> From: Bob Hinden [mailto:[e-mail]]
> Sent: Monday, May 18, 2020 10:47 PM
> To: Templin (US), Fred L <[e-mail]>
> Cc: Bob Hinden <[e-mail]>; Mark Smith <[e-mail]>; 6man <[e-mail]>
> Subject: Re: Size of CR in CRH
> 
> Fred,
> 
> > On May 18, 2020, at 8:53 PM, Templin (US), Fred L <[e-mail]> wrote:
> >
> > Bob, I am interested in environments where there are potentially countless billions of
> > routers. The mobile host is a 20th century archetype; the archetype for the 21st century
> > is mobile *routers*. And yes, these can show up as hops in a source route.
> 
> I think source routes will be the least of your problem with this.   For example, designing a routing protocol to work at this scale will be
> a problem.
> 
> Bob
> 
> 
> >
> > Thanks - Fred
> >
> >> -----Original Message-----
> >> From: ipv6 [mailto:[e-mail]] On Behalf Of Bob Hinden
> >> Sent: Monday, May 18, 2020 4:08 PM
> >> To: Mark Smith <[e-mail]>
> >> Cc: 6man <[e-mail]>; Bob Hinden <[e-mail]>
> >> Subject: Size of CR in CRH
> >>
> >> [Was Adoption call criteria for CRH? [was: Re: CRH and RH0] ]
> >>
> >> Hi,
> >>
> >> With no hats on:
> >>
> >>> On May 18, 2020, at 2:37 PM, Mark Smith <[e-mail]> wrote:
> >>> 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 also prefer a single size (and only one SR header definition).   If it’s 16-bits, that would allow 64K routers in one CRH domain
> assuming
> >> it needs to uniquely identify each router, if there is more than 64K routers, then it only needs to identify the routers that are
> serving
> >> as hops in the source route.
> >>
> >> As you note 24 bits is better, but may not align as well.   Or then 32-bits.
> >>
> >> Bob
> >>
> >>
> >>>
> >>>> *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.
> >>>
> >>>
> >>>> 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
> >>>> --------------------------------------------------------------------
> >