Re: Size of CR in CRH

Tom Herbert <tom@herbertland.com> Thu, 21 May 2020 14:42 UTC

Return-Path: <tom@herbertland.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 C5A263A0D1B for <ipv6@ietfa.amsl.com>; Thu, 21 May 2020 07:42:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.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 55KomIkucgjK for <ipv6@ietfa.amsl.com>; Thu, 21 May 2020 07:42:21 -0700 (PDT)
Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (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 433323A0D1F for <6man@ietf.org>; Thu, 21 May 2020 07:42:06 -0700 (PDT)
Received: by mail-ed1-x52f.google.com with SMTP id l5so6796519edn.7 for <6man@ietf.org>; Thu, 21 May 2020 07:42:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QbASNUOtuWM9rA77VpJzOq8pwmKO9i2CwcoN4Iq8WUI=; b=vxoOip/J6d2tUB1xgxOQz70xhOhKy+D+eHfSdbFORuVwtw95rK+hpmu7M5rIx6PlqN tc6jydt7aJdniKGyYDhDjyrBlsUEzZaYrMit49pUHglCNxY4QG8409LFuwSfs0M0Qr/b eBZkEkMVWBHO2m+NJdkLPv/YR8e4/XJmQYEGu0QyRb60f6yhGa+t28Y5ByML2nhm/YGd noPsSqTrPM16l9MpluuvGWS3ZWBK5wZyy7xy/buVChEZYA/XzFZgBCbyBvyj40EIXvKq OG1sQitQT64uWv1Eb/60bo0fdi85VV82X2s0h1bwOoOAPXsHOuobSLwqqz7+Z/S+0SZ+ +baA==
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=QbASNUOtuWM9rA77VpJzOq8pwmKO9i2CwcoN4Iq8WUI=; b=gdBf3s6Li68OnntLXqLcgNmjTEI6tUGZspvdskyUs7vrTW9zOC/dxTQsMLi0AjEsrs 2b/DCsBvGW/bIJhnXYGvZqG4sktDhjtuPVFIFH0Ezl4jEo+loH7ojp5/F+k80V82L36X Xfbh2PowHH5BVypxuEb8Y/VnuvIvxsCOXw40PyEOvzvBmzfgKmQ44+hoGQou66/NcM3Y nwO7/7e35C2kzcApBzY77bAfFtxkDmP7VOE0My5ZW7u697cfijXCp1G6pljnPMtAOJ3t hO8xCqm6+md/EXaZn2Frgeg3wxyn+4A+bjiIFAxbtlQH0544J0XoOpHMcTe9Rtdjyk23 zwBQ==
X-Gm-Message-State: AOAM533aUiIFoPuvLL17PpkklMkLHf/Xr8V+xj/A53u49sBl+IJeHxYi QfzCpZQMzlfvCihTpy5zZINX4hMtnWdwCCIapD4wF0Lo
X-Google-Smtp-Source: ABdhPJzSJAGtRAM/bI/SdadZ1/dbmJIhAy6pFDJF3O+YVwMn20N7UeMdeupnqDlb6I2cnfv4uEIWMeZxspYOkQhcOdY=
X-Received: by 2002:a50:d785:: with SMTP id w5mr7651102edi.212.1590072119293; Thu, 21 May 2020 07:41:59 -0700 (PDT)
MIME-Version: 1.0
References: <C7C2E1C43D652C4E9E49FE7517C236CB02A2BA5D@dggeml529-mbx.china.huawei.com> <DM6PR05MB634888D7D912D561B7F5F0E8AEB70@DM6PR05MB6348.namprd05.prod.outlook.com> <c7b12240-21dd-bb4c-99b6-d590bc298934@foobar.org> <DM6PR05MB63489BBE50753D518C887908AEB70@DM6PR05MB6348.namprd05.prod.outlook.com>
In-Reply-To: <DM6PR05MB63489BBE50753D518C887908AEB70@DM6PR05MB6348.namprd05.prod.outlook.com>
From: Tom Herbert <tom@herbertland.com>
Date: Thu, 21 May 2020 07:41:46 -0700
Message-ID: <CALx6S37DWey4aj8nFxa=nqB=CrpjuoJYLcyOCY19fOeisF7OPw@mail.gmail.com>
Subject: Re: Size of CR in CRH
To: Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>
Cc: Nick Hilliard <nick@foobar.org>, 6man <6man@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e4617405a629835b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/0nEb9C7RrUbK4FgygfcCp4e08ow>
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: Thu, 21 May 2020 14:42:24 -0000

Ron,

I believe if these are considered compressed values that are just used in
the on-the-wire datapath then that would mitigate would complexity in the
control plane. For instance, uncompressed identifiers can be used in
tables, configuration, for conveying in BGP independently of whether
compression is being used in datapath.

Tom


On Thu, May 21, 2020, 7:34 AM Ron Bonica <rbonica=
40juniper.net@dmarc.ietf.org> wrote:

> Nick,
>
> Fair enough. Let's initiate a dialog to identify and mitigate the
> operational complexity. This may require many messages, so let's do that
> off-line and come back to the mailing list with a summary.
>
>                                                                  Ron
>
>
>
> Juniper Business Use Only
>
> -----Original Message-----
> From: Nick Hilliard <nick@foobar.org>
> Sent: Thursday, May 21, 2020 6:24 AM
> To: Ron Bonica <rbonica@juniper.net>
> Cc: 6man <6man@ietf.org>
> Subject: Re: Size of CR in CRH
>
> [External Email. Be cautious of content]
>
>
> Ron Bonica wrote on 21/05/2020 03:51:
> > Does having two CRH versions really add operational complexity, given
> > that operators will be advised to run one or another?
> >
> > Why not let the operator choose which version is best for its network?
> > They probably know better than us.
>
> yeah, it really does add complexity.
>
> I don't see a straightforward way of hiding the implementation details in
> a configuration grammar, at least not portably across vendors.  This means
> implementing complexity right down the tool chain and creating operational
> / support awareness about the fact there would be N different varieties of
> CRH, semantically similar but not the same.
>
> If you merge networks with different SID sizes, this will be disruptive
> because there's no clear migration mechanism between one size and another,
> so changing SID size would mean a flag day. Probably retooling too.
>
> It's not just operational complexity, btw - using multiple SID sizes has a
> long trail of consequences at a protocol level too.  For example, how would
> you signal this in bgp?  Separate afis?  Same AFI but different tlvs for
> each different type? Then how do you handle arbitrage?  Tom made some
> suggestions, but these also have consequences.
>
> If the prevailing WG opinion is to make multiple SID size options
> available, then we need to describe in detail how this is going to work
> right across the board, and how to minimise the downstream impact.  If we
> don't then this pushes the consequence heap into other peoples' laps and
> they may not appreciate this.
>
> Nick
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>