Re: [Pce] Shepherd's review of draft-ietf-pce-pcep-exp-codepoints
Julien Meuric <julien.meuric@orange.com> Fri, 17 November 2017 17:29 UTC
Return-Path: <julien.meuric@orange.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 4B9B8128C9C; Fri, 17 Nov 2017 09:29:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.94
X-Spam-Level:
X-Spam-Status: No, score=0.94 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_BRBL_LASTEXT=1.449, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 cEP0Ip88EAD4; Fri, 17 Nov 2017 09:29:36 -0800 (PST)
Received: from p-mail2.rd.orange.com (p-mail2.rd.orange.com [161.106.1.3]) by ietfa.amsl.com (Postfix) with ESMTP id 244EC1292F5; Fri, 17 Nov 2017 09:29:36 -0800 (PST)
Received: from p-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 3989DE300C6; Fri, 17 Nov 2017 18:29:35 +0100 (CET)
Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by p-mail2.rd.orange.com (Postfix) with ESMTP id 18F2AE300BF; Fri, 17 Nov 2017 18:29:35 +0100 (CET)
Received: from [10.193.71.63] (10.193.71.63) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.361.1; Fri, 17 Nov 2017 18:29:34 +0100
From: Julien Meuric <julien.meuric@orange.com>
To: Dhruv Dhody <dhruv.dhody@huawei.com>, Jonathan Hardwick <Jonathan.Hardwick@metaswitch.com>
CC: "draft-ietf-pce-pcep-exp-codepoints@ietf.org" <draft-ietf-pce-pcep-exp-codepoints@ietf.org>, "pce@ietf.org" <pce@ietf.org>, 'Dhruv Dhody' <dhruv.ietf@gmail.com>
References: <CY4PR0201MB36030DD4394ABF68124A5CFA842A0@CY4PR0201MB3603.namprd02.prod.outlook.com> <23CE718903A838468A8B325B80962F9B8D5C30A9@BLREML503-MBX.china.huawei.com> <CY4PR0201MB360311691273119057CF6339842B0@CY4PR0201MB3603.namprd02.prod.outlook.com> <23CE718903A838468A8B325B80962F9B8D5C3537@BLREML503-MBX.china.huawei.com>
Organization: Orange
Message-ID: <62ab8db3-ba39-99f6-a038-264f9800ea39@orange.com>
Date: Fri, 17 Nov 2017 18:29:34 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <23CE718903A838468A8B325B80962F9B8D5C3537@BLREML503-MBX.china.huawei.com>
Content-Type: text/html; charset="windows-1252"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/xFxF2qrvGxcpE5lYLUdLVhFFJ9c>
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: Fri, 17 Nov 2017 17:29:38 -0000
IMHO, the correct wording lies in between. RFC 5440 set the default for PCEP ("A PCEP-ERROR object is used to report a PCEP error"). Further specification (e.g. RFC 8231) MAY add message-specific behavior, but I think it is wrong to mandate a new behavior for each new message. I would thus suggest :
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. Message-specific behavior MAY be specified (e.g., [RFC8231]
defines rules for a PCC to handle an unknown object in an Update
(PCUpd) message).
My 2 cents,
Julien
<snip>
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.
- [Pce] Shepherd's review of draft-ietf-pce-pcep-ex… Jonathan Hardwick
- Re: [Pce] Shepherd's review of draft-ietf-pce-pce… Dhruv Dhody
- Re: [Pce] Shepherd's review of draft-ietf-pce-pce… Jonathan Hardwick
- Re: [Pce] Shepherd's review of draft-ietf-pce-pce… Dhruv Dhody
- Re: [Pce] Shepherd's review of draft-ietf-pce-pce… Julien Meuric
- Re: [Pce] Shepherd's review of draft-ietf-pce-pce… Adrian Farrel
- Re: [Pce] Shepherd's review of draft-ietf-pce-pce… Jonathan Hardwick