Re: Size of CR in CRH

[Tom Herbert <[e-mail]>]

On Wed, May 20, 2020 at 12:08 PM Ron Bonica <[e-mail]> wrote:
>
> Tom,
>
> I am happy too add a third size if there is WG consensus.
>
The primary question is probably should there be just one size, or can
there be more than one size (i.e. a choice between 1 an N :-))

Tom

>                                         Ron
>
>
>
> Juniper Business Use Only
>
> -----Original Message-----
> From: Tom Herbert <[e-mail]>
> Sent: Wednesday, May 20, 2020 3:07 PM
> To: Ron Bonica <[e-mail]>
> Cc: Bob Hinden <[e-mail]>; 6man <[e-mail]>
> Subject: Re: Size of CR in CRH
>
> [External Email. Be cautious of content]
>
>
> On Wed, May 20, 2020 at 11:41 AM 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
> >
> Ron and Bob,
>
> There's an obvious tradeoff here between flexibility and complexity. I won't speak for HW implementations, but in a SW datapath implementations the additional complexity to support different sizes is relatively slight as long as possible sizes are 2^n, properly alignment is maintained, there's no additional fields in the header other than the array, and the values are considered compressed versions of the largest possible identifier (for example, if 16 bit SIDs are sent these can be expanded to 32 bits be prepending zeros).
> This way, the same code can be used where it's parameterized by various sizes. From this perspective, I wouldn't mind if there were three sizes defined: 16, 32, and 64.
>
> Tom
>
> > 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/i
> > >> pv
> > >> 6
> > >> __;!!NEt6yMaO-gk!UCWrvkvflbEehBiEIA8M4PHGA_mrvC0MLpZly-euihAg3_3aSj
> > >> RJ
> > >> L
> > >> LRAZuRumqRr$
> > >> -------------------------------------------------------------------
> > >> -
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests:
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6
> > __;!!NEt6yMaO-gk!TtOuL3q5ftCTzcAo80NSzIprzqZfGflXimd_USkIaN33XGY6s85mv
> > ylu_NBKRGb8$
> > --------------------------------------------------------------------