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

Rakesh Gandhi <rgandhi.ietf@gmail.com> Fri, 29 May 2020 17:51 UTC

Return-Path: <rgandhi.ietf@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 C7EC43A0EA2 for <ipv6@ietfa.amsl.com>; Fri, 29 May 2020 10:51:35 -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 xrAvdIfOiIBR for <ipv6@ietfa.amsl.com>; Fri, 29 May 2020 10:51:33 -0700 (PDT)
Received: from mail-lf1-x144.google.com (mail-lf1-x144.google.com [IPv6:2a00:1450:4864:20::144]) (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 838493A07BE for <ipv6@ietf.org>; Fri, 29 May 2020 10:51:32 -0700 (PDT)
Received: by mail-lf1-x144.google.com with SMTP id z206so190983lfc.6 for <ipv6@ietf.org>; Fri, 29 May 2020 10:51:32 -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=UZ8EHbSK2fJm2qGGhkiefeGeDidRowJgFROXKY8PacM=; b=pe5vccuh9YE85aRRLKRHf9Acy/McOJiUFFoecLwA763TJlZneU9k5onMDAPWmM0pym OJtF1Nx4Qt0F2pwQqkzQrQPXHVq4TyI3maH8Jsw0gb1eJ88iwYuBfqr6ReafksaaDy0a IZm/W2hErctfmV4kgk/2j744HKXOIgGOFcNd+dEgMAIbbh9p34ndZZKiAj3trpI5lJMW a2iDfSXufIvP+vzdaZvNzgoc3YTqgtKkMEyHqpuD0e2kfmZOXowJg0OcPhOrO0+8x2mM /NoeCgef0dOIHSY7642F54eqnPxkcq/AetTc7pFh0z6+eGpCnQ7ywy4lg5fdWXiSbCQw hbww==
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=UZ8EHbSK2fJm2qGGhkiefeGeDidRowJgFROXKY8PacM=; b=etEO/6b1zrF4STsc5zVb9esttdxqcpymMIo7BcjCx4xM5+C7/uaKjaZEOsy3QZ8tqE jFTBrgy+WLo7L3tQppyDfkvsQgIxM2bvC522KPlCInAp8A4rWsqTrwtAcY2as14ge9SH iu5IB6hxMGUcWXNF9EuRBRgAyljK0WTiYY/EuIVVKSOiY6Ns/XuxJgEwkGBQRM665iHE vXt0PaSVYQZzpJExzV8wQAckQedAPu6cuHsXpF16IlmA+HUAvAT49JfvLc0YYH6NPa9u 33YfiYlvJcr+evVswhS+1KV6RvUPy+zmogFlX39pjNWvJH6zFmJCJQR245CbQbvd4Q2X qG/w==
X-Gm-Message-State: AOAM532rQcypOgzpCjoFtBYqt6SvcNUq0KzgTEXxLbGxw6CD1GXEWJl3 ISrC3IQkYcqWHiBI+d34H5dKO3VkFwdPXx6V+ZbpEJA=
X-Google-Smtp-Source: ABdhPJzFx7nEsVy+twy8eFzwzmicAbEtbkz18qDpn2h5DAZ29ZTh55OLqa8341pEP5XmK4TC0T6KWSPpGWhqvFPrfbY=
X-Received: by 2002:a19:c04:: with SMTP id 4mr4970293lfm.17.1590774690647; Fri, 29 May 2020 10:51:30 -0700 (PDT)
MIME-Version: 1.0
References: <CABNhwV2h5Vzb=_q2NNg4ZLw+1GrQ3baCAAVMiapi_5Je6o-_HQ@mail.gmail.com> <410169479.1590731084307.JavaMail.root@pwmlap3v> <C7C2E1C43D652C4E9E49FE7517C236CB02A53DEA@dggeml529-mbx.china.huawei.com>
In-Reply-To: <C7C2E1C43D652C4E9E49FE7517C236CB02A53DEA@dggeml529-mbx.china.huawei.com>
From: Rakesh Gandhi <rgandhi.ietf@gmail.com>
Date: Fri, 29 May 2020 13:51:18 -0400
Message-ID: <CAMZsk6eB8Y5GxYp7Ed-Y5F_8ipTps=NYw3kJhh33J789UjDiGg@mail.gmail.com>
Subject: Re: Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"
To: "Chengli (Cheng Li)" <c.l@huawei.com>
Cc: IPv6 List <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000005a923805a6cd1883"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/LR53Jk4ru3Scu5cOjlSpiiIKwQY>
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: Fri, 29 May 2020 17:51:36 -0000

Hi WG, Chairs,



I do not support WG adoption of this document.



I agree with Cheng. Work should first start with SPRING WG with an analysis
of the available options.



Thanks

Rakesh



On Fri, May 29, 2020 at 2:14 AM Chengli (Cheng Li) <c.l@huawei.com> wrote:

> Yes, agree with that. Personally, I think most of the issues will be
> addressed if we start from SPRING.
>
>
>
> Thanks,
>
> Cheng
>
>
>
>
>
> *From:* ipv6 [mailto:ipv6-bounces@ietf.org] *On Behalf Of *???/??
> *Sent:* Friday, May 29, 2020 1:45 PM
> *To:* Wang Weibin (NSB - CN/Shanghai) <weibin.wang@nokia-sbell.com>om>; Gyan
> Mishra <hayabusagsm@gmail.com>
> *Cc:* IPv6 List <ipv6@ietf.org>rg>; Ran Pang(联通集团联通网络技术研究院本部) <
> pangran@chinaunicom.cn>
> *Subject:* Re: Re: Adoption Call for "The IPv6 Compact Routing Header
> (CRH)"
>
>
>
>
>
> I fully agree Gyan and I would like the discussion to be prioritized
> through SPRRING WG.
>
>
>
> KH
>
>
>
>
>
> ------------------- Original Message -------------------
>
> *From : *"Gyan Mishra" (hayabu sagsm@gm ail.com)
>
> *To : *"Wang, Weibin (NSB - CN/Shanghai)" (weibin.wang@nokia-sbell.com)
>
> *Cc : *"IPv6 List" (ipv6@ietf.org)
>         "Ran Pang(联通集团联通网络技术研究院本部)" (pangran@chinaunicom.cn)
>
> *Date : *2020/05/29 금요일 오후 2:23:22
>
> *Subject : *Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"
>
>
>
> I believe a few variants of what you propose have been done with the SRV6
> compression d rafts.
>
>
>
> Gyan
>
>
>
> On Thu, May 28, 2020 at 10:30 PM Wang, Weibin (NSB - CN/Shanghai) <
> weibin.wang@nokia-sbell.com> wrote:
>
> I think it is a good idea to create a new routing type for encoding new
> type of SID in RH.
>
> I also think that, as a result of IPv6 address has 16 bytes length, its
> space is big enough, lots of bits-string within it is redundant and
> unnecessary in some scenario. so considering the classic SRv6 scenario, we
> can only use least significance 64 bits within a fixed /64 prefix block for
> all SID assigning for limited domain being deployed by SRv6.
> That means, only one same  /64 block is enough for all kind of SIDs
> assigning within limited domain, so only rightmost 64 bits representing all
> SIDs allocated to all prefix-SID and Adj-SIDs and Service-SIDs should be
> encoded within SRH with new routing type value. During packets being
> encapsulated with outer IPv6 and new RH forwarding through SRv6 domain, its
> left-most 64 bits of DA field keep intact and only right-most 64 bits will
> be replaced endpoint by endpoint from SRH.SL.
> The benefit:
> - get half-reduced SRH length compared to classic SRv6 SRH under same
> number of SIDs encoded segment list;
> - keep same forwarding plane with classic SRH processing; no extra
> processing for deducing compressed SID or normal SID coding in SRH; keeping
> the simple of forwarding plane is most important for all solution.
> - only one /64 prefix as SID block, the complexity level of security
> deployment is largely reduced.
> - the efforts of control plane protocol extension such as ISIS-srv 6 or
> OSF P-srv6 have being made previously can be reserved.
> - no mapping mechanism at forwarding procedure and control plane.
> - the solution is balance between SRH size and complexity of forwarding
> plane.
>
>
> Cheers!
>
> Wang Weibin
>
> -----Original Message-----
> From: ipv6 <ipv6-bounces@ietf.org> On Behalf Of Tom Herbert
> Sent: 2020年5月29日 4:48
> To: Greg Mirsky <gregimirsky@gmail.com>
> Cc: IPv6 List <ipv6@ietf.org>rg>; Ran Pang(联通集团联通网络技术研究院本部) <
> pangran@chinaunicom.cn>
> Subject: Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"
>
> On Thu, May 28, 2020 at 1:23 PM Greg Mirsky <gregimirsky@gmail.com > wro
> te:
> >
> > 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.
>
> Or just create a new routing type that is universally unambiguous, doesn't
> require external information just to understand the header format, and
> carries not risk of breaking backwards compatibility. Like Joel said, being
> compatible with SRH routing type for compressed SIDs isn't a requirement
> and I can think of any reason why it should be. A new routing type is also
> an opportunity to revisit all the fields in the header, for instance we can
> reevaluate whether Flags, Tags, and TLVs are really needed in a routing
> header.
>
> Tom
>
> >
> > 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 t his sinc e 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 chang e withou t
> 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 compati ble
> with SRH.
> >> >>> >
> >> >>> >
> >> >>> > Thanks,
> >> >>> >
> >> >>> > Ran
> >> >>> >
> >> >>> >
> >> >>> >     *From:* Bob Hinden <mailto:bob.hinden@gmail..com
> <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
> <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 th e
> list.< br>>> >>> >     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
>
>
>