Re: Size of CR in CRH

Mark Smith <markzzzsmith@gmail.com> Wed, 20 May 2020 21:24 UTC

Return-Path: <markzzzsmith@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 E14DC3A00D3 for <ipv6@ietfa.amsl.com>; Wed, 20 May 2020 14:24:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.598
X-Spam-Level:
X-Spam-Status: No, score=-0.598 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 AtUi0ayyi9IL for <ipv6@ietfa.amsl.com>; Wed, 20 May 2020 14:24:32 -0700 (PDT)
Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) (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 737E73A00C4 for <6man@ietf.org>; Wed, 20 May 2020 14:24:32 -0700 (PDT)
Received: by mail-ot1-x335.google.com with SMTP id a68so3733675otb.10 for <6man@ietf.org>; Wed, 20 May 2020 14:24:32 -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:content-transfer-encoding; bh=+JQqUl96SGRjHmnQOaSuTPtxZJyo2pAu7uSIPB7HZ5M=; b=rZiTK7Xjsc2XCS+XfjlvflyYg0HXZJqVs5EdWzRGDWTeSvW0NhMfg1cBDqGy9RcCt7 8DHoBISzmYeZgZh1P6nZAl/MC9lK4CDPud8s4wY7QJPmxUJL4o1TayzM/I2NpPvkBf8A +FmeNww/iQAPaO1gIMaugbsbIWePkluhigRIywJstsrwKg8SFjiN5XagsYO+KFTjMps4 O3DrjPA4bwy8ZgfTLEZ9k2xV+cceFx94LuaaqHCir9cxo6KrbvqJaAEDX9hBOrch/BGi YUH6hICteAkW7uR74RkBsnQFXQFtik3qNKBeUQP9hvYJjQ8iQ5Pkkh5nSsBxpkoCo8gY 1zfg==
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:content-transfer-encoding; bh=+JQqUl96SGRjHmnQOaSuTPtxZJyo2pAu7uSIPB7HZ5M=; b=mYE7BibRGuH2fnO8Xa3Puk2iYUzFLMR/PfUfCxZadbGp3TPdtrfCu4RGAn6nSaY6OA VeCvV0GCItNGOi47zV4st0+8+yDiXkj5rZNmSzNYwy1bGIucz9ewGduaUsS3UQuZQnIL Bzh/5LOwE89HAIqsF2QO4PCqZo5Rm4B10SADp4CIR3G5lghOBrgBlr208CfiBNGXz8gr IHGfuBtysqXzJPFnBrXqvoCEI5lS9psoxIeYK3hHNcgIOFwVChB1FjMon686hoV7H6ea r2ZAnVU2zpnnMNJpwbSsBJ/YGxQAarH2Hd2TlT7vD20Reio+qYzI/3cnyf4lw9hQWbOt AX6g==
X-Gm-Message-State: AOAM531tXOTkZN5JRwQRY77xzy6uH1L6MAbbrmw6NjysoAsl5/dqs0Jd o7d1H7oLAaX7E9ejpFsYcisxNTuA2L7ZgHAePuY=
X-Google-Smtp-Source: ABdhPJxvnGFcxIu+P0NGj2vmmKatdy458AN2FWzdXASJ4OROyilpuKHJwMwzFL94MRXjbG0SqlUPwalZQ79UsHpREwU=
X-Received: by 2002:a05:6830:20d7:: with SMTP id z23mr4910834otq.153.1590009871592; Wed, 20 May 2020 14:24:31 -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> <EA0BCB8D-C328-471E-A824-320A6A1C39B8@gmail.com> <DM6PR05MB634898FF6351E40315A42E88AEB60@DM6PR05MB6348.namprd05.prod.outlook.com>
In-Reply-To: <DM6PR05MB634898FF6351E40315A42E88AEB60@DM6PR05MB6348.namprd05.prod.outlook.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Thu, 21 May 2020 07:24:05 +1000
Message-ID: <CAO42Z2wcH-wMP1bTSFxH+i4ReH8XLAUVTxfvFQfV7jVgVyJ5HQ@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: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/49Qt_6JrIePt-lGXphQRM62dadQ>
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 21:24:35 -0000

Hi Ron,

On Thu, 21 May 2020 at 04:41, Ron Bonica
<rbonica=40juniper.net@dmarc.ietf.org> 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 <bob.hinden@gmail.com>
> Sent: Wednesday, May 20, 2020 12:46 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,
>
> 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/ipv
> >> 6
> >> __;!!NEt6yMaO-gk!UCWrvkvflbEehBiEIA8M4PHGA_mrvC0MLpZly-euihAg3_3aSjRJ
> >> L
> >> LRAZuRumqRr$
> >> --------------------------------------------------------------------
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------