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

["BRUNGARD, DEBORAH A" <[e-mail]>]

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.

Thanks!
Deborah


-----Original Message-----
From: Vigoureux, Martin (Nokia - FR/Paris-Saclay) <[e-mail]> 
Sent: Tuesday, October 01, 2019 4:45 AM
To: BRUNGARD, DEBORAH A <[e-mail]>; Dhruv Dhody <[e-mail]>
Cc: pce-chairs <[e-mail]>; [e-mail]; The IESG <[e-mail]>; [e-mail]; Hariharan Ananthakrishnan <[e-mail]>
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.

-m

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 <[e-mail]> On Behalf Of Dhruv Dhody
> Sent: Monday, September 30, 2019 7:28 AM
> To: Martin Vigoureux <[e-mail]>
> Cc: pce-chairs <[e-mail]>; [e-mail]; The IESG 
> <[e-mail]>; [e-mail]; 
> Hariharan Ananthakrishnan <[e-mail]>
> 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 <[e-mail]> 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
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_ies
>> 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:
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.
>> 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=
>>
>>
>>
>> ---------------------------------------------------------------------
>> -
>> COMMENT:
>> ---------------------------------------------------------------------
>> -
>>
>> 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
>