Re: Size of CR in CRH

[Tom Herbert <[e-mail]>]

On Tue, May 19, 2020 at 7:23 AM Templin (US), Fred L
<[e-mail]> wrote:
>
> 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.
>
Another possibility is identifier/locator split. For instance, all the
physical devices in many networks are assigned their own /64. In such
cases the routing header can just carry 64 bit locators and no special
mapping or control plane other than standard routing is needed.

Tom
> 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
> > >>>> --------------------------------------------------------------------
> > >
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------