Re: [Pce] Chair review of draft-lee-pce-flexible-grid
Leeyoung <leeyoung@huawei.com> Mon, 11 March 2019 23:57 UTC
Return-Path: <leeyoung@huawei.com>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD98A1310C6; Mon, 11 Mar 2019 16:57:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 Plcgc3Kpmary; Mon, 11 Mar 2019 16:57:26 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 88A5C129A87; Mon, 11 Mar 2019 16:57:26 -0700 (PDT)
Received: from lhreml703-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id B332FA7DD74751189F3D; Mon, 11 Mar 2019 23:57:24 +0000 (GMT)
Received: from lhreml703-chm.china.huawei.com (10.201.108.52) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 11 Mar 2019 23:57:24 +0000
Received: from lhreml703-chm.china.huawei.com (10.201.108.52) by lhreml703-chm.china.huawei.com (10.201.108.52) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10; Mon, 11 Mar 2019 23:57:24 +0000
Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml703-chm.china.huawei.com (10.201.108.52) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1591.10 via Frontend Transport; Mon, 11 Mar 2019 23:57:24 +0000
Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.179]) by SJCEML702-CHM.china.huawei.com ([169.254.4.15]) with mapi id 14.03.0415.000; Mon, 11 Mar 2019 16:57:18 -0700
From: Leeyoung <leeyoung@huawei.com>
To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "pce@ietf.org" <pce@ietf.org>
CC: "draft-lee-pce-flexible-grid@ietf.org" <draft-lee-pce-flexible-grid@ietf.org>
Thread-Topic: Chair review of draft-lee-pce-flexible-grid
Thread-Index: AdTH1ne8wAMTGhb+QVaFcbbLKJ8c6wG7qR1Q
Date: Mon, 11 Mar 2019 23:57:17 +0000
Message-ID: <7AEB3D6833318045B4AE71C2C87E8E173D0FA3C7@sjceml521-mbx.china.huawei.com>
References: <028a01d4c7d6$a38fdc30$eaaf9490$@olddog.co.uk>
In-Reply-To: <028a01d4c7d6$a38fdc30$eaaf9490$@olddog.co.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.145.78]
Content-Type: multipart/mixed; boundary="_002_7AEB3D6833318045B4AE71C2C87E8E173D0FA3C7sjceml521mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/RObEXrxqqUX4buYsDxb89ef-j6A>
Subject: Re: [Pce] Chair review of draft-lee-pce-flexible-grid
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pce/>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Mar 2019 23:57:30 -0000
Hi Adrian, Thanks for your chair's review. Please see inline for my comment. 01 version has been uploaded (please see the attachment). Note: I might have made mistakes as I was rush to meet the deadline :) Best regards, Young -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Monday, February 18, 2019 4:10 PM To: pce@ietf.org Cc: draft-lee-pce-flexible-grid@ietf.org Subject: Chair review of draft-lee-pce-flexible-grid Hi, As this document is being polled for adoption, I thought I should review it. There are a considerable number of nits, but nothing that prevents adoption in my view. In the event that this document is adopted, I think the authors would do well to address the changes shortly afterwards. If the document is not adopted but the authors want to continue with the work, they should pick up these nits. Thanks, Adrian --- Please fix the RFC 2119 boilerplate to use the latest form... The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. ...You'll need to add a reference to RFC 8174 --- idnits shows a lot of issues with references. It is not hard to run idnits so please get into the habit of running it before you ask for WG adoption. For your convenience, here are all of the issues == Missing Reference: 'RFC3209' is mentioned on line 318, but not defined == Unused Reference: 'RFC2863' is defined on line 654, but no explicit reference was found in the text == Unused Reference: 'RFC6566' is defined on line 683, but no explicit reference was found in the text == Unused Reference: 'RFC7420' is defined on line 687, but no explicit reference was found in the text == Unused Reference: 'RFC7446' is defined on line 692, but no explicit reference was found in the text == Unused Reference: 'RFC5521' is defined on line 708, but no explicit reference was found in the text == Unused Reference: 'RFC6205' is defined on line 712, but no explicit reference was found in the text == Unused Reference: 'RFC7689' is defined on line 719, but no explicit reference was found in the text == Unused Reference: 'RFC7688' is defined on line 722, but no explicit reference was found in the text == Unused Reference: 'RFC7581' is defined on line 731, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 7698 The last issue is a warning, and you can keep the downwards reference if you think it is the right thing to do. --- Please check that all abbreviations are expanded on first use. I see: ERO PCE --- Move the first sentence of paragraph 4 of Section 3 down to the end of that paragraph so that the use of the term "flexi-grid" comes after it has been explained. --- Section 3 has This document provides PCEP extensions to support Routing and Spectrum Assignment (RSA) in in Spectrum Switched Optical Networks (SSON)[RFC7698]. s/in in/ s/(SSON)[RFC7698]/(SSON} [RFC7698]/ The terms RSA and SSON are, of course, defined in RFC 7698. But the terms come as a surprise in this document. Perhaps you could insert a short paragraph above this one to say... The terms "Routing and Spectrum Assignment" (RSA) is introduced in [RFC7698] to refer to blah blah. The term "Spectrum Switched Optical Networks" is also introduced in [RFC7698] and indicates a network that is blah blah blah. That would leave you with This document provides PCEP extensions to support RSA in SSONs. --- Section 3 s/extensions are going to be specified/extensions are specified/ --- Section 4 Bullet b) has a second sentence (beginning "This document aligns...") that doesn't seem specific to that bullet. Maybe it belongs at the top of the section. --- Section 4 has Additionally, given a range of potential spectrums to allocate, the request SHOULD convey the heuristic / mechanism to the allocation. The reader is left wondering how to meet that "SHOULD" and also why to vary that "SHOULD". --- Section 4 needs a reference to RFC 5511 to explain the notation. --- Section 4 If the SA object is present in the request, it MUST be encoded after the ENDPOINTS object. I think that should be 'GENERALIZED ENDPOINTS object' --- Section 4 has The following new flags SHOULD be set But I think you are equally happy for the bit to be set or cleared. YL>> OLD: The following new flag SHOULD be set NEW: One flag bit is allocated as follows: --- 4.1 This TLV MUST NOT be used when the M bit is cleared. I think you may mean... SHOULD NOT be present and MUST be ignored YL>> Yes. OLD: This TLV MUST NOT be used when the M bit is cleared. NEW: This TLV SHOULD not be present and MUST be ignored when the M bit is cleared. --- I think you are going to need an IANA registry for the Frequency-Slot Assignment (FSA) Method. YL>> Yes, added. NEW: IANA is to allocate a new PCEP TLV type, Frequency-Slot Selection TLV (TBD2) in the "PCEP TLV Type Indicators" subregistry (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type-indicators). --- 4.1 is going to need an explanation of what the 'n' parameter is. YL>> Yes. Added: where "n" is the parameter in f = 193.1 THz + n x 0.00625 THz where 193.1 THz is the ITU-T "anchor frequency" and "n" is a positive integer including 0 [RFC7698]. --- 4.1 - S bit not supported: a PathErr MUST be generated with the Error Code "Routing Problem" (24) with error sub-code "Unsupported Frequency slot Selection Symmetry value" (TDB). This is a bit unclear. Presumably the issue is "S bit clear not supported". You might consider reversing the meaning of the S bit and then this would be a lot clearer. YL>> Done. --- Please distinguish the different TBDs as TBD1, TBD2, etc. (And note you have several cases of "TDB") YL>> yes. Added TBDX (where X=1,2,...) --- 4.1 As defined in [RFC7570], the R bit reflects the LSP_REQUIRED_ATTRIBUTE and LSP_ATTRIBUTE semantic defined in [RFC5420], and it SHOULD be set accordingly. It is not clear what R bit you are referring to. YL>> This paragraph was removed as this is an irrelevant discussion. --- 4.1 A Frequency Slot Selection TLV can be constructed by a node and added to an ERO Hop Attributes subobject in order to be processed by downstream nodes (transit and egress). As defined in [RFC7570], the R bit reflects the LSP_REQUIRED_ATTRIBUTE and LSP_ATTRIBUTE semantic defined in [RFC5420], and it SHOULD be set accordingly. Once a node properly parses the Spectrum Selection sub-TLV received in an ERO Hop Attributes subobject, the node use the indicated spectrum assignment method (at that hop) for the LSP. In addition, the node SHOULD report compliance by adding an RRO Hop Attributes subobject with the WSON Processing Hop Attribute TLV (and its sub-TLVs) that indicate the utilized method. Frequency-Slot Selection TLVs carried in an RRO Hop Attributes subobject are subject to [RFC7570] and standard RRO processing; see [RFC3209]. There's something odd here. - Doesn't this section say/imply that the Frequency-Slot Selection TLV belongs in the Spectrum Assignment object? Why are you talking about TLVs in the Hop Attribute TLV and the ERO Hop Attributes subobject? Maybe the first paragraph here should read... A Frequency Slot Selection TLV can also be constructed by a node... - Why are you talking about the Spectrum Selection sub-TLV? Doesn't that belong in Section 5? YL>> Thanks for pointing this out. You are correct. These two paragraphs do not belong here. Deleted. --- 4.2 For any request that contains a Frequency-slot assignment, the requester (PCC) MUST be able to specify a restriction on the frequency-slots to be used. I think you can s/MUST/must/ YL>> Yes. Corrected. --- 4.2 <Frequency-lot Restriction Constraint> ::= <Action> <Count> <Reserved> (<Link Identifiers> <Freq-slot Restriction>)... I don't think you need to list every field of the frequency slot TLV in the RBNF, and in particular you should not list the reserved field. YL>> Actually the following is the right RBNF: NEW <Frequency-lot Restriction Constraint> ::= ( <Action> <Count> <Reserved> <Link Identifiers> <Freq-slot Restriction>)... With this correction, I think I can further reduce it as follows: <Frequency-lot Restriction Constraint> ::= ( <Action> <Link Identifiers> <Freq-slot Restriction>)... Is this OK with you? --- 4.2 Note that a PCC MAY add a spectrum restriction that applies to all links by setting the Count field to zero and specifying just a set of spectrums. I think s/spectrum/frequency slot/ twice YL>> Agreed and corrected. --- 4.2 and Section 3.3.1 for the Spectrum Restriction Field encoding, respectively. Why do you point us at the definition of this field? YL>> Yes, it is not necessary; removed. --- 4.2.1 broken reference YL>> It is corrected to point to Section 4.2 --- 5. The Spectrum Allocation TLV type is TBD, recommended value is TBD. No need to recommend a value of TBD :-) YL>> "recommended value is TBD" delete. --- 5. The type value of the Spectrum Restriction Constraint TLV is TBD by IANA. This seems out of place and is the first mention of this TLV. YL>> Deleted. Instead before Figure 4, added "IANA is to allocate a new PCEP TLV type, the Spectrum Allocation TLV Type (TBD). --- Section 7 could use some external references. Added: G.694.1 and G.872. --- Section 8 IANA maintains a registry of PCEP parameters. IANA has made allocations from the sub-registries as described in the following sections. Hmmm, I think IANA has not actually made these allocations. You should say "IANA is requested to make allocations..." --- I think the titles of 9.1 and 9.2 may be reversed.
--- Begin Message ---A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element WG of the IETF. Title : PCEP Extension for Flexible Grid Networks Authors : Young Lee Haomian Zheng Ramon Casellas Ricard Vilalta Daniele Ceccarelli Francesco Lazzeri Filename : draft-ietf-pce-flexible-grid-01.txt Pages : 20 Date : 2019-03-11 Abstract: This document provides the Path Computation Element Communication Protocol (PCEP) extensions for the support of Routing and Spectrum Assignment (RSA) in Flexible Grid networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-flexible-grid/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-pce-flexible-grid-01 https://datatracker.ietf.org/doc/html/draft-ietf-pce-flexible-grid-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-flexible-grid-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce--- End Message ---
- [Pce] Chair review of draft-lee-pce-flexible-grid Adrian Farrel
- Re: [Pce] Chair review of draft-lee-pce-flexible-… Leeyoung
- Re: [Pce] Chair review of draft-lee-pce-flexible-… Dhruv Dhody
- Re: [Pce] Chair review of draft-lee-pce-flexible-… Leeyoung
- Re: [Pce] Chair review of draft-lee-pce-flexible-… Leeyoung
- Re: [Pce] Chair review of draft-lee-pce-flexible-… Gabriele Maria Galimberti (ggalimbe)
- Re: [Pce] Chair review of draft-lee-pce-flexible-… Adrian Farrel
- Re: [Pce] Chair review of draft-lee-pce-flexible-… Leeyoung
- Re: [Pce] Chair review of draft-lee-pce-flexible-… Leeyoung