Re: Genart last call review of draft-ietf-sfc-nsh-19
"Carlos Pignataro (cpignata)" <cpignata@cisco.com> Fri, 01 September 2017 04:28 UTC
Return-Path: <cpignata@cisco.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7D1D126BF0; Thu, 31 Aug 2017 21:28:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Level:
X-Spam-Status: No, score=-14.52 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.01, RCVD_IN_MSPIKE_WL=-0.01, 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
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 U-CKjdH6V1KY; Thu, 31 Aug 2017 21:28:52 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F75D132EE3; Thu, 31 Aug 2017 21:28:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29084; q=dns/txt; s=iport; t=1504240132; x=1505449732; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=dxBhhaWKG0DrfEQN7KtuIqRswE0UuL5GaEZ1z5BoBfE=; b=UYuqsYiB75Gnsj+H/xjQH+QJmtfw9ky4+sGp5CHUQoAs62MQFFOPSPOs 3b36jKCq8+zlF1rPDEk9GMa/xLfmZCnuh8v+VXjXXF4fKF0dhvDGOR6P5 n/v769CxBQ1V5f0dYVD93S+3R57/IN+bdIL7dOq/McINCo/2X3ZUA9f7P 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0C/AAAF4ahZ/5ldJa1dGQEBAQEBAQEBAQEBBwEBAQEBg1pkgRUHjhCQH4FPIoJwhUmNbg6CBC6FGQIag3U/GAECAQEBAQEBAWsohRkGI1EFEAIBCA4GKwMCAgIfERQRAgQOBRuJMkwDFRCvP4InhzsNhBoBAQEBAQEBAQEBAQEBAQEBAQEBAQEdgyqCAoFOgWMrC4JygleCBjiCczCCMQWJe4kRhSWIAjwCh1mDWoQmhHaCE4Vng32Gd4xOiXYBDxA4gQ13FVsBhwh2AYlOgQ8BAQE
X-IronPort-AV: E=Sophos;i="5.41,456,1498521600"; d="scan'208,217";a="479886876"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Sep 2017 04:28:51 +0000
Received: from XCH-RTP-020.cisco.com (xch-rtp-020.cisco.com [64.101.220.160]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v814SoKR005074 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 1 Sep 2017 04:28:51 GMT
Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-020.cisco.com (64.101.220.160) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 1 Sep 2017 00:28:50 -0400
Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1263.000; Fri, 1 Sep 2017 00:28:50 -0400
From: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
To: Dan Romascanu <dromasca@gmail.com>
CC: "gen-art@ietf.org" <gen-art@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, Service Function Chaining IETF list <sfc@ietf.org>, "draft-ietf-sfc-nsh.all@ietf.org" <draft-ietf-sfc-nsh.all@ietf.org>
Subject: Re: Genart last call review of draft-ietf-sfc-nsh-19
Thread-Topic: Genart last call review of draft-ietf-sfc-nsh-19
Thread-Index: AQHTG1wXf572axcqxkiCBrPJS5Tss6KfhneAgAAyl4CAAAjkAA==
Date: Fri, 01 Sep 2017 04:28:49 +0000
Message-ID: <7BB49936-077F-4909-82BB-C9976C03C4AE@cisco.com>
References: <150341604132.6021.14134855950693780483@ietfa.amsl.com> <780ED7FA-6417-40A8-8524-69887C3AB161@cisco.com> <CAFgnS4XoR7eqW=+4i63Q=YGdqOVGCkBELkvfym_7kONtKKhaKg@mail.gmail.com>
In-Reply-To: <CAFgnS4XoR7eqW=+4i63Q=YGdqOVGCkBELkvfym_7kONtKKhaKg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.118.116.133]
Content-Type: multipart/alternative; boundary="_000_7BB49936077F490982BBC9976C03C4AEciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/S2ebsxkkz2A310irdlNgg9BtYvk>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Sep 2017 04:28:56 -0000
Thanks to you, Dan! — Carlos Pignataro, carlos@cisco.com<mailto:carlos@cisco.com> “Sometimes I use big words that I do not fully understand, to make myself sound more photosynthesis." On Aug 31, 2017, at 11:56 PM, Dan Romascanu <dromasca@gmail.com<mailto:dromasca@gmail.com>> wrote: Hi Carlos, Thank you for addressing my comments. Your suggested edits seem to address the issues. Regards, Dan On Fri, Sep 1, 2017 at 3:55 AM, Carlos Pignataro (cpignata) < cpignata@cisco.com<mailto:cpignata@cisco.com>> wrote: Hi, Dan, Many thanks for your detailed and valuable review, and apologies for the delay in Ack-ing and responding. Please see inline. — Carlos Pignataro, carlos@cisco.com<mailto:carlos@cisco.com> “Sometimes I use big words that I do not fully understand, to make myself sound more photosynthesis." On Aug 22, 2017, at 11:34 AM, Dan Romascanu <dromasca@gmail.com<mailto:dromasca@gmail.com>> wrote: Reviewer: Dan Romascanu Review result: Almost Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-sfc-nsh-19 Reviewer: Dan Romascanu Review Date: 2017-08-22 IETF LC End Date: 2017-08-25 IESG Telechat date: 2017-09-14 Summary: This document describes the header (called Network Service Header - NSH) to be inserted in packets and frames in order to create packets and frames that realize service functions described by other SFC documents. It needs to be read in conjunction with RFC 7665 and other documents as the SFC control plane I-D in order to make sense of the required functionality. This part of the SFC solution seems almost ready, but a few issues mentioned below need in my opinion clarification before the document is approved. Thank you for this summary — you raise good points. Major issues: 1. Section 11.1 claims: 'An IEEE EtherType, 0x894F, has been allocated for NSH'. I could not find this value in the tables displayed by the IEEE Registration Authority (RAC) - for example at http://standards-oui.ieee.org/ethertype/eth.txt. Neither does IANA at https://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbers.xhtml (which would not be in any case the authoritative source). Can you please indicate the source that this is indeed a confirmed IEEE EtherType registration. I am not sure how often that page is updated, but the same link you include, http://standards-oui.ieee.org/ethertype/eth.txt, shows: 0x894F 894F: NSH (Network Service Header). Reference: draft-ietf-sfc-nsh-18 Granted, that registration will be updated with the RFC number instead of the I-D, when it publishes. 2. Section 5 refers to ietf-rtgwg-dt-encap which is expired. If I understand correctly the status of this work, there is a design team in place in the Routing Area created to look at common issues for the different data plane encapsulations being discussed in various WGs including SFC. This leaves the issue unsettled at this stage and this may be a problem for a standards track document. I suggest that first the reference to the expired document is removed, second that the issue is marked as 'open' and subject for future work. Good suggestion. Instead of removing the reference all together, we can mark it as exemplifying of one approach. Minor issues: 1. Two values 'Experiment 1' and 'Experiment 2' are defined in section 2.2 and 11.2.5 for the Next Protocol. This seems a little odd. Why 2? Why are they defined at the end of the range? Maybe there is an explanation for those who know the history but for an un-initiated reader or a future implementer this seems odd. There is no strong rational behind the number of values (two) or the location (towards the end of the range). There are two values as it seems appropriate given the same of the number space (2 out of 256). Perhaps, it’s somewhat following common practice started at https://tools.ietf.org/html/rfc3692#section-2.1 (2 values for and 8-bit field, closer to the end). 2. In Section 2.2 I see: All other flag fields, marked U, are unassigned and available for future use, see Section 11.2.1. Unassigned bits MUST be set to zero upon origination, and MUST be ignored and preserved unmodified by other NSH supporting elements. Elements which do not understand the meaning of any of these bits MUST NOT modify their actions based on those unknown bits. The way the last sentence is written it seems to open the path for elements that claim to 'understand' the meaning of some Unassigned bit to modify its behavior based upon it. This does not seem good, as at transmission all Unassigned bits MUST be set to zero. I would suggest to make the statement simpler and just say that at reception all elements MUST NOT modify their actions based on these bits. Very good point, and good improvement. Applied. 3. In Section 2.2 I see: 0xF - This value is reserved for experimentation and testing, as per [RFC3692]. Implementations not explicitly configured to be part of an experiment SHOULD silently discard packets with MD Type 0xF. Why is this a SHOULD and not a MUST? To use MUSTs very sparingly and leave a little bit of leeway for experimentation, following appropriate justification. 4. I believe that [I-D.ietf-sfc-control-plane] needs to be a Normative Reference. There are several places in the document (e.g. in Section 2.3) where this document is referred to describe behavior or actions related to the fields of the header. The control plane I-D is, by WG decision, intended to not be normative as NSH is the data plane independent of the CP spec. I see that [I-D.ietf-sfc-control-plane] is cited in two places: 1. [I-D.ietf-sfc-control-plane] provides an example of such in 2. process. These considerations are deployment-specific. However, the control plane is entitled to instruct SFC-aware SFs with the data structure of context header together with its scoping (see Section 3.3.3 of [I-D.ietf-sfc-control-plane]). We already caught the issue with #2 and changed it to, in our working copy working with the chairs, to: process. These considerations are deployment-specific. However, the control plane is entitled to instruct SFC-aware SFs with the data structure of context header together with its scoping (see e.g., Section 3.3.3 of [I-D.ietf-sfc-control-plane]). As that’s one possible, and non-normative way, out of many ways. 5. The version number has only two bits assigned. Moreover, this document reserves already two values without any explanation why (only 00 is mandatory to use, as far as I understand). This needs to be explained (maybe 'historical' reasons - but unclear for future readers and users) and may be a limitation as the protocol develops. The version field is indeed a two-bit field. One reserved and will not be used. One used by this spec, and two unassigned ones. We really expect to not be bumping up version number ofter — or ever… Nits/editorial comments: 1. Please make sure that acronyms are expanded at first occurrence (e.g
- Genart last call review of draft-ietf-sfc-nsh-19 Dan Romascanu
- Re: Genart last call review of draft-ietf-sfc-nsh… Carlos Pignataro (cpignata)
- Re: Genart last call review of draft-ietf-sfc-nsh… Dan Romascanu
- Re: Genart last call review of draft-ietf-sfc-nsh… Carlos Pignataro (cpignata)