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

Greg Mirsky <gregimirsky@gmail.com> Thu, 28 May 2020 20:23 UTC

Return-Path: <gregimirsky@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 EBB203A0D0F for <ipv6@ietfa.amsl.com>; Thu, 28 May 2020 13:23:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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=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 syyRxP0Z6PIQ for <ipv6@ietfa.amsl.com>; Thu, 28 May 2020 13:23:52 -0700 (PDT)
Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (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 971D83A0D0E for <ipv6@ietf.org>; Thu, 28 May 2020 13:23:51 -0700 (PDT)
Received: by mail-lj1-x233.google.com with SMTP id k5so35023508lji.11 for <ipv6@ietf.org>; Thu, 28 May 2020 13:23:51 -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; bh=cwa9AbrcSlny+4jlrA7bACdE5pfZa9FWkf54Ybnpi3U=; b=hqm6mq6f6LIVScQNDLgg4XAVrJfdiOzcq+f/+itaJaA7UNr3LHzvWF5TU7k7PNKvgE Tu7POMthLdGcWgz7QL5qco8zLITbG8H6qkq8BStCqmv7MQap0LObQhdv46p69jbGUswZ SZ/CJNp3S/7Mov2wl3N8t/OKjkOGDbIpKOEQowS2Xolx4JU5zdRgYehuqU75qsNC0XD7 fJJiamxgbVLht2Yq+eZsAjUu1E/6n3sFCi2vBiqGtpkC99wTdSTByVmGUv/t3t10pLp3 nR/LPDIHB5yV3H7UHNsPe6ZEvPMLiz87EqxMUzNJqW3gow1JHCuRtXBF0Jfp5g8L0kVc LtdQ==
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=cwa9AbrcSlny+4jlrA7bACdE5pfZa9FWkf54Ybnpi3U=; b=ESj3r4bEYE7zEB7pdOFAHcW4t8KLA+NrZ6tIvZZBCm5L726c5hn3OGMq9Leg7Ve5a/ EDpDP3KHmNhK0oGYQWrem+/jRSMc9SKA9bRHFf44bGCSYNF5AvN8q6PMiPYdjDyZElhk pGHXLkKXBHBGndlkQJT7n1qRF1aI4rg8MqHrkEROazmdzR1AxgV47IJxtO6ovrpFBoe9 KtcTZvteu31pbURuLZG5aCbQqFJTUbu0y6FU52ui4NrxZ7xDpxFqwPESgeeT05rBP6er QlR5K1teDakkbqDKNfxBZHxgaAhy5OLhjwZkqav65AKB3a0jSBSX36/ypXO4BG+EnL0G jmyQ==
X-Gm-Message-State: AOAM532iV6t1dGuGC91N/eII/XKk+YPxgCrikEChfa5SxjxhEaHH2rRS IO0SJrBluo7A5sJaoaXO451iHlTgJGQkX4qZJRc=
X-Google-Smtp-Source: ABdhPJx7ymVhkgIjBnvpW9mhBstbkM9rqDidHKb4mqXynt5cFSvErhTzeYX9QX51JO1NEYKf7VngjN8ncb321+DP7kg=
X-Received: by 2002:a2e:5446:: with SMTP id y6mr2396777ljd.8.1590697429612; Thu, 28 May 2020 13:23:49 -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> <CALx6S34hG=PTpja_PhMbtcCL+QnaBhqTfk6u_4kzatXARpoWPQ@mail.gmail.com>
In-Reply-To: <CALx6S34hG=PTpja_PhMbtcCL+QnaBhqTfk6u_4kzatXARpoWPQ@mail.gmail.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Thu, 28 May 2020 13:23:38 -0700
Message-ID: <CA+RyBmWsJUxuxJr9YwBx2q9n=Xiw+V8AwNZAyCpRc1HjFeBjXA@mail.gmail.com>
Subject: Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"
To: Tom Herbert <tom@herbertland.com>
Cc: "Joel M. Halpern" <jmh@joelhalpern.com>, IPv6 List <ipv6@ietf.org>, =?UTF-8?B?UmFuIFBhbmco6IGU6YCa6ZuG5Zui6IGU6YCa572R57uc5oqA5pyv56CU56m26Zmi5pys6YOoKQ==?= <pangran@chinaunicom.cn>
Content-Type: multipart/alternative; boundary="0000000000003cbdc405a6bb1b83"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/sKZxzpoL4ZWkeV6USjWBzr0qr2c>
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:23:54 -0000

Hi Tom,
I agree that "and ignored on receipt" in the definition of the Flags field
makes the future use of the field more restrictive. But I believe that can
be mitigated, as I've mentioned earlier, via control and/or management
plane extensions. Not that we have not faced a similar situation before and
dealt with the challenge in a reasonable way.

Regards,
Greg

On Thu, May 28, 2020 at 1:14 PM Tom Herbert <tom@herbertland.com> wrote:

> 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
> >> --------------------------------------------------------------------
>