Re: Size of CR in CRH

Nick Hilliard <> Tue, 19 May 2020 23:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6BF9F3A02C1 for <>; Tue, 19 May 2020 16:35:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Du0-Pd7zoKH2 for <>; Tue, 19 May 2020 16:35:13 -0700 (PDT)
Received: from ( [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B50333A0366 for <>; Tue, 19 May 2020 16:35:12 -0700 (PDT)
Received: from crumpet.local ( [] (may be forged)) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id 04JNZ79G071763 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 May 2020 00:35:09 +0100 (IST) (envelope-from
X-Authentication-Warning: Host [] (may be forged) claimed to be crumpet.local
Subject: Re: Size of CR in CRH
To: Ron Bonica <>
Cc: Bob Hinden <>, 6man <>
References: <> <> <> <> <> <> <> <> <> <>
From: Nick Hilliard <>
Message-ID: <>
Date: Wed, 20 May 2020 00:35:06 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:52.0) Gecko/20100101 PostboxApp/7.0.16
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 19 May 2020 23:35:16 -0000

Ron Bonica wrote on 19/05/2020 19:01:
> So, allocating two Routing types may be the best solution.

yeah, the hardware constraints requirement is troublesome - hey, we're 
all ToR junkies these days - but the more I think about it, the more 
complex this becomes from an operational / implementation point of view, 
for example:

- do you define SID size on a per domain or per node or a per-SID + 
per-node basis?

- if per-domain, how do you implement non-service affecting migration 
from 16-bit to 32-bit?

- without using differentiating CLI syntax, can you manually define a 
mechanism to allow a 16-bit identifier to be configured in a 32-bit SID?

- the distribution protocols needs to become aware of multiple SID sizes

- is (sid16)32768 the same as (sid32)32768. If not, why not? If so, then 
why?  How can this be explained either by or to the TAC agent at 03:00 
over a noisy, laggy phone line in a time-constrained maintenance window 
involving a P1 where neither of you speaks the other's language natively?

- how many segments do you really need to program for actual networks 
(1? 10? 50?), and how deep can you inspect on merchant silicon of today, 
and currently in development? I.e. how badly would your flexibility be 
hobbled if SIDs were one size only?