Re: Size of CR in CRH

[Fred Baker <[e-mail]>]

Speaking strictly for myself...

This is a question:

What is the probability of needing 65536 code points, 131072 code points, etc, etc?

Could the problem of N*0x0ffff code points be addressed by allocating N code points, each of which has 0xFFFF minor code points? Issues include operational overhead and a variety of other things. Note that the usual argument for large prefixes and large numeric groups tend to mention operational overhead.

Discuss...

> On May 20, 2020, at 2:24 PM, Mark Smith <[e-mail]> wrote:
> 
> Hi Ron,
> 
> On Thu, 21 May 2020 at 04:41, Ron Bonica
> <rbonica=[e-mail]> wrote:
>> 
>> Bob,
>> 
>> First, let's agree that the problem with having two CRH versions:
>> 
>> - is complexity
>> - is not code point consumption
>> 
> 
> There's an operational issue with having two or more sizes, which is
> the risk and possible future consequences of choosing the small size
> when you might need the or a larger size in the future.
> 
> To change any significant production network from one size to another
> is going to involve a lot of planning, may involve disrupting
> customers' services, and is likely to involve a lot of out of hours
> work. (I like to think of out of hours work as 10 times harder than
> in-hours work, so my view is to try to avoid incurring out of hours
> work unless there is no other choice.)
> 
> In this case of 16 bit verses 32 bits, it sounds like the main cost of
> choosing 32 bits will be in ASICs that support them.
> 
> So for an operator, it sounds like a choice between writing a bigger
> cheque today to buy bigger ASICs, or the possibility of still having
> to buy bigger ASICs later (granted, likely cheaper due to natural
> scales of economy) and then getting less sleep, disrupting customers
> etc. to put the new ASIC equipment in.
> 
> I think operators are used to writing pretty big upfront cheques for
> equipment, because they're used to buying extra equipment and links
> for redundancy, just in case of failures.
> 
> Note that I'm not arguing specifically for 32 bits here, just that if
> there is a choice between a variety of sizes, the largest choice is
> normally the least risky operational choice.
> 
> A single single size would be better operationally, as long as that
> single size is large enough to cover most use cases. Other special
> cases that can't be accommodated sound like they need their own
> special and different solution.
> 
> Regards,
> Mark.
> 
> 
> 
> 
> 
> 
> 
> 
>> Given that agreement, we look for ways to reduce complexity. Options are:
>> 
>> - find ways to reduce complexity while retaining two CRH versions
>> - drop one CRH version
>> 
>> The following are ways to reduce complexity while retaining two CRH versions:
>> 
>> - Recommend that operators run one CRH version or the other, but not both, except during transition periods
>> - Facilitate transition by making the 16-bit identifier, with value N, reference the same CRH-FIB entry as the 32-bit identifier that also has value N.
>> 
>> And, of course, we could drop the CRH-32, at least for the time being. But I don't think that this is the right decision because we have heard three arguments for CRH 32, with these being:
>> 
>> - the O-RAN argument (presented by me)
>> - the Data Center Underlay argument (presented by Uma)
>> - the sparsely populated identifier argument (presented by Andrew).
>> 
>> While the O-RAN argument may be speculative, the other two are not.
>> 
>>                                                                                                Ron
>> 
>> 
>> Juniper Business Use Only
>> 
>> -----Original Message-----
>> From: Bob Hinden <[e-mail]>
>> Sent: Wednesday, May 20, 2020 12:46 PM
>> To: Ron Bonica <[e-mail]>
>> Cc: Bob Hinden <[e-mail]>; Nick Hilliard <[e-mail]>; 6man <[e-mail]>
>> Subject: Re: Size of CR in CRH
>> 
>> Ron,
>> 
>> Thanks, this is helpful.  Comments inline.
>> 
>> Bob
>> 
>> 
>>> On May 20, 2020, at 9:03 AM, Ron Bonica <[e-mail]> wrote:
>>> 
>>> Hi Bob,
>>> 
>>> AFAICS, a 16-bit identifier is good enough for any network that exists today. And until very recently, I believed that a 16-bit identifier was good enough for any network that might exist for many years to come.
>> 
>> Good
>> 
>>> 
>>> However, 5G may change all of that. The promise of 5G is high data rates from the user-device to the cell tower. In order to achieve these high data rates, the user-device and cell tower communicate with one another over extremely high radio frequencies. These extremely high radio frequencies do not propagate well over long distances. So, there will be *many* cell towers.
>>> 
>> 
>> I understand that part of 5G.
>> 
>>> The O-RAN Alliance is exploring transport architectures in which each cell tower hosts a Cell Site Router (CSR) and each CSR can be the endpoint of a traffic engineered path. In that architecture, a 32-bit CR may be required, because there may be as many as 1,000,000 CSRs.
>>> 
>>> Yes, this is a bit speculative. But it may happen.
>> 
>> CRH could start with a 16-bit identifier.   Once the O-RAN work is further along, a new routing header with 32-bit identifiers could be developed if needed.   As you said, there isn’t a shortage of routing header types and would make the specification and implementations simpler.
>> 
>>> 
>>> This is the motivation for having two sizes. We don't want to deprive existing networks of optimal compression because of future speculation. But we don't want to close the door on 5G support, either.
>>> 
>>> 
>>> Ron
>>> 
>>> P.S. ASICs can generally handle 16, 24 and 32 bit CRs. However, some are more efficient when word-alignment is maintained. This makes 16 and 32 more desirable.
>>> 
>>> 
>>> 
>>> Juniper Business Use Only
>>> 
>>> -----Original Message-----
>>> From: Bob Hinden <[e-mail]>
>>> Sent: Tuesday, May 19, 2020 11:05 PM
>>> To: Ron Bonica <[e-mail]>
>>> Cc: Bob Hinden <[e-mail]>; Nick Hilliard
>>> <[e-mail]>; 6man <[e-mail]>
>>> Subject: Re: Size of CR in CRH
>>> 
>>> Ron,
>>> 
>>> A few comments inline.
>>> 
>>>> On May 19, 2020, at 11:01 AM, Ron Bonica <[e-mail]> wrote:
>>>> 
>>>> 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.
>>> 
>>> Are there any networks today where 16 bits is too small?
>>> 
>>>>     - 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.
>>> 
>>> This seems pretty speculative to me.  Do you have any justification for this?   Is there a 5G document that discusses this?
>>> 
>>> This is also assuming that each router needs to be identified uniquely and that every router on a path needs to be in the source route.  How long will each path be.   Source routing won’t scale well with large numbers of hops regardless of the size identifier.
>>> 
>>> 
>>>>     - 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.
>>> 
>>> s/too short for some networks/too short for some future networks/  ??   Are there any today, even close?
>>> 
>>>> A 24-bit identifier may be difficult for some ASICs to process. A 32-bit identifier gives suboptimal compression for all existing networks.
>>> 
>>> So I assume that ASICs can’t process a 32-bit identifier either?
>>> 
>>>> 
>>>> 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).
>>> 
>>> I don’t think the availability of router header types is a good justification for two headers.
>>> 
>>> Having two headers now adds complexity given what I think I am hearing that there isn’t a need for a bigger identifier for long time in the future.
>>> 
>>> Bob
>>> 
>>>> 
>>>> So, allocating two Routing types may be the best solution.
>>>> 
>>>> 
>>>> Ron
>>>> 
>>>> 
>>>> 
>>>> Juniper Business Use Only
>>>> 
>>>> -----Original Message-----
>>>> From: ipv6 <[e-mail]> On Behalf Of Nick Hilliard
>>>> Sent: Tuesday, May 19, 2020 1:13 PM
>>>> To: Bob Hinden <[e-mail]>
>>>> Cc: 6man <[e-mail]>
>>>> 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
>>>> [e-mail]
>>>> Administrative Requests:
>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv
>>>> 6
>>>> __;!!NEt6yMaO-gk!UCWrvkvflbEehBiEIA8M4PHGA_mrvC0MLpZly-euihAg3_3aSjRJ
>>>> L
>>>> LRAZuRumqRr$
>>>> --------------------------------------------------------------------
>> --------------------------------------------------------------------
>> 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
> --------------------------------------------------------------------