RE: Size of CR in CRH

Ron, thanks for this explanation and you are certainly welcome to proceed as you are
doing. As you note, there are plenty of Routing header type values available and you
should be able to claim two of them. That will still leave plenty left over for me to claim
one of my own.

Thanks - Fred

> -----Original Message-----
> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Ron Bonica
> Sent: Tuesday, May 19, 2020 11:02 AM
> To: Nick Hilliard <nick@foobar.org>; Bob Hinden <bob.hinden@gmail.com>
> Cc: 6man <6man@ietf.org>
> Subject: RE: Size of CR in CRH
> 
> Hi Nick, Bob and Fred
> 
> The following factors figured into the decision to specify 2 Routing types, one with a 16-bit identifier and the other with a 32-bit
> identifier:
> 
> 	- Today, very few networks contain more than 65,000 routers. So, most networks could obtain best compression with a 16-bit
> identifier.
> 	- When 5G is deployed, we may see networks that contain more than 65,000 Cell Site Routers. These networks will need an
> identifier that is wider than 16 bits.
> 	- It is unlikely that we will ever see a network that contains more than 4,000,000 routers. So, we will never need an identifier
> that is wider than 32 bits.
> 
> If Routing header types were in short supply, and only one were available to us, we would have to do one of the following:
> 
> 	- Select a single length (16, 24 or 32 bits)
> 	- Use the fifth byte of the Routing header to indicate the identifier length.
> 
> The first option isn't very appealing. A 16-bit identifier is too short for some networks. A 24-bit identifier may be difficult for some
> ASICs to process. A 32-bit identifier gives suboptimal compression for all existing networks.
> 
> The second option isn't very appealing either. If we use the fifth byte to indicate the identifier length, and we want the first identifier
> to begin on a 32-bit boundary, the next 24 bits would be wasted.
> 
> Fortunately, Routing header types are not in short supply. The Routing Type registry has room for 255 entries. Since it was established
> 25 years ago, only 6 types have been allocated. Of those, two have been deprecated (RH0 and Nimrod) and two are for special use
> (Experiment 1 and Experiment 2).
> 
> So, allocating two Routing types may be the best solution.
> 
>                                                                         Ron
> 
> 
> 
> Juniper Business Use Only
> 
> -----Original Message-----
> From: ipv6 <ipv6-bounces@ietf.org> On Behalf Of Nick Hilliard
> Sent: Tuesday, May 19, 2020 1:13 PM
> To: Bob Hinden <bob.hinden@gmail.com>
> Cc: 6man <6man@ietf.org>
> Subject: Re: Size of CR in CRH
> 
> [External Email. Be cautious of content]
> 
> 
> Bob Hinden wrote on 19/05/2020 00:08:
> > 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.
> 
> Having multiple options for SID size increases complexity at several
> levels: hardware programming, CLI, network compatibility, troubleshooting, etc.  What happens if a network wants to change from
> using one type of SID to another because of whatever reason?  Does a node need to be configured with multiple IDs?  Can you mix
> and match?
> These sorts of things matter when you run networks.  You're increasing the complexity of some aspects by a factor of two.
> 
> Simplicity is a huge gain from an operational point of view.
> 
> 32 bits has the advantage of being the same size as a node's bgp or ospf router-id.  This would be something ranging from helpful to
> important if the device has an option for manual programming.
> 
> The EH packet header lookup size of a device obviously impacts this.
> 
> Nick
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-
> gk!UCWrvkvflbEehBiEIA8M4PHGA_mrvC0MLpZly-euihAg3_3aSjRJLLRAZuRumqRr$
> --------------------------------------------------------------------
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------