Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

Tom Herbert <tom@herbertland.com> Thu, 28 May 2020 20:14 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 65B513A0B11 for <ipv6@ietfa.amsl.com>; Thu, 28 May 2020 13:14:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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=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 Llvw5851sowx for <ipv6@ietfa.amsl.com>; Thu, 28 May 2020 13:14:25 -0700 (PDT)
Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (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 688003A0AD6 for <ipv6@ietf.org>; Thu, 28 May 2020 13:14:25 -0700 (PDT)
Received: by mail-ed1-x533.google.com with SMTP id k19so1096953edv.9 for <ipv6@ietf.org>; Thu, 28 May 2020 13:14:25 -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:content-transfer-encoding; bh=q1xUKEXnZ6rcorzDoF6TgCITIdIu8TnAH5QHSAK3ibE=; b=M2bhCDf6P/BY+fYhGLAhu8QGzhjFedwTucxKxGj6vjcNKaQpfOeweaNl1dIWcfcRhL W6XTCZN6l88f8U5PVXtngJDwWDk6DHgnM7xRx2z+/w4UcbXn7s7wMYrG/+YfPetJKFox PmdYlG6D5y09v8J+5K7tD656wToqWp4u/qd2TEOO3s4CpC2ILwgs/qhwzdacrfDtub0X F+NzBlyWWEb+V7JFkQZkWj0jXH+Nldi59NQayC2bopBE2N95cGS4Fqa+ZjA3CrqfGr1p tbMXLWHUc6X6pcYb031TrFEKhciRFT/vf+K5bqKJt7L8TzSWgpoDz+lzZfzEXUonER/L NFRA==
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=q1xUKEXnZ6rcorzDoF6TgCITIdIu8TnAH5QHSAK3ibE=; b=KUnTwmcr2bGYcXYzBLUaMKwfzEAWoW0VBa9xtFSrIYL4LGitTznH7coPiwENzHdEhA UXLEfpBwUcoiyPoyMV72/mFeGTmu6JUD8aY691kahuXaC6iXrCh0zDqjxLpAlYBKb0+1 oLnYSWG3fPwSRkeXlsKeimRe+7SmMtGn0C5jFGjZTygVSHGo+zrb0c8Sosv0tEQttu2C S0e9d+3R27E/g3NxY4GUlzM5G6exSnxFt3lAPfQyajZOhp3jcYHy+yh62NoWUEv35dEP vrjwpEV2q1iQAt91wH09dAi1yUZF3LXhL66b34qIvODaaaz9BUZzZUD/tq0wBcxRfts0 79OQ==
X-Gm-Message-State: AOAM531ODV7OCtYUEfdYEG47bgJfyClMimcuRsjys8iINWllPNVS7JAH +pbhXo1iRPUZfVlY+VuKuSGgEzfKdpvbjXimgWPmYg==
X-Google-Smtp-Source: ABdhPJxPVnpwNJr9ZIGHFfYz5zUzqOivMMWLviA4KyQMpZUzzXLpkYiidvJhYPV5IhtJJPzZOUYXJfhOvMhMqUzioGs=
X-Received: by 2002:a05:6402:2d4:: with SMTP id b20mr5058175edx.118.1590696863581; Thu, 28 May 2020 13:14:23 -0700 (PDT)
MIME-Version: 1.0
References: <19D30186-B180-4F65-BF00-7AD07CEF3925@gmail.com> <defcf5c6292345e7a333d600c4f47561@M10-HQ-ML02.hq.cnc.intra> <5eff7c35-f4f1-fa8f-2343-66896f3b42d9@joelhalpern.com> <CALx6S34zxH2k=27uuGjOL8-bT5m2WTSBcxxHDmGAvejEsM6R9g@mail.gmail.com> <CA+RyBmXpy++6sfo50AHdEzuOdYVVUXE4+7Tq3BJVSHG3nTJK0Q@mail.gmail.com>
In-Reply-To: <CA+RyBmXpy++6sfo50AHdEzuOdYVVUXE4+7Tq3BJVSHG3nTJK0Q@mail.gmail.com>
From: Tom Herbert <tom@herbertland.com>
Date: Thu, 28 May 2020 13:14:12 -0700
Message-ID: <CALx6S34hG=PTpja_PhMbtcCL+QnaBhqTfk6u_4kzatXARpoWPQ@mail.gmail.com>
Subject: Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"
To: Greg Mirsky <gregimirsky@gmail.com>
Cc: "Joel M. Halpern" <jmh@joelhalpern.com>, IPv6 List <ipv6@ietf.org>, =?UTF-8?B?UmFuIFBhbmco6IGU6YCa6ZuG5Zui6IGU6YCa572R57uc5oqA5pyv56CU56m26Zmi5pys6YOoKQ==?= <pangran@chinaunicom.cn>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/wXRYmIk2eAQEkipvts0-wlWjO_8>
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, 28 May 2020 20:14:27 -0000

On Thu, May 28, 2020 at 12:54 PM Greg Mirsky <gregimirsky@gmail.com> wrote:
>
> Hi Tom,
> you've noted that "The format of SRH is very specific that SIDs are 128 bits". True, that is the view, the current view based on the definition of SRv6 and SRH in  RFCs 8402 and 8754. But both may be updated at some point. Thus we can avoid the introduction of RH per SID length. Would you agree that it is a viable option?

Greg,

Unfortunately it's not an option. There is no field in SRH that could
robustly be used as a code point to indicate an alternate header
format or different length of SIDs. Neither is there any way to
retroactively add that this since RFC8754 is already out the door and
in deployment. This is analogous to someone wanting to create a
compressed version of the IPv6 header to use 64-bits instead of 128
bit addresses-- there is no way to do that without getting a new IP
version number. The difference in the analogy, is that the IP version
number space is only4 bits, but the routing type space is 8 bits. So
allocating new routing types for compressed SIDs really isn't much
issue since there are plenty of values available (247 routing type
values are unassigned whereas only 5 IP version numbers are
unassigned).

Tom

>
> Regards,
> Greg
>
> On Thu, May 28, 2020 at 11:33 AM Tom Herbert <tom@herbertland.com> wrote:
>>
>>
>>
>> On Thu, May 28, 2020, 11:22 AM Joel M. Halpern <jmh@joelhalpern.com> wrote:
>>>
>>> Several people, including at least one I-D, have asserted that there is
>>> some abstract requirement for compatibility with SRvc6's SRH.  There is
>>> no such requirement.  That is not a criterion the 6man group needs to
>>> consider.  In my personal opinion, it is not even a constraint on what
>>> SPRING chooses to do.
>>
>>
>> Joel,
>>
>> It's not even clear what compatibility with SRH means. The format of SRH is very specific that SIDs are 128 bits, and the protocol has no sufficient extensibility mechanism that allows that to change without breaking backwards compatibility. As far as I can tell, changing or compressing SIDs requires a new routing type regardless of the compression method or who specifies it.
>>
>> Tom
>>
>>>
>>> Yours,
>>> Joel
>>>
>>> On 5/28/2020 3:38 AM, Ran Pang(联通集团联通网络技术研究院本部) wrote:
>>> > Hi WG,
>>> >
>>> > It seems like CRH is not compatible with SRv6 and SRH. We need to
>>> > discuss how CRH cooperates with uSID, G-SRv6 or other SRv6 header
>>> > compression solutions before adoption, or whether CRH will cause
>>> > difficulties in the deployment of G-SRv6 and other solutions. At
>>> > present, we tend to choose solutions compatible with SRH.
>>> >
>>> >
>>> > Thanks,
>>> >
>>> > Ran
>>> >
>>> >
>>> >     *From:* Bob Hinden <mailto:bob.hinden@gmail.com>
>>> >     *Date:* 2020-05-16 06:13
>>> >     *To:* IPv6 List <mailto:ipv6@ietf.org>
>>> >     *CC:* Bob Hinden <mailto:bob.hinden@gmail.com>
>>> >     *Subject:* Adoption Call for "The IPv6 Compact Routing Header (CRH)"
>>> >     This message starts a two-week 6MAN call on adopting:
>>> >     Title:          The IPv6 Compact Routing Header (CRH)
>>> >     Authors:        R. Bonica, Y. Kamite, T. Niwa, A. Alston, L. Jalil
>>> >     File Name:      draft-bonica-6man-comp-rtg-hdr-21
>>> >     Document date:  2020-05-14
>>> >     https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr
>>> >     as a working group item. Substantive comments regarding adopting
>>> >     this document should be directed to the mailing list.  Editorial
>>> >     suggestions can be sent to the authors.
>>> >     Please note that this is an adoption call, it is not a w.g. last
>>> >     call for advancement, adoption means that it will become a w.g.
>>> >     draft.  As the working group document, the w.g.. will decide how the
>>> >     document should change going forward.
>>> >     This adoption call will end on 29 May 2020.
>>> >     The chairs note there has been a lot of discussions on the list
>>> >     about this draft.   After discussing with our area directors, we
>>> >     think it is appropriate to start a working group adoption call.  The
>>> >     authors have been active in resolving issues raised on the list.
>>> >     Could those who are willing to work on this document, either as
>>> >     contributors, authors or reviewers please notify the list.   That
>>> >     gives us an indication of the energy level in the working group
>>> >     to work on this.
>>> >     Regards,
>>> >     Bob and Ole
>>> >
>>> > 如果您错误接收了该邮件,请通过电子邮件立即通知我们。请回复邮件到 hqs-
>>> > spmc@chinaunicom.cn,即可以退订此邮件。我们将立即将您的信息从我们的发送
>>> > 目录中删除。 If you have received this email in error please notify us
>>> > immediately by e-mail. Please reply to hqs-spmc@chinaunicom.cn ,you can
>>> > unsubscribe from this mail. We will immediately remove your information
>>> > from send catalogue of our.
>>> >
>>> > --------------------------------------------------------------------
>>> > IETF IPv6 working group mailing list
>>> > ipv6@ietf.org
>>> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> > --------------------------------------------------------------------
>>> >
>>>
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> ipv6@ietf.org
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------