Re: [spring] 6man w.g. last call for <draft-ietf-6man-spring-srv6-oam>
"Zafar Ali (zali)" <zali@cisco.com> Fri, 21 February 2020 05:41 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 8AB21120236; Thu, 20 Feb 2020 21:41:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level:
X-Spam-Status: No, score=-14.499 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, 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=BNLUwHkx; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=W4SQoylh
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 kOhMhQ-mtWNL; Thu, 20 Feb 2020 21:41:31 -0800 (PST)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A36A120052; Thu, 20 Feb 2020 21:41:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=250968; q=dns/txt; s=iport; t=1582263691; x=1583473291; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=YgMsQzoY0bxb6wnaWvnE11J4JtmLr4eXpCwEr/n8Owc=; b=BNLUwHkxTG0hslvF0ICbLwn51DCh56qF45Ad/YVKAglrmWHpqrghWXdc 729lZjzh8xfJntKuZ17T2dQbB8YpcIg9DXPP2FSqu5s2lxa74MX7VQaR7 6sHXZL0MK+GWwPF+uL6x8p4DvcjaNKQAcThI9v+gDxkBO9i+E72Hn1Jf0 E=;
X-Files: draft-ietf-6man-spring-srv6-oam.txt, draft-ietf-6man-spring-srv6-oam-03-loa-comments-ZA.txt : 41903, 49812
IronPort-PHdr: 9a23:4KTRJR0oVeb0V9FHsmDT+zVfbzU7u7jyIg8e44YmjLQLaKm44pD+JxGCt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8TgZdYBUERoMiMEYhQslVdyMDUzTJ//xZCt8F8NHBxdo
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0C+AgBAbU9e/5tdJa1cChsBAQEBAQEBBQEBAREBAQMDAQEBgXuBJS8kBScFbFggBAsqg1RAg0YDinGCOiWBAYhijjCBQi9hA1AEAgcBAQEMAQEYAQoIAgIEAQGBKwEggi9FAheBcSQ4EwIDDQEBBQEBAQIBBQRthTcMhWYBAQEBAgEBAQoGCAECBh0BASQBBAMLAQ0CAgEGAhEDAQIhAQYDAgICGQYGCxQJCAIEAQ0FDhSDBAGCSgMOIAECDJExkGcCgTmIYnWBMoJ/AQEFgS8BAwIOQYNCDQuCBQcJBYEzhSAMhngagUE/gRABASYMFIFOSTU+ghtJAQECAQGBJAcBAQEGBQYBByABEAkGBwkCBoJSMoIsjUsSCAoJBoJmhXAkcYE2hGGCXI5HMkQKgjyDb4J3aoVNhDNegiWCERyCSTFMhx6ETooUgWeOcIh7gi6QHQIEAgQFAg4BAQWBaSJncXAVGiEqAYJBCUcYDY4dDBeBBAEBAYJJgkqCSoUIATh0AoEnizMQF4IbAQE
X-IronPort-AV: E=Sophos;i="5.70,467,1574121600"; d="txt'?scan'208,217";a="447512987"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 21 Feb 2020 05:41:20 +0000
Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 01L5fKHL022615 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 21 Feb 2020 05:41:20 GMT
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 20 Feb 2020 23:41:19 -0600
Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 21 Feb 2020 00:41:17 -0500
Received: from NAM12-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 20 Feb 2020 23:41:17 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hsCRuI1V90/qbBztGe1YY9R14opj9y239J4HKZdpX+iSLCavXMS/+mWM0twUIuhL64YA7+ak5GQg81xf+l4FL1Yd0OI4ZiQR/7iByrF5dQMoCnKq4Y6T9RH5CXl7RgWV6W8hEf9Yp7rzgN/9Wy7aHEOYuiEqnUdJn5GzU8HIc0/XEZBFsghBlEFWdiMS8ofAfH4u34x20QVFB0kWpEYoIoLaV60YJOa41uVrnbB0rRtmzMBTcR3zsHN7E8yTFqnOOwavY0dOj2nUXJi+LYJugKDNABBJiWkkL45e0FsGbvPFbFJK5Hofu905gs9u4+IDUoLA5bCNGyFwwJh/jA00QQ==
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=piV4aF87US/JorrM7cQSO0zaHIIL9Fxq1QxV8cXVwqc=; b=aVReWndF9yMGES33eyyqaYsDN7Zrei8j3499Uh+w3q4JUAXak9h1B9BdJQ2AX6NRABr2THuGFTmYjuQwSRrYDnCm/9BMeCf0G/EtpNgAMYsTA5M2QtVm20dIdGueppIrheu9qYF+wAUhh7+JxXJ0l4GbeedEFi/U6emthMWz+QukHjAO02lqDEIsK5uDXzZt2H3SBujDjiTXqQMXr7Nas2sRB7ij+NGan9quNiRJa9NfTOdX3hT9ELZC0dxH0sm9KAMgA8ldX8v7aS99BXPfkuewQX+50GYWPB4O8+8ba6GNlkAoUetaOgwTsXS5Sdl/t4CXkbyn7sY3+RX4oM5lFg==
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=piV4aF87US/JorrM7cQSO0zaHIIL9Fxq1QxV8cXVwqc=; b=W4SQoylhR4rG7U1b2CTvAr7aIliMPxc7Vxskey0IAt93jdOK5Q/TDgrpJz3bS7axbDNiHNecLHFvowOydND65GPuKqsPtBJ/7RL/uZEbMTyV30kEuSjuCoK7cT6TlPSraU7LFsw+dij3djQXmQetVW6BcVJzDTB94e2Tu0OzB3Y=
Received: from MN2PR11MB3710.namprd11.prod.outlook.com (20.178.252.147) by MN2PR11MB4239.namprd11.prod.outlook.com (52.135.39.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2729.29; Fri, 21 Feb 2020 05:41:14 +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.016; Fri, 21 Feb 2020 05:41:14 +0000
From: "Zafar Ali (zali)" <zali@cisco.com>
To: Loa Andersson <loa@pi.nu>, Brian E Carpenter <brian.e.carpenter@gmail.com>, Ole Troan <otroan@employees.org>, 6man WG <ipv6@ietf.org>, SPRING WG <spring@ietf.org>
CC: 6man Chairs <6man-chairs@ietf.org>, "Zafar Ali (zali)" <zali@cisco.com>
Thread-Topic: [spring] 6man w.g. last call for <draft-ietf-6man-spring-srv6-oam>
Thread-Index: AQHVquT4fiT0mGN0ekCReZDXMAlj3afzd/OAgADJlICAARyrgIAA66eA///SVQCAAKQ5gIACJK8AgCuYEICAAMxLAA==
Date: Fri, 21 Feb 2020 05:41:13 +0000
Message-ID: <C8900892-D5E1-4023-9309-BA695F739709@cisco.com>
References: <ECC21DA8-0156-41D2-921E-177389D3C904@employees.org> <09adcd59-13ae-448b-6a48-5e7471dbd121@pi.nu> <15d6aa7b-b786-57c7-2014-1c76edbc4e77@gmail.com> <82A1B481-B638-4D9B-AC90-A9195CA531F5@cisco.com> <8b407450-0bc5-502b-2907-e05efebc2e84@pi.nu> <3A01D745-7B1A-420B-9A6C-D9A35AA84174@cisco.com> <2d02954d-af78-8d3d-dbcf-5eb989157b47@pi.nu> <842FEA33-2203-4862-9DE0-E963956C3230@cisco.com> <E894124D-4BD4-46D3-B81A-C54F42B3C8CF@cisco.com>
In-Reply-To: <E894124D-4BD4-46D3-B81A-C54F42B3C8CF@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
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: bd586a37-0371-4d6a-ec74-08d7b690aa67
x-ms-traffictypediagnostic: MN2PR11MB4239:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <MN2PR11MB4239DB8CA6194F049777BCB2DE120@MN2PR11MB4239.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0320B28BE1
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(396003)(39860400002)(136003)(346002)(376002)(189003)(199004)(54906003)(9326002)(107886003)(8936002)(66946007)(76116006)(8676002)(81166006)(81156014)(91956017)(71200400001)(66446008)(66476007)(2906002)(4326008)(66556008)(66576008)(64756008)(6486002)(6512007)(86362001)(4001150100001)(33656002)(478600001)(186003)(110136005)(53546011)(6506007)(36756003)(30864003)(66574012)(5660300002)(316002)(2616005)(966005)(579004)(559001); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4239; H:MN2PR11MB3710.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A: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: Hqg2+rgduKYPMGeISS/aQnJHabvMs/Lenb6AcyuXsxEcKtHdWp9CGRrZgi6lAAY+6hsLUoP2TEcGeYvvR4SSNY3qSMQNSGwYXYpjTVywUst7sMK2bNNQm8/9N27ppkcWav5l1BOLRlJgrdNZxfV3ueg53ygAfdpRwbDpH8LnKRP3u61vn+dq8TLOfIzXd6UGgnbXePTTgvagFT+pxXahBqNjBd3eB2ToiuJtaf11U+n5ZUx6tmZUXrEu5sA+RH0dwesdcsDU3gCd6AO8CBcZlJbihEb94Lfw3DJb5iVlFm5E3cdkGPJPvw0XcpkspUjl85TLLj3+hxA0UrYrDip02OzRuYl0kWaOW8gxtTYa8lqcYa4KaRQp5mn2HciBUSJtz/dR47W+LNVXdbEn1Bypzt8x1PsjXVJ+afo/MlTT3VqEAs3UDstmvUQP7q4u5YywMOUEQ2Pm55AKT31ySkOfceSB/dmRiLncbGUW6iaVYumPUtsE9PzRRPGpqXs6v5ehV0beK1B+IzUNGq9pxFXmCA==
x-ms-exchange-antispam-messagedata: NlWRM+ZDuKf5U+wQSwAJ2YxeAOl0o3xrwqOMonLRwsAmJ2JSJd2ulQnYoWZya2q5fQ6/steA4m0MGyrSr4/tva8SlCwKbTO6zTReG7KT2UfIKjAoaTnwnMV87IcgbDYG5itXUlr77NwenCVoC8YUqOewyG2XiAxprSO3tEVXZlo=
Content-Type: multipart/mixed; boundary="_005_C8900892D5E140239309BA695F739709ciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: bd586a37-0371-4d6a-ec74-08d7b690aa67
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Feb 2020 05:41:14.2030 (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: Lt8OkU1JDgvKsoPv1swE4kia0hNFXcJloHg6ObBGiFhTM+YCGshTRfcOYUquDJO6
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4239
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com
X-Outbound-Node: rcdn-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/2se0pMWLikQqwPpw1x35VpVAjxU>
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: Fri, 21 Feb 2020 05:41:42 -0000
Hi Loa, We have addressed most of your comments in the enclosed .txt file. We have also uploaded updated XML file to the 6man/OAM repository (but please use the enclosed .txt file for diffs. Somehow “Compare Editor's Copy to Working Group Draft” is pointing to older diffs. Details of how your comments are addressed are listed in the following as well as in the enclosed updated diffs file that you shared earlier. We plan to address the remaining comments very soon. Many thanks again for detailed review. Thanks Regards … Zafar How comments were addressed: [LA1]The Abstract seems to be a bit ìbareî, it should be a stand-alone text, this seem to pre-suppose an high level of familiarity with the topic. [ZA] rewrite TBD. [LA2]Dataplane or data pale, us one both not both. [ZA] Changed. [LA3]îsomeî, this begs for an explanation of what has been left out and why. [LA4]There is an RFC 7322, please make sure that you are following these guidelines. S for the placement of the ìRequirement Languageî, the style guide says that it should be placed as a top level section after the Introduction, however not even the RFC Editor follow that guidance, the Requirement Language are most often placed as a subsection of the introduction. [ZA] Changed the text to follow the RFC7322 guideline. [LA5]There is a new template for this, BCP BCP 14 which consists of twp RFCs ([RFC2119] [RFC8174]) should be referenced. [ZA] Reference to [RFC8174] added. [LA6]Thos is very sparse, and it is also a direct copy og the abstract (or the other way around). I donít think this is allowed. [ZA] rewrite TBD. [LA7]I think you could remove this header and make îAbbreviationsî section 1.1 [ZA] Fixed. [LA8]RFC 8402 define this is as îSegemetns Leftî [ZA] Good catch! Fixed. [LA9]Also this document uses îSegments Leftî [ZA] Fixed. [LA10]Admittedly the topology is simple, but the figure could be much clearer. I agree that it is a good idea to define a simple topology and use it throughout the document. [ZA] Thanks. Any suggestion to simplify is welcomed. [LA11]This could be a good place to explain the use of înode kî. [ZA] Moved. [LA12]Probably not a very strong point, ìclassicî is already a bit ambivalent, and will be more so as the time goes by. Iíd say just drop it, or make it ìnon-SRv6 IPv6 nodesî. [ZA] Fixed. [LA13]îNode kî is not in the reference topology. [ZA] Node k is used to refer to all nodes collectively (e.g., to define the IPv6 addressing scheme for them.). IMO this should be fine. [LA14]If you are going to push the link number into the IPv6 address, it would be better to start numbering from zero. [ZA] There is no node 0 in the topology. The addressing example is based on node names. IMO this should be fine. [LA15]This three is redundant, the î3:4î in the two previous positions uniquely identify the link, [ZA] Actually it is not redundant as the last :3 represents the link address at node 3 side. IMO this should be fine. [LA16]After going through this a number of time Iím convinced that this is correct. However, it takes quite an effort to go through a rather cryptic text. Is it possible to clarify. [ZA] Thanks for your feedback. Actually there was a typo and I fixed it. [LA17]This îS1î means îSID1î, why do we need the ìSî as a special notation when we already have ìSIDî [ZA] Si is a notation that relates to a topology or service segment. S[j] represents the SID pointed by the SL field in the SRH. S[j] is like a index in sid-list in the SRH. IMO this should be fine. [LA18]When we were specifying MPLS-TP we diid a lot of OAM work, concepts like MIPs and MEPs were introduced. Do these concepts have any bearing on SRv6 OAM? [ZA] Thanks for your feedback. SRv6 OAM is in-line with OAM in IPv6 networks, which are not of transport nature. [LA19]This is a double reference to the same document and strictly note necessary The format of the second reference is also wrong and does not appear in the reference list. [ZA] Fixed. [LA20]Well, if you do you need a subsection in the IANA Consideration. The flag field is defined in ietf-6man-segment-routing-header, but it is still a draft. As this document stands now you canít find the IANA allocations. Partly depending on that IANA not yet done the allocations, but also because if they were done there is no clear reference to the registry. SRH.Flags is not the name of the registry. [ZA] Fixed. [LA21]The notation îSRH.Flagsî is invented here, right? draft-ietf-6man-segment-routing-header, and the SRV6 Networking programming draft (which is referenced for terminology) simply talks about SRH or ìSRH Flagsî. [ZA] The SRH.Flags is defined in draft-ietf-6man-segment-routing-header. The IANA registry for SRH.Flags is requested in draft-ietf-6man-segment-routing-header. This document just defined a flag to identify OAM packets. [LA22]Why start with bit 2, why not 0 or 7? [ZA] There is a long history. This O-flag flag were originally defined in the https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-11. During the LC review, it was moved to OAM draft. But the position has been already defined and used by the ASICs. Hence, keeping the same bit position. [LA23]We are allocating a flag from a registry defined in draft-ietf-6man-segment- routing-header. Since this is still in IESG review it will not be possible progress this document until the routing header document is in the RFC Editors queue, and it canít become an RFC until the document defining the registry is also an RFC. I think the SRH flags registry should be properly named here, "Segment Routing Header Flags" [ZA] Yes, the SRH flags registry is named as "Segment Routing Header Flags". Please see IANA section in the new revision. [LA24]I think the should be either OAM, Operation Administration and Maintenance; or O&M, OAM and Management. See RFC 6291. [ZA] Fixed. [LA25]Note: Chapter 3 is well written and easy to understand [ZA] Will fix it - TBD. [LA26]Comment added after reading the entire section, the procedures and mechanisms described is as far as I can judge well and clearly documented. [ZA] Thanks. [LA27]An Extreme nit, but I would call this îPing in SRv6 Networksî [ZA] Fixed [LA28]I said it before ñ I donít like ìClassicî, and I donít thnk it is necessary or contribute significantly. [ZA] We will think about renaming. TBD. [LA29]I think this procedures is well and clearly documented. [ZA] Thanks. [LA30]As far as I can see this works. [ZA] Thanks. [LA31]We might want a reference. [ZA] This should be fine as this is well know. [LA32]At this point I start think of SRv6 as îconnection oriented. [ZA] SRv6 enables source routing. [LA33]I see no immediate technical problems here. [ZA] Thanks [LA34]I defer to the security experts on this section. [ZA] Yes that is part of the review process. [LA35]You need text in this section describing the allocation of the O-flag. [ZA] Fixed. [LA36]What are the registration procedures??? If I understand correctly we want to take one of the unused ICMPv6 Type Numbers and create the ìICMP Type Numbers ñ SRv6 OAM messagesî registry. But with all due respect the text is a bit tangled. [ZA] Fixed the text. Thanks for the good catch. [LA37]This allocation is in itself not problematic, but the registries are not yet in place., weíll have to wait for the network programming draft to progress. [ZA] Agreed! Thanks Regards … Zafar From: "Zafar Ali (zali)" <zali@cisco.com> Date: Thursday, February 20, 2020 at 12:30 PM To: Loa Andersson <loa@pi.nu>, Brian E Carpenter <brian.e.carpenter@gmail.com>, Ole Troan <otroan@employees.org>, 6man WG <ipv6@ietf.org>, SPRING WG <spring@ietf.org> Cc: 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 Loa, Sorry, I could not get back to your other comments, earlier. I am starting to look into all outstanding comments. It will be great if you could send me copy of the word document diffs (privately). But either way, your comments are quite clear. Many Thanks Regards … Zafar From: "Zafar Ali (zali)" <zali@cisco.com> Date: Thursday, January 23, 2020 at 6:46 PM To: Loa Andersson <loa@pi.nu>, Brian E Carpenter <brian.e.carpenter@gmail.com>, Ole Troan <otroan@employees.org>, 6man WG <ipv6@ietf.org>, SPRING WG <spring@ietf.org> Cc: 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> Loa, Many thanks. The comments in your email has been addressed in latest version in the GitHub. We are working to address the rest of your comments. Thanks Regards … Zafar From: Loa Andersson <loa@pi.nu> Date: Wednesday, January 22, 2020 at 5:03 AM To: "Zafar Ali (zali)" <zali@cisco.com>, Brian E Carpenter <brian.e.carpenter@gmail.com>, Ole Troan <otroan@employees.org>, 6man WG <ipv6@ietf.org>, SPRING WG <spring@ietf.org> Cc: 6man Chairs <6man-chairs@ietf.org> Subject: Re: [spring] 6man w.g. last call for <draft-ietf-6man-spring-srv6-oam> Zafar, Tnx - 1 down 36 to go! Actually a bit more with the NITs output. Can you take a look at the long lines next, it should be easy edits. The first two long lines are in this paragraph: 248 S01.1. IF SRH.Flags.O-flag is set and local configuration permits 249 O-flag processing THEN 250 a. Make a copy of the packet. 251 b. Send the copied packet, along with a timestamp 252 to the OAM process. ;; Ref1 253 Ref1: An implementation SHOULD copy and record the timestamp as soon as 254 possible during packet processing. Timestamp is not carried in the packet 255 forwarded to the next hop. Line 253 has four characters "n as" outside the allowed 72 characters Line 254 has the word "packet" outside the allowed 72 characters This is inside the figure and I think that you can left shift the enire figure, otherwise I don't see a problem with introducing line breaks. In figure 4: 639 > traceroute srv6 B:4:C52 via segment-list B:2:C31 641 Tracing the route to SID function B:4:C52 642 1 2001:DB8:1:2:21 0.512 msec 0.425 msec 0.374 msec 643 SRH: (B:4:C52, B:4:OTP, B:2:C31; SL=2) 644 2 2001:DB8:2:3:31 0.721 msec 0.810 msec 0.795 msec 645 SRH: (B:4:C52, B:4:OTP, B:2:C31; SL=1) 646 3 2001:DB8:3:4::41 0.921 msec 0.816 msec 0.759 msec 647 SRH: (B:4:C52, B:4:OTP, B:2:C31; SL=1) 649 Figure 4 A sample output for hop-by-hop traceroute to a SID function Line 649 has "tion" of "SID function" (fig numbring) outside the allowed 72 characters, again should be easy to left shif or introduce line breaks. The reason I want to address this first is that it is easy, but also a show stopper. And last, thugh I hate to add late comments - abbreviations, I have not gone through the entire document to look for unexpanded abbreviations, but there is at least one "NPU". Which I read as Network Processing Unit, what confuses me is that it is not in the RFC Editors abbreviation list at all. I think there is an action point for the wg chairs to have it introduced, and for the authros to expand, as well as going through the document an d make sure that everthing that should be expanded is. /Loa On 22/01/2020 13:15, Zafar Ali (zali) wrote: Hi Loa, Many thanks for your follow-up. Based on your feedback, we have updated the version in the GitHub. Thanks Regards … Zafar *From: *Loa Andersson <loa@pi.nu<mailto:loa@pi.nu>> *Date: *Tuesday, January 21, 2020 at 9:59 PM *To: *"Zafar Ali (zali)" <zali@cisco.com<mailto:zali@cisco.com>>, Brian E Carpenter <brian.e.carpenter@gmail.com<mailto:brian.e.carpenter@gmail.com>>, Ole Troan <otroan@employees.org<mailto:otroan@employees.org>>, 6man WG <ipv6@ietf.org<mailto:ipv6@ietf.org>>, SPRING WG <spring@ietf.org<mailto:spring@ietf.org>> *Cc: *6man Chairs <6man-chairs@ietf.org<mailto:6man-chairs@ietf.org>> *Subject: *Re: [spring] 6man w.g. last call for <draft-ietf-6man-spring-srv6-oam> Zafar, Thanks for addressing this. However one thing remains. The text is now: "There MAY be additional segments preceding the END.OP/ END.OTP SID." I don't think there is a need for requirement language in that sentence, I read it as straightforward English: "There may be additional segments preceding the END.OP/ END.OTP SID." Would do very well. Can you explain the need for requirement language? /Loa On 22/01/2020 01:55, Zafar Ali (zali) wrote: Hi Brian, Many thanks for your comments. Much appreciated. The working copy of the new version in the repository addresses your/ Loa’s comment highlighted in your email. https://github.com/ietf-6man/srv6-oam Thanks Regards … Zafar *From: *spring <spring-bounces@ietf.org<mailto:spring-bounces@ietf.org> <mailto:spring-bounces@ietf.org><mailto:spring-bounces@ietf.org%3e>> on behalf of Brian E Carpenter <brian.e.carpenter@gmail.com<mailto:brian.e.carpenter@gmail.com> <mailto:brian.e.carpenter@gmail.com><mailto:brian.e.carpenter@gmail.com%3e>> *Organization: *University of Auckland *Date: *Monday, January 20, 2020 at 2:57 PM *To: *Loa Andersson <loa@pi.nu<mailto:loa@pi.nu> <mailto:loa@pi.nu><mailto:loa@pi.nu%3e>>, Ole Troan <otroan@employees.org<mailto:otroan@employees.org> <mailto:otroan@employees.org><mailto:otroan@employees.org%3e>>, 6man WG <ipv6@ietf.org<mailto:ipv6@ietf.org> <mailto:ipv6@ietf.org><mailto:ipv6@ietf.org%3e>>, SPRING WG <spring@ietf.org<mailto:spring@ietf.org> <mailto:spring@ietf.org><mailto:spring@ietf.org%3e>> *Cc: *6man Chairs <6man-chairs@ietf.org<mailto:6man-chairs@ietf.org> <mailto:6man-chairs@ietf.org><mailto:6man-chairs@ietf.org%3e>> *Subject: *Re: [spring] 6man w.g. last call for <draft-ietf-6man-spring-srv6-oam> To be clear about one of the points in the review, MAY NOT is not allowed by RFC2119 because it is totally ambiguous in English (since it can mean either "must not" or "might not"). In any case the phrase "MAY or MAY NOT" is not of any normative value. It presumably simply means "MAY" in all cases in this draft. Regards Brian On 20-Jan-20 20:54, Loa Andersson wrote: WG, I have reviewed the entire document. First, I'm not an IPv6 expert. As far as I can see the sued on I have not used github, I had a couple of attempts to learn the tools, but so far I have failed. I have instead done what I use to do, use the review tool with Word. Since I sometimes have a pushback on the docx-format I save the result as a .txt-file. Drawback is that all comment show up as refrences to a list at the end of the document. But you can't get everything. /Loa PS gives this output for this draft; it is quite a lot and in itself are so much that it is worth sending it bck to the authors and asking them to fix it. Was the noits tool checked at all before starting the wglc? idnits 2.16.02 /tmp/draft-ietf-6man-spring-srv6-oam-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 6 characters in excess of 72. == There are 5 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: To perform ICMPv6 ping to a target SID an echo request message is generated by the initiator with the END.OP or END.OTP SID in the segment-list of the SRH immediately preceding the target SID. There MAY or MAY NOT be additional segments preceding the END.OP/ END.OTP SID. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: To traceroute a target SID a probe message is generated by the initiator with the END.OP or END.OTP SID in the segment-list of the SRH immediately preceding the target SID. There MAY or MAY NOT be additional segments preceding the END.OP/ END.OTP SID. -- The document date (December 18, 2019) is 32 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'SL' is mentioned on line 190, but not defined -- Looks like a reference, but probably isn't: '2' on line 191 -- Looks like a reference, but probably isn't: '1' on line 191 -- Looks like a reference, but probably isn't: '0' on line 192 == Missing Reference: 'RFC7011' is mentioned on line 230, but not defined == Missing Reference: 'I-D.ietf-idr-bgpls-srv6-ext' is mentioned on line 241, but not defined == Missing Reference: 'RFC792' is mentioned on line 701, but not defined == Missing Reference: 'RFC 8403' is mentioned on line 660, but not defined == Unused Reference: 'RFC0792' is defined on line 823, but no explicit reference was found in the text == Unused Reference: 'RFC8403' is defined on line 843, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-spring-srv6-network-programming-06 Summary: 1 error (**), 0 flaws (~~), 12 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. On 05/12/2019 04:53, Ole Troan 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> <mailto:ipv6@ietf.org> <mailto:ipv6@ietf.org> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org<mailto:ipv6@ietf.org> <mailto:ipv6@ietf.org> <mailto:ipv6@ietf.org> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- _______________________________________________ spring mailing list spring@ietf.org<mailto:spring@ietf.org> <mailto:spring@ietf.org> <mailto:spring@ietf.org> https://www.ietf.org/mailman/listinfo/spring -- Loa Andersson email: loa@pi.nu<mailto:loa@pi.nu> <mailto:loa@pi.nu> Senior MPLS Expert Bronze Dragon Consulting phone: +46 739 81 21 64 _______________________________________________ spring mailing list spring@ietf.org<mailto:spring@ietf.org> https://www.ietf.org/mailman/listinfo/spring -- Loa Andersson email: loa@pi.nu<mailto:loa@pi.nu> Senior MPLS Expert Bronze Dragon Consulting phone: +46 739 81 21 64
- [spring] 6man w.g. last call for <draft-ietf-6man… Ole Troan
- Re: [spring] 6man w.g. last call for <draft-ietf-… Joel M. Halpern
- Re: [spring] 6man w.g. last call for <draft-ietf-… Greg Mirsky
- Re: [spring] 6man w.g. last call for <draft-ietf-… Zafar Ali (zali)
- Re: [spring] 6man w.g. last call for <draft-ietf-… Joel M. Halpern
- Re: [spring] 6man w.g. last call for <draft-ietf-… Joel M. Halpern
- Re: [spring] 6man w.g. last call for <draft-ietf-… li_zhenqiang@hotmail.com
- Re: [spring] 6man w.g. last call for <draft-ietf-… Ron Bonica
- Re: [spring] 6man w.g. last call for <draft-ietf-… otroan
- Re: [spring] 6man w.g. last call for <draft-ietf-… Zafar Ali (zali)
- Re: [spring] 6man w.g. last call for <draft-ietf-… Zafar Ali (zali)
- Re: [spring] 6man w.g. last call for <draft-ietf-… Joel Halpern Direct
- Re: [spring] 6man w.g. last call for <draft-ietf-… Zafar Ali (zali)
- Re: [spring] 6man w.g. last call for <draft-ietf-… Joel M. Halpern
- Re: [spring] 6man w.g. last call for <draft-ietf-… Robert Raszuk
- Re: [spring] 6man w.g. last call for <draft-ietf-… Greg Mirsky
- Re: [spring] 6man w.g. last call for <draft-ietf-… Rakesh Gandhi
- Re: [spring] 6man w.g. last call for <draft-ietf-… Greg Mirsky
- Re: [spring] 6man w.g. last call for <draft-ietf-… Robert Raszuk
- Re: [spring] 6man w.g. last call for <draft-ietf-… Greg Mirsky
- Re: [spring] 6man w.g. last call for <draft-ietf-… Joel M. Halpern
- Re: [spring] 6man w.g. last call for <draft-ietf-… Zafar Ali (zali)
- Re: [spring] 6man w.g. last call for <draft-ietf-… Joel M. Halpern
- Re: [spring] 6man w.g. last call for <draft-ietf-… Greg Mirsky
- Re: [spring] 6man w.g. last call for <draft-ietf-… Zafar Ali (zali)
- Re: [spring] 6man w.g. last call for <draft-ietf-… Zafar Ali (zali)
- Re: [spring] 6man w.g. last call for <draft-ietf-… Ron Bonica
- Re: [spring] 6man w.g. last call for <draft-ietf-… Zafar Ali (zali)
- Re: [spring] 6man w.g. last call for <draft-ietf-… Loa Andersson
- Re: [spring] 6man w.g. last call for <draft-ietf-… Bob Hinden
- Re: [spring] 6man w.g. last call for <draft-ietf-… Zafar Ali (zali)
- Re: [spring] 6man w.g. last call for <draft-ietf-… Brian E Carpenter
- Re: [spring] 6man w.g. last call for <draft-ietf-… Loa Andersson
- Re: [spring] 6man w.g. last call for <draft-ietf-… Bob Hinden
- Re: [spring] 6man w.g. last call for <draft-ietf-… Zafar Ali (zali)
- Re: [spring] 6man w.g. last call for <draft-ietf-… Zafar Ali (zali)
- Re: [spring] 6man w.g. last call for <draft-ietf-… Loa Andersson
- Re: [spring] 6man w.g. last call for <draft-ietf-… Zafar Ali (zali)
- Re: [spring] 6man w.g. last call for <draft-ietf-… Loa Andersson
- Re: [spring] 6man w.g. last call for <draft-ietf-… Zafar Ali (zali)
- Re: [spring] 6man w.g. last call for <draft-ietf-… Zafar Ali (zali)
- Re: [spring] 6man w.g. last call for <draft-ietf-… Zafar Ali (zali)
- Re: [spring] 6man w.g. last call for <draft-ietf-… Zafar Ali (zali)
- Re: [spring] 6man w.g. last call for <draft-ietf-… Pablo Camarillo (pcamaril)
- Re: [spring] 6man w.g. last call for <draft-ietf-… Greg Mirsky
- Re: [spring] 6man w.g. last call for <draft-ietf-… Loa Andersson
- Re: [spring] 6man w.g. last call for <draft-ietf-… Greg Mirsky