Re: [Pce] Shepherd's review of draft-ietf-pce-pcep-exp-codepoints

Jonathan Hardwick <Jonathan.Hardwick@metaswitch.com> Mon, 13 November 2017 00:08 UTC

Return-Path: <Jonathan.Hardwick@metaswitch.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 2B3A41200C5; Sun, 12 Nov 2017 16:08:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.02
X-Spam-Level:
X-Spam-Status: No, score=-2.02 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_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=metaswitch.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 mqor6wyjwaUk; Sun, 12 Nov 2017 16:08:07 -0800 (PST)
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0104.outbound.protection.outlook.com [104.47.33.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EDCE124F57; Sun, 12 Nov 2017 16:08:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metaswitch.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=cIzEBw4fzv7jnXUcUES11BNvDVFuDZ3CuXlALJO6prQ=; b=I7RRRlb6T/jOsI0yeGIo9DRw45qNypvhNMgBoV8r25QSW2+VReHdkejT59Lcqag8fevPSOlYAfeDB48d+x2bftdiaOkgKLM4tyu4o8NfrvP99SE1aSeBgLSITemcA2PCJ77xT3p+pcR4d3vxH6WLVEjjKguzMCgky13o6/2EYX0=
Received: from CY4PR0201MB3603.namprd02.prod.outlook.com (52.132.99.21) by CY4PR0201MB3603.namprd02.prod.outlook.com (52.132.99.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.218.12; Mon, 13 Nov 2017 00:08:03 +0000
Received: from CY4PR0201MB3603.namprd02.prod.outlook.com ([fe80::dce9:6773:68c7:10f3]) by CY4PR0201MB3603.namprd02.prod.outlook.com ([fe80::dce9:6773:68c7:10f3%13]) with mapi id 15.20.0218.011; Mon, 13 Nov 2017 00:08:03 +0000
From: Jonathan Hardwick <Jonathan.Hardwick@metaswitch.com>
To: Dhruv Dhody <dhruv.dhody@huawei.com>, "draft-ietf-pce-pcep-exp-codepoints@ietf.org" <draft-ietf-pce-pcep-exp-codepoints@ietf.org>
CC: "pce@ietf.org" <pce@ietf.org>, "pce-chairs@ietf.org" <pce-chairs@ietf.org>, 'Dhruv Dhody' <dhruv.ietf@gmail.com>
Thread-Topic: Shepherd's review of draft-ietf-pce-pcep-exp-codepoints
Thread-Index: AdNbazxoJX1mpJIUTGiD0iKyZXkw0wAQjYAAABhtNqA=
Date: Mon, 13 Nov 2017 00:08:03 +0000
Message-ID: <CY4PR0201MB360311691273119057CF6339842B0@CY4PR0201MB3603.namprd02.prod.outlook.com>
References: <CY4PR0201MB36030DD4394ABF68124A5CFA842A0@CY4PR0201MB3603.namprd02.prod.outlook.com> <23CE718903A838468A8B325B80962F9B8D5C30A9@BLREML503-MBX.china.huawei.com>
In-Reply-To: <23CE718903A838468A8B325B80962F9B8D5C30A9@BLREML503-MBX.china.huawei.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Jonathan.Hardwick@metaswitch.com;
x-originating-ip: [203.127.152.4]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY4PR0201MB3603; 6:YFY/5u3PCdgYSUHXymtC9inUAqNEOIBWhdoemrtsDi7jFmCuR2FIhkL7DvmG7mdLTAi2HJp8VC23D7haoA+4IbbMDx0Fm+8w6OW9isxCAa2rscb0oROQUIWTbaN4ioSJBJJoB/4vwtJArIn+K0ejaof9nkNdZd1oR5eHzL7zwtmGZyJclfx6UT2WeWQgvO24FjjL4hvy43SQx5dm5KKO7EHHhs/xgxTCYGQpk2RvJGQ1WSKtDR3e4RGcm3IGR3UAqnpuaqrzSajoYEKay874p6K2BW6kQ6FAdFLqQ8qW8e98HgrQIu7JVYCoXVY7puMS8w7DFoGNDZUmlBIG6WAc67/e0c3wyxtqNpNSfvOUwNg=; 5:6YoyTe+Dtks5VhBj/pIRxj4i7TwTCPNABklbkysh0SS45nhoPP7spQXWG0iD0+A6Fn6Y6iPniqIVtejItI6cTFj/cTskAbVAnyiICnwVtkKgdtJ1rxrHynSACrivmQ639P4UyW3raXhrYrTV/OC4+7kjVzQPjWCAz2HfihkCe4o=; 24:lf2D/oQQejK9ryvjcsG8xmV65LWuNepNFgSUxtnAUfMYMTfSpt/RYzlwBz6mN3R5gBVUfleNkVuuER2vHcg8fsE9btJjC3YOf1+j68qBcZM=; 7:atiYMuTP0fIe0lhAsEMOZKTTTljBDwbMLcN8h7hgerlczDh6IbyptlhEyjmA2ogbs6OdFC3orE3RhiLsKHhg6gFZ4ODOgyn7RMo/3goJ7J6HKltY500P3IF4keRNKIaqN4N1FrGH5Zcik9U7Qss1SQohTUn7d+7Hf/ruxHhmABgYrRZik3AaoVHwxYpJFmBwzQqkwNUEeT1NApbpEgX8FUQmySoF2Wx4NFAdmliJDw6CPekE5JpH5Chv/fCq3Tbc
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: a343cb1c-ea50-4359-25ff-08d52a2a9bfa
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:CY4PR0201MB3603;
x-ms-traffictypediagnostic: CY4PR0201MB3603:
x-microsoft-antispam-prvs: <CY4PR0201MB3603A2BE8B2A0FE3D94BD605842B0@CY4PR0201MB3603.namprd02.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(93006095)(93001095)(3002001)(10201501046)(3231022)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR0201MB3603; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR0201MB3603;
x-forefront-prvs: 0490BBA1F0
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(346002)(189002)(199003)(76104003)(790700001)(3660700001)(2906002)(316002)(110136005)(86362001)(54906003)(106356001)(105586002)(6506006)(4326008)(3280700002)(7736002)(8936002)(81156014)(8676002)(81166006)(229853002)(6436002)(14454004)(2950100002)(3846002)(55016002)(102836003)(54896002)(66066001)(25786009)(6116002)(39060400002)(33656002)(6306002)(76176999)(50986999)(7696004)(5660300001)(9686003)(6246003)(2501003)(189998001)(53936002)(99286004)(72206003)(54356999)(478600001)(97736004)(2900100001)(5250100002)(68736007)(101416001)(230783001)(74316002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR0201MB3603; H:CY4PR0201MB3603.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: metaswitch.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY4PR0201MB360311691273119057CF6339842B0CY4PR0201MB3603_"
MIME-Version: 1.0
X-OriginatorOrg: metaswitch.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a343cb1c-ea50-4359-25ff-08d52a2a9bfa
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Nov 2017 00:08:03.5398 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR0201MB3603
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/CAljvCN_KytVKQ_yoyg_MpeeTIw>
Subject: Re: [Pce] Shepherd's review of draft-ietf-pce-pcep-exp-codepoints
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.22
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, 13 Nov 2017 00:08:09 -0000

Hi Dhruv

Thanks for this.  Trimming to the open points:

Introduction

The second paragraph is superfluous - I suggest deleting:

   Further, in order to support use cases described in [RFC8051],

   [I-D.ietf-pce-stateful-pce] specifies a set of extensions to PCEP to

   enable stateful control of MPLS-TE and GMPLS LSPs via PCEP.

   [I-D.ietf-pce-pce-initiated-lsp] describes the setup, maintenance and

   teardown of PCE-initiated LSPs under the stateful PCE model.

[[[Dhruv Dhody]]] Because of the comment for handling the unknown experimental objects for the stateful PCE messages, I think it is better to continue to keep this text. What do you think?

[Jon] Right - OK to leave it.  But then I think these have to become normative references.

Section 5

The following paragraph does not tell the whole story.

   A PCE that does not recognize an experimental PCEP object, will
   reject the entire PCEP message and send a PCE error message with
   Error- Type="Unknown Object" or "Not supported object" as described
   in [RFC5440].

If the P flag is clear in the object header, then the PCE MAY ignore the object instead of generating this error message. Also, you do not discuss what a PCC would do on receipt of a PCUdp or PCInitiate containing an unrecognised experimental object - it is inconsistent that you don't cover these cases.  (FWIW, RFC 8231 is a bit ambiguous about what a PCC should do about the PCUpd. Section 6.2 says that a PCErr should be sent, but then it refers to section 7.3.3, which says that a PCRpt should be sent. Hmmm.)

[[[Dhruv Dhody]]] Yes. How about I update to this -

   If the PCE does not understand or support an experimental object with
   the P flag set in the Object Header, in the Path Computation Request
   message (PCReq), the entire PCEP message is rejected and PCE responds
   with a PCErr message with Error-Type="Unknown Object" or "Not
   supported object" as described in [RFC5440].  Otherwise the object is
   ignored.  In case of stateful PCE messages [RFC8231], the P flag is
   ignored and the unknown object handling is as per the stateful PCE
   extensions.

And let's try to handle the inconsistency in RFC 8231 with an errata perhaps? And handle PCE-initiated during AUTH48?

[Jon] I think this is OK, but if we are just going to point the reader at RFC8231, then we might as well do the same with RFC5440, rather than duplicate its text.  And we should write something that allows for the possibility that more message types may be relevant in future.  How about

   If a PCEP speaker does not understand or support an experimental object
   then the way it handles this situation depends on the message type.
   For example, a PCE handles an unknown object in the Path Computation Request
   (PCReq) message according to the rules of [RFC5440].  A PCC handles an
   unknown object in an Update (PCUpd) message according to the rules of [RFC8231]
   and, in an LSP Initiate Request (PCInitiate) message, according to the rules of
   [I-D.ietf-pce-pce-initiated-lsp].  Any document that adds a new PCEP message
   type must specify how to handle unknown objects on that message.

Note that this last sentence is not an RFC2119 MUST because it defines author behaviour, not device behaviour.