Re: Size of CR in CRH

Bob Hinden <bob.hinden@gmail.com> Wed, 20 May 2020 16:46 UTC

Return-Path: <bob.hinden@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 656013A0C01 for <ipv6@ietfa.amsl.com>; Wed, 20 May 2020 09:46:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ds2HystMRzF7 for <ipv6@ietfa.amsl.com>; Wed, 20 May 2020 09:46:39 -0700 (PDT)
Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E0C53A0C00 for <6man@ietf.org>; Wed, 20 May 2020 09:46:39 -0700 (PDT)
Received: by mail-wr1-x42f.google.com with SMTP id l11so3898273wru.0 for <6man@ietf.org>; Wed, 20 May 2020 09:46:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=J80YaP4n2m/ph1tWjoQU/dngJBNbjWgFGwwq6y24Os8=; b=HqZ2zQI32ZLHQ9STW8dwPR9bJwdd3SkKWWfcxGxIpsqpUBAEnv6xxkGgAs794Dy0K9 MNNiG43u+cYZRrIdpXd9mr28UHnGihKZQj0T8P4XfCOnlpsbwG96q9w7i/AZdll4GD6L hHXmGI+Ocs84WGXHWFrzodeWIlY/n+2YK66li/A4exdpyuiE1ZZ6MCfY8JumSCL6FsYw W1cf+cgWKpuex0YdGKn7F6dpgZ9ypwT8TF3HSGr8Gbe3TFiY2lItC3y8xbefKBH5Cx/4 OGKPYSsJ3U5PwTSi7ZUdu94dZ9lhV2dOthJ2eohq6x4wSWq6AeVI6N9GdTaQkB9sospD Lh5w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=J80YaP4n2m/ph1tWjoQU/dngJBNbjWgFGwwq6y24Os8=; b=QeDJFHWqfVEOGPMokZhRn+T8UC+Dx429b7y6S1CMEIX9big2bNJYgCMSj/DdBwTg6Q yW9NA48oIBOsb6WtCxdc+ixriu95B9p632T5sFjKRcjSoPWd+N0gZ93goAz+s32K9dWJ XvBbgm+c4vgGKNbwzFvk5mcDpuIE5gr+PDmkjqgdIiBjVwhMR4ceoUXcbsiTBeDRsWbZ d8Dn00SW62SmYL7m2KNcqTgscE+BaSOKFlO/VsiV8pB04i6gkZcazNdW1VbwH4yHjT/n 8LEbR0PX6HrCM71uJpokij7xedvIi9TyW6R+9m/RSBODgi4qqm/2b1nP8/rX98sxXNac 46Vw==
X-Gm-Message-State: AOAM533arw8Mrivk10NAZHCHCdcOR2WT+5tKMoiyXG3htqjeBspLWn3C KWSK5ZviWWzhCsGZG9P5BJ0=
X-Google-Smtp-Source: ABdhPJzsKmBhh/245G0vgZPxjhJclMOltB8HHwwSv/koD7Qqm9rYb37+7z6X8duNaZlJY9F6FAGM5A==
X-Received: by 2002:a5d:4d89:: with SMTP id b9mr5257507wru.210.1589993197552; Wed, 20 May 2020 09:46:37 -0700 (PDT)
Received: from ?IPv6:2601:647:5a00:ef0b:8d90:8dc6:e6d7:49ac? ([2601:647:5a00:ef0b:8d90:8dc6:e6d7:49ac]) by smtp.gmail.com with ESMTPSA id w20sm3565023wmk.25.2020.05.20.09.46.34 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 May 2020 09:46:36 -0700 (PDT)
From: Bob Hinden <bob.hinden@gmail.com>
Message-Id: <EA0BCB8D-C328-471E-A824-320A6A1C39B8@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_6EC5D833-0846-4C27-9B56-7921A839B570"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\))
Subject: Re: Size of CR in CRH
Date: Wed, 20 May 2020 09:46:29 -0700
In-Reply-To: <DM6PR05MB6348EC9394082D410E3BAB1CAEB60@DM6PR05MB6348.namprd05.prod.outlook.com>
Cc: Bob Hinden <bob.hinden@gmail.com>, Nick Hilliard <nick@foobar.org>, 6man <6man@ietf.org>
To: Ron Bonica <rbonica@juniper.net>
References: <DM6PR05MB6348E9AD1E088792C2F10BB4AEBF0@DM6PR05MB6348.namprd05.prod.outlook.com> <8CC3F837-B4D6-4570-AF2F-37041839F391@employees.org> <21E9A957-1A31-4A11-8E78-5F7E382866D4@juniper.net> <CAOj+MMEONA5OtWz9Y7pTt4WyVsb+7-_wEKPVryyHLncHG6ew6g@mail.gmail.com> <CALx6S35fPrnh6UtpPYmQ6Yew6D2QVMvYTdp0AaGr8jYhGNKk3A@mail.gmail.com> <CAOj+MMH0Q6ASmjPdmgNB2LHDhvCL2u2DLB9SBRLnJnCD3EbA4w@mail.gmail.com> <CAO42Z2wke4Lw44zdE0G9CJq3rXh69jsxjO5=RTcCv9EXdNOp5A@mail.gmail.com> <BC6A6354-BAB5-4CE0-ABEB-73B4C88E149A@gmail.com> <a8220864-302a-3698-c61d-abb7926482fa@foobar.org> <DM6PR05MB6348945F596A016E6F11856EAEB90@DM6PR05MB6348.namprd05.prod.outlook.com> <19E3F1AE-904C-49DC-B528-B1025A1454F0@gmail.com> <DM6PR05MB6348EC9394082D410E3BAB1CAEB60@DM6PR05MB6348.namprd05.prod.outlook.com>
X-Mailer: Apple Mail (2.3445.104.14)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/g-euF3bQ2ugiXT74i_SeNd0JMIc>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 May 2020 16:46:41 -0000

Ron,

Thanks, this is helpful.  Comments inline.

Bob


> On May 20, 2020, at 9:03 AM, Ron Bonica <rbonica@juniper.net> 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 <bob.hinden@gmail.com>
> Sent: Tuesday, May 19, 2020 11:05 PM
> To: Ron Bonica <rbonica@juniper.net>
> Cc: Bob Hinden <bob.hinden@gmail.com>; Nick Hilliard <nick@foobar.org>; 6man <6man@ietf.org>
> Subject: Re: Size of CR in CRH
> 
> Ron,
> 
> A few comments inline.
> 
>> On May 19, 2020, at 11:01 AM, Ron Bonica <rbonica@juniper.net> 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 <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_3aSjRJL
>> LRAZuRumqRr$
>> --------------------------------------------------------------------