Re: Size of CR in CRH

Uma Chunduri <umac.ietf@gmail.com> Wed, 20 May 2020 17:05 UTC

Return-Path: <umac.ietf@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 7C0C93A0AA6 for <ipv6@ietfa.amsl.com>; Wed, 20 May 2020 10:05:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=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 N3BLwMI--oIH for <ipv6@ietfa.amsl.com>; Wed, 20 May 2020 10:05:33 -0700 (PDT)
Received: from mail-vs1-xe31.google.com (mail-vs1-xe31.google.com [IPv6:2607:f8b0:4864:20::e31]) (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 94EA93A0A3D for <6man@ietf.org>; Wed, 20 May 2020 10:05:33 -0700 (PDT)
Received: by mail-vs1-xe31.google.com with SMTP id w65so2237762vsw.11 for <6man@ietf.org>; Wed, 20 May 2020 10:05:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VLr6TXcbyudm1eRvVv/qVhiGzXB3vsOIavsdkkHfR4s=; b=nxB2b9rbDQzOOGkPxiY613GWPJtEz8lgvCOkB5B8FAFhudiTilWnDSNZIkwk/YOtu+ yNFpntzNtTN8X3tpNMYWFMu5rTrxMVxGCfRoSXibsOjsxDEzSopbL05GduvE4087Wg02 RYKDKjsN/uAQbMGmy7P76wVCHKIldmARLCQDgd41pD3GVNfhEuML1M23EkpwH+/X+v6O xVy0kCCKFYyYmb9bTwjr2B7WjwS44GQHGMLwSjiDT6OuA7AfbhuxITIRSjFuxwvm43il 52jbbX5hBTWwq3U52N/CGXbSQBs1e4/wJ/MRaIVyGrRUsU2GD3sKqWLGWKNRRFywtEN3 eryA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VLr6TXcbyudm1eRvVv/qVhiGzXB3vsOIavsdkkHfR4s=; b=P2Si+q0lBBXCqh5A90onGD4RMg1IybzZTT3jts+dsj7rmwEt3gKtjR6solLBvHYH9h WyX7uuWYnihjlsSCB3mfLkLTKAxbMAwxlSKuE9X9/oKJON5AQ5IrQlsHBnXhQ5Vcl8WH CsmG0DAJwxGu1M8dK+b2DP5DFyR1jhkKKRHzgG0Fxg+jfJZ8EpVOMyYLwpPhJYSQZ378 7+wQ1ndYx9Q8rH8K2Y1SjXPoAnZdWmlehji2bp0+5U0UyNzxLXMH413D14zqKIgKvkA8 OaJabBZmayfgH1cDW/W6VPeSr8qHowmegxHjzybh201qZMEjTtgnl1Y9NwhoCmBRSdmI 0Www==
X-Gm-Message-State: AOAM531c/1S8Q6oQDVkuyoW1dbXpb2SpL83vtpe0SQYzfx5bEBZhhNIj Tz639NmxgsvUkXIegaz1J31w34meWq/KqfHcg1E=
X-Google-Smtp-Source: ABdhPJya5DPMOdSrw2xblbWdAg7u+eNCaeRiYSochHVanVSWsph6ysQqHbRRYKd5PExIRhlejXZ0AiSgOtAmiR6i39k=
X-Received: by 2002:a67:edce:: with SMTP id e14mr4065299vsp.235.1589994332462; Wed, 20 May 2020 10:05:32 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <DM6PR05MB6348EC9394082D410E3BAB1CAEB60@DM6PR05MB6348.namprd05.prod.outlook.com>
From: Uma Chunduri <umac.ietf@gmail.com>
Date: Wed, 20 May 2020 10:05:33 -0700
Message-ID: <CAF18ct5Tpz5uPr+K_miWyvN+v58v7bCss1BQ+L475JHWY1+V_g@mail.gmail.com>
Subject: Re: Size of CR in CRH
To: Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>
Cc: Bob Hinden <bob.hinden@gmail.com>, 6man <6man@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000061a32005a617676e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/h5cZelpXE7xkdNBCl-bPfZ0-geQ>
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 17:05:36 -0000

Hi Ron,

One quick comment below [Uma]. Apologies, if I interfere between you and
Bob.

--
Uma C.

On Wed, May 20, 2020 at 9:04 AM Ron Bonica <rbonica=
40juniper.net@dmarc.ietf.org> 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.



[Uma]: We all know a typical big SP network (1000 to 2000 nodes) size. If
you take a DC underlay the number is much higher. This is the reason

MSDCs started their journey to BGP only underlay (by giving up fast
convergence and FRR properties). We can all see LSR WG is working  to fix

this to address that space.

So, yes 16 bit identifiers would be  limiting in that case. However in
earlier discussions, some body questioned me what's the use of TE in DC

underalay.  So this leaves us to various access networks and SP networks
(see below on the 5G point).


The other dimension to this is  - number of identifiers in the packet and
that is not proportional to number of nodes in the network, but how many

nodes it ought to traverse to reach the egress node. I guess, this is
simpler to visualize.



>
> 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.


> 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.


[Uma]: You are correct on NR and small cells. But when 1000000 CSR's where
(which covers a big geographic area of a country like US)? That is

 the missing link above.

a) It is not clear in the industry how NG RAN evolves (off topic) . However
-

b) Looking at where the industry is: your access rings in LTE (biggest
deployments are few 100 nodes).  Even in 5G this will not change

exponentially. But, yes you will more nodes in the ring or you will
sub-tended rings (Olympic rings).

One more thing, you cell site router is extremely cost sensitive. You have
lot more things to worry there even  if the number is even few

thousands in that part (before worrying for exhausting identifier space).






> 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.


>
>