RE: CRH "mapping table" and OAM - Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

Linda Dunbar <linda.dunbar@futurewei.com> Tue, 26 May 2020 17:10 UTC

Return-Path: <linda.dunbar@futurewei.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 33BCD3A0A3E for <ipv6@ietfa.amsl.com>; Tue, 26 May 2020 10:10:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.989
X-Spam-Level:
X-Spam-Status: No, score=-1.989 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, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.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 UKN9QyfDu7qF for <ipv6@ietfa.amsl.com>; Tue, 26 May 2020 10:10:50 -0700 (PDT)
Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2101.outbound.protection.outlook.com [40.107.236.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 043303A0A47 for <ipv6@ietf.org>; Tue, 26 May 2020 10:10:49 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DCjK4vuw+67WTToMx5I5LtQBj8yJe+Ut3JqA8eYwe/yqp7BI+X976uu2L3q5nlvbIEfI3ppnYsS5+E1ceQF0r2mhhd4vkHD6CvkdLqGKRGUBtxd0QGiCmuPoSxrt3XaZ7VqtD4+g842cNs75Ts2oz0+HbjXkJVc0/I/9F5cmik2xmxvQ5LV8Lcy499z9rZiIyIuwKu+7cqSQ8GzfQYZOgJGMeTpV9WfFqQ1i2jdXPusXbXa4lotiAOf2XXPLkTgKcKIrit35zIU7eJ1Sgr8fSfRKwAbdSUi+lRe1VQB9GUwVlWTMmqX+54xWhZb77KFgiwGEJetOCFxkR5jdxdq6qA==
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=TynG+4pw+cKqLKUG7kQSe0NZObq/UYu+ng637FyEgT0=; b=M+n1DCrxcq8rC3WhMGkmLMWHxyk4zRMzwyBUo6r7iJHYH5rR/3iE3CKJ/OurbB21/u0jSeOH4Wp0MbuwA2FJKQFXfm9x0GG6cYMK5yF3zxO4mOiLGcXP5mrgPOTrJBmgxOk6o/sK+JmEVbfLKww4VODAKluO242Pc25p+WWBi2jZ/bnE57aibcKUqFYIppyxnZs6NGAShfgzl05iUUYX2EzY3KQY5FusLUyytex05RowTp5oqB4+EpLzPtkeuKLXsmr6ko2hI7RFN7zj5xO7LW2mL9jEu1zQK8lw3uSw5PhEQ2tcuKape8bgZjyiUDHqa5uSr3SkSIriKauofH0+BA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TynG+4pw+cKqLKUG7kQSe0NZObq/UYu+ng637FyEgT0=; b=UbuzltdYa/8+bb2S2eqCfWXXt0PwXRsEFNJ9ExpuCxIxe/U/0E/15BDUqsz1kCMR1IGarRcP6m+GiNFUNq9UAGXS4aOkLi4XxAzQGr87bZtjgfq6PxaIDQ1PfI0+9mWRw+TyaxMvLN4Z9RuMNZ8dti3st5giTWW/EezHsSABk6s=
Received: from SN6PR13MB2334.namprd13.prod.outlook.com (2603:10b6:805:55::16) by SN6PR13MB2397.namprd13.prod.outlook.com (2603:10b6:805:53::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3045.9; Tue, 26 May 2020 17:10:46 +0000
Received: from SN6PR13MB2334.namprd13.prod.outlook.com ([fe80::7813:cef6:bbde:1970]) by SN6PR13MB2334.namprd13.prod.outlook.com ([fe80::7813:cef6:bbde:1970%5]) with mapi id 15.20.3045.013; Tue, 26 May 2020 17:10:45 +0000
From: Linda Dunbar <linda.dunbar@futurewei.com>
To: Robert Raszuk <robert@raszuk.net>, Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>
CC: "Darren Dukes (ddukes)" <ddukes=40cisco.com@dmarc.ietf.org>, Bob Hinden <bob.hinden@gmail.com>, IPv6 List <ipv6@ietf.org>
Subject: RE: CRH "mapping table" and OAM - Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"
Thread-Topic: CRH "mapping table" and OAM - Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"
Thread-Index: AQHWMyXyEOUgfmORcUGMQx/5+Q5thai6c4YQgAAV5gCAAA3MUA==
Date: Tue, 26 May 2020 17:10:45 +0000
Message-ID: <SN6PR13MB23349C2A47C5C1A00E33CDDD85B00@SN6PR13MB2334.namprd13.prod.outlook.com>
References: <759F2FDB-C5ED-4FFA-9983-AE5D201E7CC5@cisco.com> <DM6PR05MB63480B378F943AA6B29A0CD8AEB00@DM6PR05MB6348.namprd05.prod.outlook.com> <CAOj+MMFC2pGuajw+bxRXJen634QLoAOV1ibNciJ3mgybb7TS9w@mail.gmail.com>
In-Reply-To: <CAOj+MMFC2pGuajw+bxRXJen634QLoAOV1ibNciJ3mgybb7TS9w@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: raszuk.net; dkim=none (message not signed) header.d=none;raszuk.net; dmarc=none action=none header.from=futurewei.com;
x-originating-ip: [72.180.73.64]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 099bba35-b51a-47a0-e86b-08d80197bad3
x-ms-traffictypediagnostic: SN6PR13MB2397:
x-microsoft-antispam-prvs: <SN6PR13MB239744870E602FF660F5C7EB85B00@SN6PR13MB2397.namprd13.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:3276;
x-forefront-prvs: 041517DFAB
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: myBMVw2bWBrJjmhRRYQ/Y6amFsdhi4WfCktsq/EOPn19PlwbNVLk3bxgkjVSbHFYv1EmtpytRS/IYKeaaO3QUH9XnDVArCVImceegNM6uNxvNDQzFL26WozUHYmFODHWOiaVBgUyZoBHx1T/NlSKQMQEjeP5JVO+TPiHIco9irW+O9fvoFhNVKdZGuULAAPqVTnb8YugXG+/+W10q4xhnDtmJRxVMB21YUBRyQPtJZ8L6OUnWPMGACJ+7niT5g+G7BDlXucMEg/69jwp5GYLlwcRynHvkz2akv4xjkS2LePJ+9FLek87ia5GcPPWSDIrw14d1udUKeiJsZ5kEGqtIepgzzHjvfXF/QpRQqeXv8zjZ7RsaUym74iokiM6Wm+Qh6cLlIDeECR5PCPcEg5cfQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN6PR13MB2334.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(346002)(376002)(396003)(136003)(39840400004)(76116006)(66446008)(66946007)(55016002)(9686003)(71200400001)(66556008)(66476007)(64756008)(166002)(316002)(6506007)(53546011)(54906003)(4326008)(26005)(5660300002)(966005)(8676002)(8936002)(186003)(478600001)(86362001)(7696005)(110136005)(33656002)(2906002)(44832011)(52536014); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: cnShY8w915F2nMl58ZCj9QmJXr1EGJhqae+VmweLVx0mvb7YNmy0+AB8MXWeYwGVLeifFiChcBi7qnpTLhIhT3kNCmjXCc3FIV+0NOZW6mwHrLeM1b7eYAxzhhC2yyTgMaNFO17TDXc7csqoYugVuIhqSJzoiVNEHXlH40KsSQj1qBlXp62BTIL8oUIfbkj/vBI72pRFxB0XXFNibvYlSQ8j/KU8zPDd1gAb3H2DEwYPvCIpaAxkxnBZN71yuXWW9mrzdX0KDhQD/aG1cNe+ncG0KXU6gkLSuz5pDuR3pSJIk7QrVrAsoqgv1F/oGkKr7fg6sE1aU8nQ44BSmiHagjziJylhzkmUipACX/kEg+zskrjGstOzJf2vHDh+1ZXT+jjiNxAkrG1p6d+5wifU1vmiARVQ+eRYQxmFJmoElGwLry7cGMH3g1jvERcJg/GIU45lechmdCjmid9Hn07c30iaD0VOKeoaHnuFdC6diFo=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_SN6PR13MB23349C2A47C5C1A00E33CDDD85B00SN6PR13MB2334namp_"
MIME-Version: 1.0
X-OriginatorOrg: Futurewei.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 099bba35-b51a-47a0-e86b-08d80197bad3
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 May 2020 17:10:45.7465 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Hnx+Z1Wwem3ibI1+USDBkfEiXt2CfYFrqdHG+GCbK158USK2JiCUHBubX2dgqpbkrkZ7Rj9mzSOXwQMiL0TJTQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR13MB2397
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/tt1xTkbS70axF2YfSHe0hAUctLc>
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 17:10:54 -0000

Thanks for Robert’s example.

In addition, Mapping Table based solutions usually don’t scale well.

There are many documents in SPRING WG to extend the SRv6 solution ([RFC8402]) for the specific purpose of minimizing the MTU overhead and/or supporting very long SID-lists on legacy hardware. It seems to me that CRH is just another solution. If not compatible with others, is there any benefit of having another solution?

Linda Dunbar
From: ipv6 <ipv6-bounces@ietf.org> On Behalf Of Robert Raszuk
Sent: Tuesday, May 26, 2020 11:08 AM
To: Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>
Cc: Darren Dukes (ddukes) <ddukes=40cisco.com@dmarc.ietf.org>; Bob Hinden <bob.hinden@gmail.com>; IPv6 List <ipv6@ietf.org>
Subject: Re: CRH "mapping table" and OAM - Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

Ron,

"just works" is great. But let's zoom in and explore how it works in practice.

Imagine on ingress PE I am mapping to engineered north CRH path flows using TCP dst port 80 dst IPv6 X::Y

Further imagine on the very same PE I am also mapping flows using TCP port 22 going to IPv6 dst X::Y to take south CRH path via my network.

Then mgmt station does ICMP ping  and traceroute  ... and it wants to ping and trace from this PE over both paths. What are the four commands I would use ?

Many thx,
Robert.







On Tue, May 26, 2020 at 5:15 PM Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org<mailto:40juniper.net@dmarc.ietf.org>> wrote:
Zafar,

Tracing the path of an IPv6 packet containing CRH is somewhat easier than tracing the path of an MPLS LSP. In order to trace the path of an MPLS LSP, you need to deploy either RFC 4950 or RFC 8029. However, you don’t need to deploy anything special to trace the path of an IPv6 packet that contains CRH. Traceroute just works.

Furthermore, when you trace the path of an IPv6 packet that contains CRH, each node returns either an ICMP Time exceeded message or an ICMP parameter problem message. From those messages, you can infer contents of the CRH-FIB at each node. So, there is no need for a special OAM mechanism to query the CRH-FIB.

                                                                                                             Ron




Juniper Business Use Only
From: Zafar Ali (zali) <zali@cisco.com<mailto:zali@cisco.com>>
Sent: Tuesday, May 26, 2020 2:22 AM
To: Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>>; Ron Bonica <rbonica@juniper.net<mailto:rbonica@juniper.net>>
Cc: Bob Hinden <bob.hinden@gmail.com<mailto:bob.hinden@gmail.com>>; IPv6 List <ipv6@ietf..org<mailto:ipv6@ietf..org>>; Darren Dukes (ddukes) <ddukes=40cisco.com@dmarc.ietf.org<mailto:40cisco.com@dmarc.ietf.org>>; Zafar Ali (zali) <zali@cisco.com<mailto:zali@cisco.com>>
Subject: CRH "mapping table" and OAM - Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

[External Email. Be cautious of content]

Hi,

I agree with Greg. OAM is not only ping/traceroute.

The CRH “mapping table” also bring additional operation complexities and hence need for OAM tools to debug.

Even for the use of Traceroute in a CRH network, I would like to remind Ron of the following email thread.
https://mailarchive.ietf.org/arch/msg/spring/YA_WW7w1xp5aRBpModqMdoF5vTU/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fspring%2FYA_WW7w1xp5aRBpModqMdoF5vTU%2F__%3B!!NEt6yMaO-gk!WbC9uTY5VNVXPVe2D0Y1GtlupaWhs5jlj8ZwtFCmvNNLZaxU_04lGDrcckxlUnJI%24&data=02%7C01%7Clinda.dunbar%40futurewei.com%7Cef70a9c2ec6f483d3f7908d8018f189d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637261061408927812&sdata=IwKnYtn9NjM%2BJ%2Fg0ZYI0JjIe8B0CggcWAKYC0%2BjLKSM%3D&reserved=0>


“[RB] In reality, the debuggability characteristics of SRv6+ are very similar to those of SR-MPLS.. We have the same mapping from a short identifier (SRv6+ SID or SR-MPLS Label) to an IPv6 address.
[RB] So, would you like to argue that debuggability is a huge issue in SR-MPLS?

[ZA] Not at all. SR-MPLS uses MPLS OAM tool kit defined in https://tools.ietf.org/html/rfc8029<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Ftools.ietf.org%2Fhtml%2Frfc8029__%3B!!NEt6yMaO-gk!WbC9uTY5VNVXPVe2D0Y1GtlupaWhs5jlj8ZwtFCmvNNLZaxU_04lGDrccvQJcKGT%24&data=02%7C01%7Clinda.dunbar%40futurewei.com%7Cef70a9c2ec6f483d3f7908d8018f189d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637261061408937769&sdata=U%2B1F9AhJGoiFL8nA2JCJoocAfhWxolNgqabWb%2FHbziU%3D&reserved=0>.
[ZA] Are you suggesting you will introduce something similar to RFC8029?”


Ron then responded with the need for extending RFC 5837 (which is essentially bringing SR-MPLS OAM tool kit for IPv6).


This is not surprising as CRH is just a poor re-engineering of SR-MPLS Data Plane with IPv6 Control Plane [RFC8663].

Thanks

Regards … Zafar

From: ipv6 <ipv6-bounces@ietf.org<mailto:ipv6-bounces@ietf.org>> on behalf of Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>>
Date: Saturday, May 16, 2020 at 8:46 PM
To: Ron Bonica <rbonica@juniper.net<mailto:rbonica@juniper.net>>
Cc: Bob Hinden <bob.hinden@gmail.com<mailto:bob.hinden@gmail.com>>, IPv6 List <ipv6@ietf.org<mailto:ipv6@ietf.org>>, "Darren Dukes (ddukes)" <ddukes=40cisco.com@dmarc.ietf.org<mailto:ddukes=40cisco.com@dmarc.ietf.org>>
Subject: Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

Hi Ron,
I agree that ICMP will work under CRH as it works today without it. But OAM is not only ping/traceroute. I think that there is value in checking out all known FM and PM OAM tools. Though, I would not be surprised to find out that everything works with CRH out-of-the-box way.

Regards,
Greg

On Sat, May 16, 2020, 17:04 Ron Bonica <rbonica@juniper.net<mailto:rbonica@juniper.net>> wrote:
Greg,

The question may be moot. I don’t foresee any CRH OAM work. PING and TRACEROUTE “just work”.

                                                         Ron




Juniper Business Use Only
From: ipv6 <ipv6-bounces@ietf.org<mailto:ipv6-bounces@ietf.org>> On Behalf Of Greg Mirsky
Sent: Saturday, May 16, 2020 4:24 PM
To: Darren Dukes (ddukes) <ddukes=40cisco.com@dmarc.ietf.org<mailto:40cisco.com@dmarc.ietf.org>>
Cc: IPv6 List <ipv6@ietf.org<mailto:ipv6@ietf.org>>; Bob Hinden <bob.hinden@gmail.com<mailto:bob.hinden@gmail.com>>
Subject: Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

[External Email. Be cautious of content]

Hi Darren,
I'm confused by what I think is a suggestion that any work on OAM relevant to an IPv6 EH does not belong in 6man WG. If that is what you've suggested, then what about draft-ietf-6man-spring-srv6-oam, which is in WGLC, and Ali and I are working to resolve comments? Are you suggesting that we should stop the authors of that draft find a different WG to anchor or hold the BoF? I'm puzzled.

Regards,
Greg

On Sat, May 16, 2020 at 7:00 AM Darren Dukes (ddukes) <ddukes=40cisco..com@dmarc.ietf.org<mailto:40cisco.com@dmarc..ietf.org>> wrote:
Hi Bob and Ole.

I’m not supporting the draft for adoption by 6man. I know you’re shocked ;).

I have one main concern with 6man adoption that I think many can agree with.

This draft will require substantial work related to the 16/32bit identifier (CP and OAM) that is not ipv6 nor ipv6 maintenance and for which this working group does not have a mandate nor, traditionally, expertise to drive.

Others have said “this is not 6man’s concern” and I agree because 6man is an ipv6 maintenance WG, not the segment mapping working group.  I believe the authors should find a WG with that concern to drive this work. I know starting work without requirements is fun and exciting, but you will likely end up at the wrong destination.

Brian had one suggestion on this topic.

In the past I’ve suggested SPRING, or if the authors desire, a BOF to build consensus and gather requirements for its parent SRm6 work or some variant of it.

I hope the authors, WG, chairs and AD consider these points during this adoption call.

Thanks
  Darren


________________________________
From: ipv6 <ipv6-bounces@ietf.org<mailto:ipv6-bounces@ietf.org>> on behalf of Bob Hinden <bob..hinden@gmail.com<mailto:bob.hinden@gmail.com>>
Sent: Friday, May 15, 2020 6:14 PM
To: IPv6 List
Cc: Bob Hinden
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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Ftools.ietf.org%2Fhtml%2Fdraft-bonica-6man-comp-rtg-hdr__%3B!!NEt6yMaO-gk!WxlH9jPuRZnF6DX0UIsFN2cS5t76jXU-Z3NMUNXACufRqrY7xBnnYVSulNkCsQgK%24&data=02%7C01%7Clinda.dunbar%40futurewei.com%7Cef70a9c2ec6f483d3f7908d8018f189d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637261061408937769&sdata=jX2J%2FUP6QH3kvBJHhOV3XvfIDTlRWqYTIULrKZOAUPA%3D&reserved=0>

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<mailto:ipv6@ietf.org>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fipv6__%3B!!NEt6yMaO-gk!WxlH9jPuRZnF6DX0UIsFN2cS5t76jXU-Z3NMUNXACufRqrY7xBnnYVSulCrJN_hr%24&data=02%7C01%7Clinda.dunbar%40futurewei.com%7Cef70a9c2ec6f483d3f7908d8018f189d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637261061408947727&sdata=Y2YfSda0sjvKWcu0nZYEgerocW9mgogrmidy1QM%2B5zA%3D&reserved=0>
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org<mailto:ipv6@ietf.org>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fipv6&data=02%7C01%7Clinda.dunbar%40futurewei.com%7Cef70a9c2ec6f483d3f7908d8018f189d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637261061408947727&sdata=qhE9JjN7UWGviKLJtQ5Nmq9oFx0T1P2ksXYQbJ0Ix2k%3D&reserved=0>
--------------------------------------------------------------------