RE: Size of CR in CRH

Andrew Alston <Andrew.Alston@liquidtelecom.com> Wed, 20 May 2020 05:21 UTC

Return-Path: <andrew.alston@liquidtelecom.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 2A30E3A3AA1 for <ipv6@ietfa.amsl.com>; Tue, 19 May 2020 22:21:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 qEiSRzL7l9NC for <ipv6@ietfa.amsl.com>; Tue, 19 May 2020 22:21:49 -0700 (PDT)
Received: from eu-smtp-delivery-182.mimecast.com (eu-smtp-delivery-182.mimecast.com [185.58.86.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 435213A3A87 for <6man@ietf.org>; Tue, 19 May 2020 22:21:48 -0700 (PDT)
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-he1eur04lp2053.outbound.protection.outlook.com [104.47.13.53]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-75-f6PQ705MPhu2iSzZGehHyw-1; Wed, 20 May 2020 06:21:44 +0100
X-MC-Unique: f6PQ705MPhu2iSzZGehHyw-1
Received: from VI1PR03MB5056.eurprd03.prod.outlook.com (2603:10a6:803:bf::31) by VI1SPR01MB333.eurprd03.prod.outlook.com (2603:10a6:803:37::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3021.23; Wed, 20 May 2020 05:21:42 +0000
Received: from VI1PR03MB5056.eurprd03.prod.outlook.com ([fe80::ed68:9303:79e0:cc49]) by VI1PR03MB5056.eurprd03.prod.outlook.com ([fe80::ed68:9303:79e0:cc49%4]) with mapi id 15.20.3000.034; Wed, 20 May 2020 05:21:42 +0000
From: Andrew Alston <Andrew.Alston@liquidtelecom.com>
To: Bob Hinden <bob.hinden@gmail.com>, Ron Bonica <rbonica@juniper.net>
CC: 6man <6man@ietf.org>
Subject: RE: Size of CR in CRH
Thread-Topic: Size of CR in CRH
Thread-Index: AQHWLWlVL97JUcjPaE6Ml0JwXtdsmqivpq+AgAANmgCAAJfTAIAAIe1Q
Date: Wed, 20 May 2020 05:21:41 +0000
Message-ID: <VI1PR03MB505611431C596432A8D3271CEEB60@VI1PR03MB5056.eurprd03.prod.outlook.com>
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>
In-Reply-To: <19E3F1AE-904C-49DC-B528-B1025A1454F0@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [197.155.81.57]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 61f8b958-962f-4447-c597-08d7fc7dae59
x-ms-traffictypediagnostic: VI1SPR01MB333:
x-microsoft-antispam-prvs: <VI1SPR01MB3331356B07DD84C2F34123FEEB60@VI1SPR01MB333.eurprd03.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 04097B7F7F
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 46VS7ZIA2zrnp3VJgV41A0pBKhANlm0263ILFvFA3a4C+nEEfsp1xLO48S1Mwp2mWTfSKJosSAAk6mt8HuQf85M5RWOPH0HkcKTWPKX9fRw/Wa09nMG6dbz944lzAKR5l2cyDaiBhwZlixBwyxC1viSjfCGLZCA2aHBxXgml3T80zftzYSqUUuEjNPC+RGl+j6Rme14Fw0OGcU49A0cNKY8fWtk9x82hID34zjnhRJZyIbSaDpqV0OB9PS1I2xfHeGvm1m2EQN+5mycOgWXcpauj7aY81MDY/lgDSy790p5wvdS5dEjlPERelv3ZR22KBbfyGCUtkadLbVDeD53Wbw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR03MB5056.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(39850400004)(346002)(366004)(136003)(376002)(2906002)(26005)(4326008)(7696005)(316002)(8676002)(8936002)(478600001)(55016002)(186003)(86362001)(110136005)(9686003)(33656002)(5660300002)(6506007)(66556008)(64756008)(66476007)(52536014)(66446008)(71200400001)(66946007)(76116006); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: yWlxsMcea/bUqVDecVUZHTMvTeqla3GvoawEva+6TzLd3VTW8+BeBYyVO2PCZhcy28aZ44vVWgKTlvcrD1verXF8t09Zfo8Fr8RTtd75wej4iQ490XquaZDsETYiwahsdbgUdmkHZ0Aoqlfvjex7gtNZYG+nlKPT3gEXz30dGRaPneQYZcKVX8r5zCDf0ylITcIAaqWvjHpr+v2RMz8iEWe8wNtpTafDxHeSxjiwknQI1IlmRck71FgMYwuqnYGXMjsLOUvSIqAhsBxZMkRK4DxX9PwMAEsDI0qbt+nLbyJVy5eqRq3HDwPyPGhv4PhrTek/oiS+wEaoCAorKS2/NP7py5qGgKNLYE1oQZjtyqv68jQbPZX3MLvZy3wEZkMZVH5UwvI4d+v44n7a1rvqdjEMNOn+EQd3mOK2DnhfKl0FD9HtWdiCa+CFH5ZrQWhkALiJWCiGv5lHLVDFkgZm3+xEpNRGWOy59hyrkZaXr6M=
x-ms-exchange-transport-forked: True
MIME-Version: 1.0
X-OriginatorOrg: liquidtelecom.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 61f8b958-962f-4447-c597-08d7fc7dae59
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 May 2020 05:21:41.9756 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 68792612-0f0e-46cb-b16a-fcb82fd80cb1
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: LOz08hDvRVeJNx51ymtyBbJBD07KbpmcouYFKKQk0S9wp2e47aDv1VdKjJzf2J7zcwElOogbgK87NI3lgAG9JqteVx3c1qJeb9X9m4drvDk=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1SPR01MB333
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: liquidtelecom.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/gVKF3V-SK6n4wq8sH05jpY9VgJ4>
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 05:21:59 -0000

Just a few comments on this.

Regarding the SID Size, and basing this on our rather extensive SR-MPLS deployments.  What we have found is that with many many hardware devices limiting the maximum SID size in MPLS to 64k we were running into some operational complexities on our side - nothing that could not be solved. 

It was not the straight up number of devices that was the problem - is was the fact that when running a single consolidated network across multiple countries, what we wanted was to assign a block of SID's to each country out of the same SRGB.  This allows each country operation to know exactly what block they are allocating out of and avoids potential problems of trying to manage all SID allocation from group level.  

This also allowed us to align our SRMS mappings correctly with the address allocations within the specific country.

However, this then creates a situation where you are effectively running into the same problem as address de-aggregation, and because you want those blocks to allow for future expansion etc, you can burn through 64k pretty damn fast when operating across 15 countries.

Now, if I look at CRH - we see a similar thing - where a large network wants to allocate blocks of CRH SID's on a per country basis, yet you are running a single consistent overarching block across the network, the 64k limit is actually a lot smaller than one would imagine.  I would however say that a 16bit CRH SID has a lot of application for smaller networks.

While it is very certainly possible in our scenario to make things work with a 16bit CRH SID, its our view that it would substantially increase complexity from an operational perspective.  Hence, while I certainly support the dual SID sizes, for me, if we had to drop one of them, it would be my preference to stay with the 32bit SID.  As I said though, if the WG does decide either pre or post adoption of the draft to go with one rather than two, I'm not hugely religious about which at t his point, though I see the need for something larger than 16bit becoming very apparent in the future.

Just by way of illustration - if we were to run networks across the entire African continent - which I hope to see us doing one day - as a single network, and we split the 64k block up per country, that only leaves 1213 CRH SID's per country - we use more than that in the SR-MPLS domain in at least 3 countries today.

Andrew