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

Greg Mirsky <gregimirsky@gmail.com> Tue, 26 May 2020 19:03 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 EF1353A0EE7 for <ipv6@ietfa.amsl.com>; Tue, 26 May 2020 12:03:25 -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 a-d0eJ1sgzn3 for <ipv6@ietfa.amsl.com>; Tue, 26 May 2020 12:03:23 -0700 (PDT)
Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (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 069353A0F02 for <ipv6@ietf.org>; Tue, 26 May 2020 12:02:37 -0700 (PDT)
Received: by mail-lj1-x230.google.com with SMTP id q2so25844968ljm.10 for <ipv6@ietf.org>; Tue, 26 May 2020 12:02:36 -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=y8UTIKzhZH1nvbj4smaZ93pStVKSSulTX7j33ACqpb4=; b=GdsfLVCHzCsGqrHlVlI2oSYv1sTldiTUnLZGYQEw3/kcDtwbYSOmF7gJemyPxy7Ach QQI/WGwDKYc6jkXTPMDo1l+OWBkh0nJERDHX/by0PatqFsBXfj4lJPQcx1GEg3YGYcNQ 5IRqqAlv2cBG8XB4/BBWJ+fWHeDIXnbFVf4QYz0b1nDBWmUs0/VSPlVGGqKXGoA0f55i xK5x8WHYXes1I6YRho5zcQGgIPrQ8IiGFLlXNSY1gU0WuHBapQ9cE3f3UKeZWJ10PUxY 0Peoj3lymkN90u3yMJUeipGod+sCKO3Y5jSBnDSuXJ5nrBTlI8cWoRi6CSuMFqXqvQjm FfYQ==
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=y8UTIKzhZH1nvbj4smaZ93pStVKSSulTX7j33ACqpb4=; b=Z4RwSe8253LCR8mSr9090YVEgxVzhjxdIi1oVEjY528Cen3RgqQnT5uvDxBa3Er3Bj dF6oYRidomwkzPc0/TAhxK5I6txAKJxSTDYfzxmTVul0WUvAMLKVkAl0wmMrLBTURQys gdSwOAHrBFj4E9fOveERsfCAvIpZbwSxlqyZbbO9H0GvBL2gQpdzeKQO45eVIjJVtro4 v0UHgFdNvsfLuV1EG2aT1VpeLvFBqaPtnr0ti+mdpDuXVSkYV7CzWYgOVzuP458PP7XO V32xt4hnmV1LvnQgx9+gUlqWvY+6mXbyDt3TAWNyMAa7nMB66CQ4ljpCdnlPuFK/Q3b+ yFJw==
X-Gm-Message-State: AOAM530LE3kcFWOl40c1d3sb2O4706pNh8B3YeztBl9/YAMzriUE8oy1 QMm1pLi/nI1W3wIR9Z9q4D69x0P8d9EVrYRLj44=
X-Google-Smtp-Source: ABdhPJwuDoSDYMuTozY5dLi8/hyw+JcWdID8M9ul662kKTNMM5dS4O36JEa78qV7Bmv3tBlsz8FCECRDT/b3JZKeMY0=
X-Received: by 2002:a2e:b1d4:: with SMTP id e20mr1093154lja.279.1590519754927; Tue, 26 May 2020 12:02:34 -0700 (PDT)
MIME-Version: 1.0
References: <19D30186-B180-4F65-BF00-7AD07CEF3925@gmail.com> <A887879F-890B-425A-B4FF-3789B875EAF7@previdi.net> <DM6PR05MB6348CDBFEDB03D5E3277458BAEB00@DM6PR05MB6348.namprd05.prod.outlook.com> <DBC94AA3-6647-4BF9-A9D7-2291B48886B2@previdi.net>
In-Reply-To: <DBC94AA3-6647-4BF9-A9D7-2291B48886B2@previdi.net>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Tue, 26 May 2020 12:02:24 -0700
Message-ID: <CA+RyBmUmJmXVo87jHj=gcy=a6sGVdQ50rjYR_2CF7+xruHb7kA@mail.gmail.com>
Subject: Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"
To: stefano previdi <stefano@previdi.net>
Cc: Ron Bonica <rbonica@juniper.net>, IPv6 List <ipv6@ietf.org>, Bob Hinden <bob.hinden@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000000033d305a691bdd1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/h1yHZmEKSrVqqlskJc-_AZKxXYQ>
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: Tue, 26 May 2020 19:03:26 -0000

Hi Stefano, et al.,
I agree that it is beneficial to have the discussion of the shorter SID in
SR over IPv6 (I'd like to differentiate the case from "classical" SRv6 as
defined in RFCs 8402 and 8754) one time rather than go over it again and
again. With that idea, we've started work on
draft-cheng-spring-shorter-srv6-sid-requirement
<https://datatracker.ietf.org/doc/draft-cheng-spring-shorter-srv6-sid-requirement/>
and
welcome comments and suggestions. If those interested in the topic agree
that the use case for a shorter SID in SR over IPv6 is practical, then
there may be not much use in discussing the above-mentioned draft and we
can proceed to the analysis of the proposed technical solutions. And to
your list, I'd like to add draft-mirsky-6man-unified-id-sr
<https://datatracker.ietf.org/doc/draft-mirsky-6man-unified-id-sr/> that
has been presented to 6man (don't recall presenting it to SPRING). Since
we're going to have another series of virtual interim meetings, perhaps one
can be planned for the discussion of this topic - shorter SID in SR over
IPv6.

Regards,
Greg

On Tue, May 26, 2020 at 11:03 AM stefano previdi <stefano@previdi.net>
wrote:

> Hi Ron,
>
>
> > On May 26, 2020, at 6:25 PM, Ron Bonica <rbonica@juniper.net> wrote:
> >
> > Stephano,
>
> /ph/f   ;-)
>
>
> > The drafts that you mention below can be categorized as follows:
> >
> > - those that are entirely independent of the SRv6 architecture
> > - those thar are entirely dependent upon the SRv6 architecture
>
>
> I don’t disagree but, in my humble view and opinion, the 4 mentioned
> drafts aim to the same objective which is related to the size of the
> routing header (whatever flavor) containing the segment list.
>
> I really wish that 6man will take time to review and process all these
> proposals before calling for adoption individual ones. Ideally, we
> shouldn’t standardize competing options or, at least, we should try to
> rationalize the spectrum of available solutions.
>
> You argument about architectural linkage is very welcome to be discussed
> during this evaluation process (well, in fact it looks it’s already well
> discussed ;-)
>
> Let’s keep the door open and let’s bring _all_ the options on the table
> before jumping to conclusions. An adoption today would give the message
> that one option is already the preferred one. This, I think, it’s not
> reflected in the state of the discussion.
>
> For all these reasons I still don’t support the adoption of
> draft-bonica-6man-comp-rtg-hdr.
>
> Thanks.
> s.
>
>
>
> > The CRH falls into the first category because it does not rely upon
> instructions being encoded in the IPv6 destination address. It assumes RFC
> 4291 address semantics.
> >
> > All of the other drafts rely on some special interpretation of the IPv6
> address. Either:
> >
> > - The IPv6 address includes an instruction that describes how subsequent
> routing headers are to be processed
> > - The IPv6 address represents a path instead of an interface
> >
>
> > For that reason, it makes sense to:
> >
> > - progress the CRH draft, independently of SRv6
> > - let the SPRING WG evaluate the other drafts and send one of them to
> 6man.
> >
> >                                                                       Ron
> >
> >
> >
> >
> >
> >
> >
> > Juniper Business Use Only
> >
> > -----Original Message-----
> > From: ipv6 <ipv6-bounces@ietf.org> On Behalf Of stefano previdi
> > Sent: Tuesday, May 26, 2020 9:40 AM
> > To: Bob Hinden <bob.hinden@gmail.com>om>; IPv6 List <ipv6@ietf.org>
> > Subject: Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"
> >
> > [External Email. Be cautious of content]
> >
> >
> > Hi,
> >
> > As author of the original SRH proposal, I follow with quite some
> interest the discussion around the need of compression of the segment list.
> At this stage I see at least 4 proposals, each of which brings some valid
> and interesting arguments:
> > . draft-bonica-6man-comp-rtg-hdr
> > . draft-decraene-spring-srv6-vlsid
> > . draft-lc-6man-generalized-srh
> > . draft-filsfils-spring-net-pgm-extension-srv6-usid
> > . (maybe there are more...)
> >
> > Also, it looks to me that the ongoing discussion is focused only on one
> of the above. Are we going to re-spin the same debate for each of these or
> do we want the WG to conduct an analysis on all of them prior to select one
> (or maybe two) that would be candidate for adoption ? Certainly, I’d prefer
> the latter.
> >
> > So, at this stage I don't support the adoption of
> draft-bonica-6man-comp-rtg-hdr and would prefer to see the WG to start an
> exhaustive analysis on all of the proposals.
> >
> > Thanks.
> > s.
> >
> >
> >> On May 16, 2020, at 12:13 AM, Bob Hinden <bob.hinden@gmail.com> wrote:
> >>
> >> 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://urldefense.com/v3/__https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr__;!!NEt6yMaO-gk!S1aUaf8ierFVerfLLA2pLHDrMNPcbbuXLHgUr_2D-ggrgxdFATJJn5IQ8I19DrKX$
> >>
> >> 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
> >>
> >>
> >> --------------------------------------------------------------------
> >> IETF IPv6 working group mailing list
> >> ipv6@ietf.org
> >> Administrative Requests:
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!S1aUaf8ierFVerfLLA2pLHDrMNPcbbuXLHgUr_2D-ggrgxdFATJJn5IQ8DARFpA5$
> >> --------------------------------------------------------------------
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests:
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!S1aUaf8ierFVerfLLA2pLHDrMNPcbbuXLHgUr_2D-ggrgxdFATJJn5IQ8DARFpA5$
> > --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>