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

"Ketan Talaulikar (ketant)" <ketant@cisco.com> Thu, 28 May 2020 12:07 UTC

Return-Path: <ketant@cisco.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 5BEB93A0DA4 for <ipv6@ietfa.amsl.com>; Thu, 28 May 2020 05:07:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.598
X-Spam-Level:
X-Spam-Status: No, score=-9.598 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=awrxErou; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=FVi2+9C1
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 48GJL2A2JdnZ for <ipv6@ietfa.amsl.com>; Thu, 28 May 2020 05:07:02 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 122063A0CB9 for <ipv6@ietf.org>; Thu, 28 May 2020 05:07:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11968; q=dns/txt; s=iport; t=1590667622; x=1591877222; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=FxLppFL8qG3+6ZDckqou839xKfJ3ZQIwBkCMhD5Z480=; b=awrxErouLnY32vkHBNp1wVglC7o2aXHNqbma1A2h+w6z3WSDKZEtX+5W Ds6OvXeAWwckJ709+3eomMZ6sHFzJ8lDdIzGvOm2gRVLPOzLaXmJykgA6 J/prAO+coUCSpmpiOmc1p//WiUZF6IHq46m3sNDhmZuonqoS5k/zCYNEA M=;
X-IPAS-Result: =?us-ascii?q?A0DKCQDyqM9e/5xdJa1mHgEBCxIMQIMaUgdvWC8sCoQbg?= =?us-ascii?q?0YDjT6JfY5LgUKBEANVCwEBAQwBARgGDwIEAQGERAIXggQCJDgTAgMBAQEDA?= =?us-ascii?q?gMBAQEBBQEBAQIBBgRthVcMhXIBAQEBAwEBEAsGBA0MAQEsDAsEAgEIEQQBA?= =?us-ascii?q?QMCIwMCAgIfBgsUAQgIAgQBEggMBweDBYJLAy4BDqQVAoE5iGF2fzODAQEBB?= =?us-ascii?q?YE2AoQDDQuCDgMGgQ4qgmSJYBqBQT+BEAFDgU9+PoIeSQEBAgGBLQESASMVD?= =?us-ascii?q?4JuM4Itjl+DDIZLmjxMCoJUiCuLWoR8gmSJBI8egweQV4lwgk2RLQIEAgQFA?= =?us-ascii?q?g4BAQWBaiJmcHAVGiGCaVAYDZBADBeDT4UUhQkBOHQCNQIGAQcBAQMJfItPA?= =?us-ascii?q?YEPAQE?=
IronPort-PHdr: =?us-ascii?q?9a23=3AmJO45hH4X3cAWJ1dfuMlzp1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e401QObW4LY6vsCgO3T4OjsWm0FtJCGtn1KMJlBTA?= =?us-ascii?q?QMhshemQs8SNWEBkv2IL+PDWQ6Ec1OWUUj8yS9Nk5YS8D5ZFzb5Ha16G1aFh?= =?us-ascii?q?D2LwEgIOPzF8bbhNi20Obn/ZrVbk1IiTOxbKk0Ig+xqFDat9Idhs1pLaNixw?= =?us-ascii?q?=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.73,444,1583193600"; d="scan'208";a="474458958"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 28 May 2020 12:07:00 +0000
Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 04SC70xf015298 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 28 May 2020 12:07:00 GMT
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 28 May 2020 07:07:00 -0500
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 28 May 2020 08:06:59 -0400
Received: from NAM10-MW2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 28 May 2020 08:06:59 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=H8bfMa5qHDcJpgU/697YgpRhms5ZaNJ4a2bGe8rwkVwsYyW4rHpZstg25QHSCPumNHa5HpTANkcI4Is9Tlvsj6T06R/RARFqEknu9W3MpZEPGHfqeectBaRpVoRzqI8gA4g/Cxgu2N+xNoHRH36H1gFGgSOeGOELM0TM8SxFrDHFwFI/7JMs2ecpWjzFQhLEBKn/1AUll4tRT7pWhudoNikWPsWrJE+Kt7agnnSY3KkvPb7djG1UUIGdKHuR3vX4eYLFaJz3beyQ0g9YYdRByo0w/KplxYFS2+dGwoXuvLavYh1x8WjiHimnrPB4b2jHaWd+xMGWot1ZfmgAqFkRdQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FxLppFL8qG3+6ZDckqou839xKfJ3ZQIwBkCMhD5Z480=; b=ewzlvOMSSwhxNLxTKolQMUiT39zrnbUf4haSG45uz86nTrtwjdOOQ7s4xOabnpfwUc+MB757/3zclTqkE+YuJZPh/0OGW3m2pLRWKs7L4ozbTYBy8ezUd99tsdhGSW+x2eOcnWvFL2lQ22sEkIeraDQj+cXXluFH2FNYexHINru2DSPLSIPlhk+2oIyxUm4TFaFQy56o0rkBvDBsVA52EfgZXqVOPhg7Si3M0Byz2ytmeJXtCzJyOWRZsahLFFsiOrMPWk+1SMM1na4iWNtVQ7uCyBmcP8mqlDitCZerJStjJX+DwkTuIJQBystBTkIlaLRbioCtNGdag62y8lpJYA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FxLppFL8qG3+6ZDckqou839xKfJ3ZQIwBkCMhD5Z480=; b=FVi2+9C1/88eZsD/4YYmw64Hmp+oO0QFIn2EJxF7TaN4CuIeuzpP+XlU+uojxrfdvQLv4gp+M9lZkwJRx67g0O+Xnpf1zTaeQhlPBeDa0xdft9PKNfKewBx1Ko/3MpIDa0JDo2Wtt8ZiULvcokPpqZC7eFJB8QKOk7ypqrt2gXw=
Received: from SA0PR11MB4576.namprd11.prod.outlook.com (2603:10b6:806:97::10) by SA0PR11MB4608.namprd11.prod.outlook.com (2603:10b6:806:94::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3045.19; Thu, 28 May 2020 12:06:57 +0000
Received: from SA0PR11MB4576.namprd11.prod.outlook.com ([fe80::89ab:9438:36b9:5db2]) by SA0PR11MB4576.namprd11.prod.outlook.com ([fe80::89ab:9438:36b9:5db2%9]) with mapi id 15.20.3045.018; Thu, 28 May 2020 12:06:57 +0000
From: "Ketan Talaulikar (ketant)" <ketant@cisco.com>
To: "Henderickx, Wim (Nokia - BE/Antwerp)" <wim.henderickx@nokia.com>, "Ron Bonica" <rbonica@juniper.net>, Mach Chen <mach.chen@huawei.com>, Bob Hinden <bob.hinden@gmail.com>, IPv6 List <ipv6@ietf.org>, Gunter Van de Velde <gunter@vandevelde.cc>
Subject: RE: Adoption Call for "The IPv6 Compact Routing Header (CRH)"
Thread-Topic: Adoption Call for "The IPv6 Compact Routing Header (CRH)"
Thread-Index: AQHWKwY4liJdYnMUi0GCGHFn1Ke91ai7RfcAgAAS2oCAAAFVgIAAzpwAgAAO34CAAUDO0A==
Date: Thu, 28 May 2020 12:06:57 +0000
Message-ID: <SA0PR11MB45769A225AF1D397F5FC6CDDC18E0@SA0PR11MB4576.namprd11.prod.outlook.com>
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> <DM6PR05MB6348774631CF80254B710B7AAEB10@DM6PR05MB6348.namprd05.prod.outlook.com> <BB90338D-B528-4F16-A0FC-7FAC451A0017@nokia.com>
In-Reply-To: <BB90338D-B528-4F16-A0FC-7FAC451A0017@nokia.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2020-05-27T03:32:20Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=7d82697e-020a-4d6e-924b-e8fc799bf107; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2
authentication-results: nokia.com; dkim=none (message not signed) header.d=none;nokia.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [72.163.220.15]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: d01103b8-b7a4-4754-9726-08d802ff9eb1
x-ms-traffictypediagnostic: SA0PR11MB4608:
x-microsoft-antispam-prvs: <SA0PR11MB4608A9B4DEF90277D8EEA2A4C18E0@SA0PR11MB4608.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:4714;
x-forefront-prvs: 0417A3FFD2
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: rzPvg1yncD69OJPUZp+61nP8RFAZ70vSEYfhOywaN8l3YoFCrppZaweLik2m+lV8r2PhxvU75lemVPf1mlhWM+qZ9cN0OaHVKbIQC8LiBVPcrRg527YNytZ5MeXEiQsGt7MWSRa68FYwwaIhD5MHY397LjPUSYsfNOnNmEUzpnJ9qxHpT2lMBSc5Vixc5fKJBhNoGlUSJlc/Z1oDj9juqt44zFlxyerknioI5ndIqBo65xCIxToqMUTv28z+LinQZCMf+APIrW8QO8mMG0DOa0FeJDVarpAj/R4N9CA7mCF04+ZMpEgDghFFjIXtPxlttiLUwV6Gt9j0zpeMBeDTNPxQiKM2JnsuzxGK4+nhJthQUAZY63wHnzihueOvFNaFG+HBm/cKCu399KRcZMPJrg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SA0PR11MB4576.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(376002)(396003)(136003)(39860400002)(366004)(33656002)(76116006)(8936002)(66946007)(26005)(316002)(8676002)(7696005)(110136005)(53546011)(6506007)(83380400001)(52536014)(9686003)(2906002)(55016002)(66476007)(64756008)(66556008)(66446008)(71200400001)(296002)(86362001)(5660300002)(478600001)(186003)(966005); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: H8gWE999hCIDOmlDxwvTeBIBJoic/mUQ/0iF3w0A/2juJDyHj0aRosKVqflhxCdyHOqL665/1sgcWHoFDFHu58ARs+fSJwvYeRLn9FbIMg1Xb5GrCssqRvRzRVOgCKUZcbzV2+YvEejskln+S/hH0TzHb6ZO+A2a1QhR1QFW3UewS+BO4lz9K/Kez8ynVVYMLL3p9uk7waxuJB3NlkUhoH1cJ9G4ECexO8HB8NHvMDPGNc9UaFakJNuTQscDzi8L/fFA9RUqMmZk23kYOmgd4LPdpVCTOawHFFRUkfBD70strsKDJtS0NdrD/eZz64q1/nuAo9Mh3ZZVEXeHggXqrDF3T6yPKS25a6ZGKOysRFPyrn4TFtzsZ2marL/xPeeqfOCHY7mg5pzChIXaL0fpSY8yB1Aswfvx2ugPSLSH4X/wzF+EVQjdiW0bLKwbitdGEqdKLj2mJNYRH3sUkKV5WaRdIeIzjRDbaeDcDz+W1J5H64bDIbk2v+F0v0yOhLrK
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: d01103b8-b7a4-4754-9726-08d802ff9eb1
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 May 2020 12:06:57.3527 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: fV6Gqxky0Op7PWiDqgMpp09Y7NyvAOyUe0TwmBnWsfDpeBoa0DG+MncLOjP9pkmxJZ9qA3yaKrVUPLmUUSIGmw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR11MB4608
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com
X-Outbound-Node: rcdn-core-5.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/JKxr5eBxRtqBJ6b_V8omO0nhe_E>
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 12:07:04 -0000

I fully agree with what Wim has shared below. While this may be new to 6man, it has been previously stated by multiple participants at Spring WG meetings and shared with the proponents of the CRH proposal.

Segment Routing solution for IPv6 have been specified by the IETF to address these use-cases. 

https://tools.ietf.org/html/draft-filsfils-spring-sr-mpls-ipv6-control-plane-02 

I agree that it is better done with a well-known mapping technology (i.e. MPLS) than reinventing the wheel.

Thanks,
Ketan

-----Original Message-----
From: ipv6 <ipv6-bounces@ietf.org> On Behalf Of Henderickx, Wim (Nokia - BE/Antwerp)
Sent: 27 May 2020 22:20
To: Ron Bonica <rbonica@juniper.net>et>; Mach Chen <mach.chen@huawei.com>om>; Bob Hinden <bob.hinden@gmail.com>om>; IPv6 List <ipv6@ietf.org>rg>; Gunter Van de Velde <gunter@vandevelde.cc>
Subject: Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

Ron, the misconception that many people have is that RFC 8663 is requiring MPLS in a traditional way. As I mentioned RFC 8663 allows to do the same as what you are trying to do with CRH. The difference is that the traffic steering would use the bits in the next-header iso extension header and that's it.

The addressing as you highlighted is the same, no difference there; full RFC 4291 IP Address semantics. 
Some misconceptions:
- I need to run MPLS protocols for this. Answer is no.
- RFC 8663 does require UDP. Answer is no. You can use native RFC4023 which is not using UDP e.g. and you have the option to use native IP or with GRE encap, but to compare it against CRH use native ipv6 in RFC4023

Now to beauty of using RFC 8663 mechanism is that you don’t have to reinvent things in a new framework and new capabilities will be supported natively. Look at SFC, G/L-SID(s), OAM, etc etc.

So it allows also many scenario's like below. On top interworking with MPLS comes for free. Here are some examples.
- IP <-> IP <-> IP (e.g. CRH scenario)
- IP <-> MPLS <-> IP (e.g. scenario used in some DC(s) who want to leverage SR to compute)
- MPLS <-> IP <-> MPLS (e.g. interconnection networks across MPLS/IP links)

Given all of this, we should use the RFC 8663 for the use case you try to address here

On 27/05/2020, 17:56, "Ron Bonica" <rbonica@juniper.net> wrote:

    Wm, Mach, Gunter,

    Certainly you are not suggesting that:

    - IPv6 doesn't need a native traffic steering mechanism
    - All IPv6 applications that require traffic steering must rely on MPLS in some form (SR-MPLS over IP, MPLS over IP)

    If you were making this argument, wouldn't it apply to all Routing headers, including the SRH?

    There are a class of operators who:

    - Cannot deploy MPLS on some nodes that need to be segment endpoints
    - Would rather use the IPv6 Flow Label for load balancing than the UDP source port (as recommended by RFC 8663 via RFC 7510)

                                                                      Ron



    Juniper Business Use Only

    -----Original Message-----
    From: Henderickx, Wim (Nokia - BE/Antwerp) <wim.henderickx@nokia.com> 
    Sent: Tuesday, May 26, 2020 11:37 PM
    To: Ron Bonica <rbonica@juniper.net>et>; Mach Chen <mach.chen@huawei.com>om>; 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]


    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://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!QPUACt0y0m2WX2yQLbQraSGY4XAwZtROjp2esEmPZkcRW1pPY_Y6WykKXptMvNOl$
        --------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------