Re: [Pce] Martin Vigoureux's No Objection on draft-ietf-pce-lsp-control-request-09: (with COMMENT)

"BRUNGARD, DEBORAH A" <> Tue, 01 October 2019 22:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 79D67120168; Tue, 1 Oct 2019 15:24:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yRPVfAWTIezF; Tue, 1 Oct 2019 15:24:14 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A2CA912012C; Tue, 1 Oct 2019 15:24:14 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id x91MFfmo018803; Tue, 1 Oct 2019 18:24:13 -0400
Received: from ( []) by with ESMTP id 2vcf3dgq3e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 01 Oct 2019 18:24:13 -0400
Received: from (localhost []) by (8.14.5/8.14.5) with ESMTP id x91MOBth003419; Tue, 1 Oct 2019 18:24:11 -0400
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id x91MO6QC003365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 1 Oct 2019 18:24:06 -0400
Received: from ( []) by (Service) with ESMTP id 4488D4009E8E; Tue, 1 Oct 2019 22:24:06 +0000 (GMT)
Received: from (unknown []) by (Service) with ESMTPS id 28A364009E8C; Tue, 1 Oct 2019 22:24:06 +0000 (GMT)
Received: from ([]) by ([]) with mapi id 14.03.0468.000; Tue, 1 Oct 2019 18:24:05 -0400
To: "Vigoureux, Martin (Nokia - FR/Paris-Saclay)" <>, Dhruv Dhody <>
CC: pce-chairs <>, "" <>, The IESG <>, "" <>, Hariharan Ananthakrishnan <>
Thread-Topic: Martin Vigoureux's No Objection on draft-ietf-pce-lsp-control-request-09: (with COMMENT)
Thread-Index: AQHVd4JEhvkCSsjTpUO5HkMCNB1mjKdErbWggAEPeACAAJj2EA==
Date: Tue, 1 Oct 2019 22:24:05 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-10-01_10:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1910010185
Archived-At: <>
Subject: Re: [Pce] Martin Vigoureux's No Objection on draft-ietf-pce-lsp-control-request-09: (with COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Path Computation Element <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 01 Oct 2019 22:24:18 -0000

As it seems there are still some questions on "update or not", I'll try to add some additional context. As we know, it is difficult to define "update", so each working group has their context for it. For TEAS, CCAMP, MPLS, PCE, if it is a new capability, which is making use of previously reserved bits, we have not considered it an update, otherwise every new RFC would be an update of the base RFC.

Here's an example of exactly this (a quick scan by me, I'm sure there are many more across all the groups):
The PCE-CAP-FLAGS sub-TLV was defined in RFC5088 (bits 9-31 were reserved). RFC 8623 defined stateful P2MP and defined new capability bits (from the reserved group) using 13, 14, 15. It was not considered an update of RFC5088 (OSPF extensions for PCE Discovery), or RFC8306 (P2MP TE LSPs for PCEP), or RFC8281 (base document with extensions to support stateful PCE). And RFC5088 was not an update of OSPF (RFC2328 and RFC2740). And RFC8281 was not an update to RFC5440 PCEP base spec). As you can see, this would result in a very big waterfall if all these were considered updates. An implementor of the base spec, with no interest in these new capabilities, would need to read all the updates just to be sure the base is not impacted. We wouldn't have any implementations, everyone would still be readingūüėä

In this document, these new values are using several more of the previously reserved values. Only implementors of this new capability need to be aware of these assignments, so among PCE folks, it is not considered an update.

Dhruv already responded to Ben on the PLSP-ID. It is the same as these flags, only those wanting to implement this new capability need to be aware of it. And it is backwards compatible with the base spec.


-----Original Message-----
From: Vigoureux, Martin (Nokia - FR/Paris-Saclay) <> 
Sent: Tuesday, October 01, 2019 4:45 AM
To: BRUNGARD, DEBORAH A <>om>; Dhruv Dhody <>
Cc: pce-chairs <>rg>;; The IESG <>rg>;; Hariharan Ananthakrishnan <>
Subject: Re: Martin Vigoureux's No Objection on draft-ietf-pce-lsp-control-request-09: (with COMMENT)

Thank you Deborah

I'm not entirely convinced. In my view the change is likely to have an impact on existing implementations (error handling part). From that point of view I feel Update wouldn't hurt in the sense that someone implementing 8231 might want to know that impact in advance. But we are down in the foggy subtleties of "Updates".
It might more be the case for an "Extends/Extended by".

Thank you for discussing my comment.


Le 2019-09-30 à 22:45, BRUNGARD, DEBORAH A a écrit :
> Hi,
> RFC8231 implementations do not need to be aware of this RFC's capability. Only for those wanting to support this new capability, they will follow this RFC.
> As the capability is optional - not required for RFC8231 implementations - to me that's an "extension", not an "update".
> Thanks!
> Deborah
> -----Original Message-----
> From: iesg <> On Behalf Of Dhruv Dhody
> Sent: Monday, September 30, 2019 7:28 AM
> To: Martin Vigoureux <>
> Cc: pce-chairs <>rg>;; The IESG 
> <>rg>;; 
> Hariharan Ananthakrishnan <>
> Subject: Re: Martin Vigoureux's No Objection on 
> draft-ietf-pce-lsp-control-request-09: (with COMMENT)
> Hi Martin,
> Thanks for your review, request authors to chime in as needed.
> On Mon, Sep 30, 2019 at 3:23 PM Martin Vigoureux via Datatracker <> wrote:
>> Martin Vigoureux has entered the following ballot position for
>> draft-ietf-pce-lsp-control-request-09: No Objection
>> When responding, please keep the subject line intact and reply to all 
>> email addresses included in the To and CC lines. (Feel free to cut 
>> this introductory paragraph, however.)
>> Please refer to
>> g 
>> _statement_discuss-2Dcriteria.html&d=DwIBaQ&c=LFYZ-o9_HUMeMTSQicvjIg&
>> r 
>> =6UhGpW9lwi9dM7jYlxXD8w&m=KTlgQC1T5yVjjuykht4r_tb9Z8KmolfZvjbnrdrTltE
>> & s=-lWEB25n3fmFCK0XDlsLE5aD_o2TOZgcVBAwzBsEYDk&e=
>> for more information about IESG DISCUSS and COMMENT positions.
>> The document, along with other ballot positions, can be found here:
>> org_doc_draft-2Dietf-2Dpce-2Dlsp-2Dcontrol-2Drequest_&d=DwIBaQ&c=LFYZ
>> - 
>> o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=KTlgQC1T5yVjjuykht4r_tb9
>> Z 8KmolfZvjbnrdrTltE&s=bK1VoQrU3l_ECgvjAVBHkS2ioansSJs0DE0by5fo3bg&e=
>> ---------------------------------------------------------------------
>> -
>> ---------------------------------------------------------------------
>> -
>> Hi,
>> thank you for this document.
>> This document indicates:
>> "...MUST NOT trigger the error condition for unknown PLSP-ID in an 
>> LSP update request as per [RFC8231] ...". "...MUST NOT trigger the 
>> error handling as specified in [RFC8231] ...".
>> Yet, it also says:
>> The procedures for granting and relinquishing control of the LSPs are 
>> specified in accordance with the specification [RFC8231].
> Maybe we can add - "...unless explicitly set aside in this document."
>> So
>> 1/ it seems to me that the latter sentence, considering the first 
>> two, is not strictly correct. 2/ the rationale is well described, so 
>> I'm fine with not respecting the original rules of 8231, but then I 
>> wonder if this document shouldn't update 8231.
> I am not sure if this rises to the level of "update" (as I understand it and not taking the ongoing discussion on the topic); to me it is a normal extension of a protocol 'business as usual'!
> I think maybe it is time for some AD guidance on this :)
> Thanks!
> Dhruv