Re: [spring] 6man w.g. last call for <draft-ietf-6man-spring-srv6-oam>

"Zafar Ali (zali)" <zali@cisco.com> Sat, 22 February 2020 01:07 UTC

Return-Path: <zali@cisco.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FAD41200F3; Fri, 21 Feb 2020 17:07:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.498
X-Spam-Level:
X-Spam-Status: No, score=-14.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-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=WmkE89uu; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=UXjYMFGp
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 CaCFQ0eg_-Lv; Fri, 21 Feb 2020 17:07:09 -0800 (PST)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 554DA12006B; Fri, 21 Feb 2020 17:07:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=64175; q=dns/txt; s=iport; t=1582333629; x=1583543229; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=f/+81gzDGHasYhoze/CvSj8AO2UtEIrwWt+/kKwiJTg=; b=WmkE89uuJL3jndqqRSuqrj7nK0gXC70jfFHJmza2vNTgSaKzyHW+fssz al8+bgc68hNCrWmUrMlNljTIrltIm9+rv6yZzD86F9pPilTONpkSWUbnP D35ZxKfjBZB6mnZXCa7IdOchOpcij06KRjfSYY947NBjsse2NqnqlE2xQ U=;
IronPort-PHdr: 9a23:AuHQFBP75qy2zWvEoLEl6mtXPHoupqn0MwgJ65Eul7NJdOG58o//OFDEuKg/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDOIdJSwdDjMwXmwI6B8vQG0T/LdbhbjcxG4JJU1o2t3w=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CKDQDufVBe/5FdJa1cChwBAQEBAQcBAREBBAQBAYF7gSUvUAVsWCAECyqDVECDRgOKcoJfiWOOMYFCgRADUAQJAQEBDAEBGAEKCgIEAQGEQAIXgXUkOBMCAw0BAQUBAQECAQUEbYU3DIVmAQEBAQMBAQoGCAMGChMBASwLAQ8CAQYCEQMBAiEBBgMCAgIfBgsUCQgCBAENBSKDBAGBfU0DLgEOkh6QZwKBOYhidYEygn8BAQWBQ0GDQw0LggwDBoE4hSAMhngagUE/gREBJiCCTD6CG0kBAQMBgScNEzoNCYJbMoIsjV4GDAmCMTuFcIJLhz2ORzJECoI8hmZqhU2FEYQ2HIJJiBuQSo5wiHyCLpAdAgQCBAUCDgEBBYFpIoFYcBUaISoBgkFQGA2OHQwXg1CFFIVBdIEpjQ5fAQE
X-IronPort-AV: E=Sophos;i="5.70,470,1574121600"; d="scan'208,217";a="484165653"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Feb 2020 01:07:03 +0000
Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 01M172KV013975 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 22 Feb 2020 01:07:02 GMT
Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 21 Feb 2020 19:07:01 -0600
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 21 Feb 2020 19:07:00 -0600
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 21 Feb 2020 19:07:00 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bin4y+o2QhfAok/IUj2Kkh2eFG118KhS4qLrdGMhv3gYRyu5eJg8w5bje1+EN7jVIt7sfifRdreUBMIfDsXThomZrN0gu1PtexT8zCgfaliixzb8RBXtV+4kWZwlGqxz7whj1eGI0rVx4fG3SMZG/00ePL+qxtFoNHQaXzVKOXFPfBHtjZjHx7Q+a2ihuocf7gu3Ny2dZ8imZoCh0flAagpxCjgp+bZ7HCgeuq9w9OkMQyBYsvvTmp7pLJDLo1+J+cS5Kt08cG3Xbu/AO28RLjKsTtEB041mf6H806/AuKRFxHb/BFUFe8V9DYCEGb84ML6hJKNT7iQv+zNhqJUJZQ==
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=f/+81gzDGHasYhoze/CvSj8AO2UtEIrwWt+/kKwiJTg=; b=Tq+q5VNcN5euCiZrWxoys35DmLnnSbtDKbUZaONxOHVm0yC3+4m8m8uGQhPx5NHLl/pqX1s2u5teHg4amh2/Ke7F1/dKK32hGSgi1OYq+zIa9mazkNoVjzAjyJzSj6k0vfC8murLs3V82N2iHWWKDwiRUjaZ+gTG+BR1QPJDIjVWuGDJnLRC7kpJMzB8euRAY2KMfN8LS7lTg9kWrJyqHhnKm8QIs0MQF51n++itqERojpsAu+cBjkLOVyJJvhA2pPSYch6FtLWafBnEHW1WuJSUagKkk1D1umtiddZe7N1lK/Dr3ntF+IInn8idJhkMo0mMphbLa0e/IfxUjnrQ/Q==
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=f/+81gzDGHasYhoze/CvSj8AO2UtEIrwWt+/kKwiJTg=; b=UXjYMFGpxexwaYQYXAZ0qSGyNQARE2ySWa3bQjJX54Icxb39TdYokxH5uvpFi0JdQIbANRd2EmvtdlihdeTffqBpplf6zEM237Z6Nu3fLX6HvVvtE3fqci6iKrJ/1kvsuC7h1CA7e1+e3OfSPHVMG8MvII0SIGB0TNh/0MEayUo=
Received: from MN2PR11MB3710.namprd11.prod.outlook.com (2603:10b6:208:f2::19) by MN2PR11MB3613.namprd11.prod.outlook.com (2603:10b6:208:ee::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2729.29; Sat, 22 Feb 2020 01:06:58 +0000
Received: from MN2PR11MB3710.namprd11.prod.outlook.com ([fe80::8c1b:b94:5d2e:446b]) by MN2PR11MB3710.namprd11.prod.outlook.com ([fe80::8c1b:b94:5d2e:446b%3]) with mapi id 15.20.2750.021; Sat, 22 Feb 2020 01:06:58 +0000
From: "Zafar Ali (zali)" <zali@cisco.com>
To: Greg Mirsky <gregimirsky@gmail.com>, Ole Troan <otroan@employees.org>
CC: SPRING WG <spring@ietf.org>, 6man WG <ipv6@ietf.org>, 6man Chairs <6man-chairs@ietf.org>, "Zafar Ali (zali)" <zali@cisco.com>, draft-ietf-spring-srv6-network-programming <draft-ietf-spring-srv6-network-programming@ietf.org>
Thread-Topic: [spring] 6man w.g. last call for <draft-ietf-6man-spring-srv6-oam>
Thread-Index: AQHVquT4fiT0mGN0ekCReZDXMAlj3aesHu4AgBQ7cQCAZjTHgA==
Date: Sat, 22 Feb 2020 01:06:57 +0000
Message-ID: <613EC60C-C81D-4CF1-9CBF-4135571CCDF6@cisco.com>
References: <ECC21DA8-0156-41D2-921E-177389D3C904@employees.org> <CA+RyBmX5=Z_sMrv8CGO7N_ZFwefQsrr=rNyaJwN+2p+9d8TS3Q@mail.gmail.com> <B496472A-0AB3-42D9-BC4E-14E5E2769008@cisco.com>
In-Reply-To: <B496472A-0AB3-42D9-BC4E-14E5E2769008@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.22.0.200209
authentication-results: spf=none (sender IP is ) smtp.mailfrom=zali@cisco.com;
x-originating-ip: [2001:420:c0cc:1002::229]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 29b6a4cb-89c6-472b-4efb-08d7b7338418
x-ms-traffictypediagnostic: MN2PR11MB3613:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <MN2PR11MB36134F43B7E47452C8876E71DEEE0@MN2PR11MB3613.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 03218BFD9F
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(366004)(396003)(39860400002)(136003)(346002)(199004)(189003)(6506007)(186003)(110136005)(53546011)(478600001)(33656002)(86362001)(4001150100001)(36756003)(30864003)(966005)(2616005)(5660300002)(316002)(81166006)(8676002)(9326002)(54906003)(8936002)(76116006)(81156014)(6512007)(2906002)(91956017)(66946007)(71200400001)(64756008)(4326008)(6486002)(66556008)(66446008)(66476007); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3613; H:MN2PR11MB3710.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: OISaW9DRReDKH+ryP1AioxZ+MK71lEKwcncTu0hlTWUd8PE4lvaKykf7R7ibSrvnSp+/dumhVAQIMOAlADB7TQqKN52qNQVS+loBfAAx3n/s7lSTa1bUNIG0jV+LsRg8As/smzsx5eR0SGj+2endmTUwn5Jf3voZSl2LXApUZz4ByqB1zzO6KBcBEYfOttOc3cC8YU++4IXqs2pjwPhRqe4fLcfVKPN0DqkSSO6GdV++t66Lvu1WU9v7vVy54Db9tTtwtuP4LnSIDZFSsUI2lpLC3vNUZ9fnvQfONx4U5VRmDAZq+Wz3hRbBnVnCPaj0cA17OiyxhS9NVGeGf2RRtq6b2iy9Ym4NBVuXMKBh4PTxIWiglr2syFvWkdWYPkM2GBaKC6PRCjKZcQPxpc4vm1MYtXdtbZOl3cP07NYa11jwtTiuQ8nbR/V+hO7Ye226yDHIQP/Khaq6Mjnf4AMIQMpfJOp/+nqW0xd7Bw+LOgx1IqKxu+hFA8pjRiLQojon5QnGW9d/yrDVP/3ZEchgig==
x-ms-exchange-antispam-messagedata: AdU6daaKuu+MaXk3638uoUBSMiZ3I9R4Hsh7mUCNLhS/WyUi8hUjvkraKKCFUbl0VupdiHVWTp1kmlAkyTwuDpDLGu89e78r/e3J3QeWMCnCPTX6pJTFuRFZiLlDZosP98C+RNCAu06JJpXRoT3YPmicCdWOJ+CNRwAgg+1GILI=
Content-Type: multipart/alternative; boundary="_000_613EC60CC81D4CF19CBF4135571CCDF6ciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 29b6a4cb-89c6-472b-4efb-08d7b7338418
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Feb 2020 01:06:58.1636 (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: Lxicw5wg6lIosZaMZK3BbK/VCoS5bax8AO7bEz/d2x4cColt3SXgT5XNESfU5okz
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3613
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com
X-Outbound-Node: rcdn-core-9.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/3IQAKiqInXZrjWRlH0XexLkuV54>
Subject: Re: [spring] 6man w.g. last call for <draft-ietf-6man-spring-srv6-oam>
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 22 Feb 2020 01:07:14 -0000

Hi Greg,

I went back to your comments to verify the latest version in the GitHub addresses them (as marked by [ZA]).
This is with the exception of your question on handling of BFD control packets or STAMP test packets. Please see [ZA2] for the specifics.

One thing that stands out from your review comments is that we need a sub-section on the illustration on the use of O-bit. We are in the process of adding the O-bit usage illustration. Please see [ZA2] for more details.

Many thanks for taking an offline call, earlier. I will reach-out to you again to discuss your comments.

Thanks

Regards … Zafar

From: "Zafar Ali (zali)" <zali@cisco.com>
Date: Wednesday, December 18, 2019 at 7:19 PM
To: Greg Mirsky <gregimirsky@gmail.com>, Ole Troan <otroan@employees.org>
Cc: SPRING WG <spring@ietf.org>, 6man WG <ipv6@ietf.org>, 6man Chairs <6man-chairs@ietf.org>, "Zafar Ali (zali)" <zali@cisco.com>
Subject: Re: [spring] 6man w.g. last call for <draft-ietf-6man-spring-srv6-oam>

Hi Greg,

Many thanks for your detailed comments. Much appreciated.

Please see comments in-line and how the new version addresses your comments.
I also look forward to our offline discussion on Friday.

Please note we have been also maintaining the latest version of the draft in the 6man-Github.

Thanks

Regards … Zafar

From: spring <spring-bounces@ietf.org> on behalf of Greg Mirsky <gregimirsky@gmail.com>
Date: Thursday, December 5, 2019 at 5:22 PM
To: Ole Troan <otroan@employees.org>
Cc: SPRING WG <spring@ietf.org>, 6man WG <ipv6@ietf.org>, 6man Chairs <6man-chairs@ietf.org>
Subject: Re: [spring] 6man w.g. last call for <draft-ietf-6man-spring-srv6-oam>

Dear Authors, et al.,
please find my comments, as WG LC comments, questions to this document below.

  *   The Abstract and Introduction describe the document as "defines building blocks for Operations, Administration, and Maintenance (OAM) in Segment Routing Networks with IPv6 Dataplane (SRv6)". I believe it would be helpful to demonstrate that the existing mechanisms used in IPv6 to demultiplex and realize OAM functions, e.g., using the well-known destination UDP port number, are not sufficient and require the introduction of new methods, e.g., O bit in SRH.
[ZA2] We are adding illustration on the use of the o-bit.
[ZA] If you look at section 4 of the draft, it explains how existing probing mechanisms are used and why extensions are needed. In the new revision posted, we have added additional information on why the O-bit in SRH is defined (for telemetry purpose). Please have a look at the latest revision as we have tried to address your comment.

  *   This document introduces the O-flag into SRH as the building block for OAM in SR networks with IPv6 data plane. It appears that the functions that are realized using the O-flag are already supported by the existing OAM protocols that enable fault management (e.g., variations of Echo Request/Reply, BFD) and performance monitoring (e.g., STAMP).
[ZA2] We are adding illustration on the use of the o-bit.
[ZA] The O-bit is for telemetry use. In the new revision posted, we have added additional normative text on O-bit processing to clarify this point.  Please have a look at the latest revision.

  *   Also, the use of the new "building block for OAM" in SRv6 splits the SR OAM suit into two functionally separate toolsets - one for SR-MPLS and another for SRv6.
[ZA] SRv6 uses IPv6 data plane and hence applicability of the IPv6 OAM tools is discussed.

  *   The document defines the support of O-flag as OPTIONAL. In that case, what is the benefit of advertising the support of O-flag by an SR node (even though the advertisement itself is optional)?
[ZA] To let the other nodes/ controller know if the O-bit is supported by a local node.

  *   The document uses the term "accurate timestamp" without the discussion or definition of what level of accuracy is required or expected, methods to acquire an accurate timestamp, format(s) that must or may be used to record a timestamp, and what are possible implications of not providing an accurate timestamp.
[ZA] We have addressed this comment by replacing “accurate” with “a”. It is really up to the local implementation and draft does not add any requirements.

  *   The document asserts that to support "Many scenarios require punting of SRv6 OAM packets at the desired nodes in the network" can be done only with using OAM Endpoint with Punt function. I believe that TTL/Hop Count Expired had been used successfully to achieve the same result.
[ZA] Yes, and tracerouting is done using TTL/ HC. Please see section 4.

  *   what is the apparent need to introduce functional duplication to already existing OAM technique?  How a packet would be processed if both O-flag and the OAM SID End.OP are present (the specification only recommends setting O-flag to 0 when End.OP SID is present)?
[ZA] Good point. The restriction really does not exist and the new version corrects the text.

  *   Section 3.4 introduces function OAM Endpoint with Timestamp and Punt. At the same time, processing the O-flag, defined, as:
            a. Make a copy of the packet.
            b. Send the copied packet, along with an accurate timestamp
Is the difference in making or not making a local copy significant enough to have two mechanisms to achieve essentially the same result? How a packet will be processed if both O-flag and the OAM SID End.OTP are present (the specification only recommends to set O-flag to 0 when END.OTP SID is present) ?

[ZA] Good point. The restriction really does not exist and the new version corrects the text.

  *   Section 3.5 states that:
   SRH TLV plays an important role in carrying OAM and Performance
   Management (PM) metadata.
I cannot find any other text that illustrates how SRH TLV plays any role in FM and/or PM OAM.

[ZA] Indeed, the current draft does not define any TLV for OAM purposes. The section was added as future drafts may define OAM TLVs.
However, based on your comments, the section has been removed in the new revision.

  *   It is stated in Section 4:
   This section describes how OAM mechanisms can be implemented using
   the OAM building blocks described in the previous section.
As this is the Standard document, using the normative language would be very much desirable. Then it would be clearer whether the use of not only O-flag but of OAM SIDs as well is optional or mandatory.

[ZA] Based on your comment, modified the text in the document to add normative language. Specifically:
o    In the new revision, we have added normative text at the beginning of 3.1.1 where O-bit is defined.
o    Sections 3.3 and 3.4 adds normative texts for OAM SIDs.
o    4.1.2 and 4.2.2 further adds additional normative text for Ping and traceroute use-cases, respectively.


  *   I've noticed that functions used as an example in the document are all part of active OAM functions. At the same time, the defined processing of the O-flag is very much similar to the operation of in-situ OAM. But I don't find any reference to in-situ OAM mechanism, nor discussion of whether both can be used in combination or are mutually exclusive.
[ZA] Based on your comment, we have removed the relevant section.

  *   In Section 4.1.2 the identification of an OAM (active OAM or some other kind of OAM) packet defined as:
   The OAM packets are identified either by setting the O-flag in SRH or
   by inserting the END.OP/ END.OTP SIDs at an appropriate place in the
   SRH.
Is the use of any of these methods required for any OAM? If that is the case, then the normative language must be used. Also, is it required to use any of these methods for, for example, BFD control packets or STAMP test packets? Isn't using assigned by IANA port number sufficient to identify active IP OAM packets? Wouldn't the same be applicable in SRv6 OAM?

[ZA2] You are right that IANA assigned port number should be sufficient to identify active OAM packets. In order to process the OAM packets targeted to a SID, based on a local configuration, the net-pgm needs to allow processing of the OAM packets. What we need is a clarification in the net-pgm draft for the Upper Layer Processing. I’ve added NET-PGM editors (Spring is already CC’ed) to request this change.

[ZA] Normative language has been added to address your comment. 4.1.2 and 4.2.2 further adds additional normative text for Ping and traceroute use-cases, respectively.

  *   I have a question on how a local node selects an application that is to receive a punted packet (whether marked by O-flag that includes one of OAM SIDs)? The document provides examples where the destination is either ICMPv6 or a traceroute (?) process. Is that an exhaustive list?
[ZA] The list is not exhaustive. Furthermore, O-bit is for telemetry use.

I greatly appreciate your kind consideration and am looking forward to the productive discussion.

[ZA] Likewise, many thanks for your comments.

Thanks

Regards … Zafar

Regards,
Greg

On Wed, Dec 4, 2019 at 3:53 PM Ole Troan <otroan@employees..org<mailto:otroan@employees.org>> wrote:
Hello,

  As agreed in the working group session in Singapore, this message starts a new two week 6MAN Working Group Last Call on advancing:

  Title    : Operations, Administration, and Maintenance (OAM) in Segment Routing Networks with IPv6 Data plane (SRv6)
  Author   : Z. Ali, C. Filsfils, S. Matsushima, D. Voyer, M.. Chen
  Filename : draft-ietf-6man-spring-srv6-oam-02
  Pages    : 23
  Date     : 2019-11-20

    https://datatracker.ietf.org/doc/draft-ietf-6man-spring-srv6-oam/

as a Proposed Standard.

Substantive comments and statements of support for publishing this document should be directed to the mailing list.
Editorial suggestions can be sent to the author. This last call will end on the 18th of December 2019.

To improve document quality and ensure that bugs are caught as early as possible, we would require at least
two reviewers to do a complete review of the document.  Please let the chairs know if you are willing to be a reviewer.

The last call will be forwarded to the spring working group, with discussion directed to the ipv6 list.

Thanks,
Bob & Ole, 6man co-chairs


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