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

Greg Mirsky <gregimirsky@gmail.com> Wed, 27 May 2020 18:38 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 D0D633A083B for <ipv6@ietfa.amsl.com>; Wed, 27 May 2020 11:38:45 -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=unavailable 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 WLNtDaDbJ5B6 for <ipv6@ietfa.amsl.com>; Wed, 27 May 2020 11:38:44 -0700 (PDT)
Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 9E4CB3A0811 for <ipv6@ietf.org>; Wed, 27 May 2020 11:38:43 -0700 (PDT)
Received: by mail-lj1-x22c.google.com with SMTP id z6so30156761ljm.13 for <ipv6@ietf.org>; Wed, 27 May 2020 11:38:43 -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=l7Oy/+MC2vSr86MW8K5r+cr1xmbXzB5PUX3GgK4Vbds=; b=LXgC1D2iEz/WALbBxRnkkjiyLPozgSJ3kdPE5It2YS/Tl2G+ExpLrMo+e+SFeSZo6W QXXkirINxx+I/QSZ56i1RssIdbjifmgAPXIbW+ar1wt1petwZbLNZChRvnjudqNIvTOt dSXJOIR7XSJrfPbK2sruXzHPHp76HFYSVfa8WF0EUrx+8XSYXIJFLTKzh58NphG79L24 79dzaDT5piioBW+p/v04We2sXzdsC7IYP5JVGPT30zJEQCWy3NdrbREZoxQ1FuBc6m4+ uJw1a9sZhB3T3h1nOojpb+x6xd+N25TArynAVROXMwUHr+mB8YNBE/0LoRsqkHkB9/8L 3CZA==
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=l7Oy/+MC2vSr86MW8K5r+cr1xmbXzB5PUX3GgK4Vbds=; b=RhMhX+V/oxZ72E0VY1Ij98o/frQoTXobYz4XDmacXqOILF6aH6Ht6aSkBN82NsehDT oKq1BE4M5NBOITjR/fpkXgfdYe/kS+37c5fXX/fuWyNRdzBx3caahzBYEwTct8Wnn1wg PihEKzcjX46pwXgMZ7SibTcHcs3Av1xin8xReBJPioFXv62DTLndOLMIcZFjh+0LolSF IETA9taXN9AAmNqNDciQIaa9B6NjaECHWcpxKeWhdGswp/hKbQ8IFAS6yTaJfhCD+oYz dzmG2VcvPIcH7p/cOeVYoMVhBBuUX07b9JAnJ8wbzjjBViEcd47l/JnBakfhj1E/f9u0 utYQ==
X-Gm-Message-State: AOAM532B0ZwFfUUjT/1fPdJ1d8WpA7xKA1gdnG6CsekvewBg+D+Uxsut AsEJ29K/1S1bPXM+w78JR5UVjoxWvWCs0ecQmzk=
X-Google-Smtp-Source: ABdhPJxNhBUJhrB2BE2kNMEI7YzycWEMSJbkCf8Vc5CH0Rwz6MjWsgRF/3KLjJ4swe4za7Fw0wlGqW3/zMxy9+UWDKA=
X-Received: by 2002:a2e:b17b:: with SMTP id a27mr3944931ljm.288.1590604720464; Wed, 27 May 2020 11:38:40 -0700 (PDT)
MIME-Version: 1.0
References: <19D30186-B180-4F65-BF00-7AD07CEF3925@gmail.com> <F73A3CB31E8BE34FA1BBE3C8F0CB2AE297BA004D@dggeml510-mbs.china.huawei.com> <DM6PR05MB634882796C9EC3E64A4B1000AEB10@DM6PR05MB6348.namprd05.prod.outlook.com> <356D8A36-510A-43B8-8492-49FDE67BC5C4@nokia.com>
In-Reply-To: <356D8A36-510A-43B8-8492-49FDE67BC5C4@nokia.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Wed, 27 May 2020 11:38:28 -0700
Message-ID: <CA+RyBmX-OvPVyj6g1833VBx-Spm6m091yoWfRBkBVe5icLZhFg@mail.gmail.com>
Subject: Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"
To: "Henderickx, Wim (Nokia - BE/Antwerp)" <wim.henderickx@nokia.com>
Cc: Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>, Mach Chen <mach.chen@huawei.com>, Bob Hinden <bob.hinden@gmail.com>, IPv6 List <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000057663f05a6a58522"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/GFHMfRZOhKXszwEYGq5C170ih1E>
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: Wed, 27 May 2020 18:38:46 -0000

Hi Wim,
the use of EH brings one benefit, important in my opinion, for OAM -
preserving the path information. MPLS-over-IP, a.k.a., RFC 8663 does not
preserve the path traversed information. Of course, it is not critical for
getting packets from ingress to egress but is useful in troubleshooting,
fault localization, and performance measurement.

Regards,
Greg

On Tue, May 26, 2020 at 8:37 PM Henderickx, Wim (Nokia - BE/Antwerp) <
wim.henderickx@nokia.com> wrote:

> Ron, as I mentioned in another thread, RFC8663 does this. Same addressing
> mechanisms as you highlight and is equally compressed (comparing 32 bit)
>
> On 27/05/2020, 05:32, "ipv6 on behalf of Ron Bonica" <
> ipv6-bounces@ietf.org on behalf of rbonica=40juniper.net@dmarc.ietf.org>
> wrote:
>
>     Mach,
>
>     The CRH is unique in the following respect. It does not rely on an
> instruction or a path being encoded in the IPv6 Destination Address. It
> relies only on RFC 4291 IP Address semantics.
>
>     Can you show me another IPv6 traffic steering solution that:
>
>     - is equally compressed
>     - does not rely on an instruction being encoded in the IPv6
> destination address
>     - does not rely on all endpoints being numbered from the same IPv6
> prefix
>
>
>                             Ron
>
>
>
>     Juniper Business Use Only
>
>     -----Original Message-----
>     From: ipv6 <ipv6-bounces@ietf.org> On Behalf Of Mach Chen
>     Sent: Tuesday, May 26, 2020 10:25 PM
>     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]
>
>
>     If the draft intents to provide a mapping based Segment Routing
> solution, there are SR-MPLS, SR-MPLS over IP exist, and there are
> implementations that work very well; seems no need to define a new one;
>
>     If the draft intents to provide a header compression solution to SRv6,
> there are several candidate solutions under discussion; seems it's
> premature to consider just adopting one and ignoring others;
>
>     If the draft intents to be one of the building blocks of a new
> competing IPv6 based Segment Routing solution, given the community has been
> working on SRv6 for so many years, it needs to prove that the new solution
> has much better merits than SRv6;
>
>     So, based on the above, I do not support the adoption at this moment.
>
>     Best regards,
>     Mach
>
>     > -----Original Message-----
>     > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Bob Hinden
>     > Sent: Saturday, May 16, 2020 6:14 AM
>     > To: IPv6 List <ipv6@ietf.org>
>     > Cc: Bob Hinden <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://urldefense.com/v3/__https://tools.ietf.org/html/draft-bonica-6
>     >
> man-comp-rtg-hdr__;!!NEt6yMaO-gk!RFfjmZf_NdYDfA4BeXQjkrOe5nDx8fFfYnrJ8
>     > UyCSeGfcx_3QbeQW7FjgwyIXhFe$
>     >
>     > 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!RFfjmZf_NdYDfA4BeXQjkrOe5nDx8fFfYnrJ8UyCSeGfcx_3QbeQW7Fjg-IpFdTb$
>     --------------------------------------------------------------------
>
>     --------------------------------------------------------------------
>     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
> --------------------------------------------------------------------
>