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

From: "Vigoureux, Martin (Nokia - FR/Paris-Saclay)" <[email-masked]>
Date: Tue, 1 Oct 2019 08:43:44 +0000

Dhruv,

thanks for your answer.

I like your proposed change.

I'll reply to Deborah's e-mail regarding the Update.
On that subject, have you seen:
https://datatracker.ietf.org/doc/html/draft-kuehlewind-update-tag-01 ?

-m

Le 2019-09-30 à 13:28, Dhruv Dhody a écrit :
> 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
> <[email-masked]> 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://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-pce-lsp-control-request/
>>
>>
>>
>> ----------------------------------------------------------------------
>> 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
>

---

From: "Vigoureux, Martin (Nokia - FR/Paris-Saclay)" <[email-masked]>
Date: Tue, 1 Oct 2019 08:45:26 +0000

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 <[email-masked]> On Behalf Of Dhruv Dhody
> Sent: Monday, September 30, 2019 7:28 AM
> To: Martin Vigoureux <[email-masked]>
> Cc: pce-chairs <[email-masked]>; [email-masked]; The IESG <[email-masked]>; [email-masked]; Hariharan Ananthakrishnan <[email-masked]>
> Subject: Re: Martin Vigoureux's No Objection on draft-ietf-pce-lsp-control-request-09: (with COMMENT)
> 
> Hi Martin,
> 
> On Mon, Sep 30, 2019 at 3:23 PM Martin Vigoureux via Datatracker <[email-masked]> wrote:
>>
>> 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_iesg
>> _statement_discuss-2Dcriteria.html&d=DwIBaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r
>> =6UhGpW9lwi9dM7jYlxXD8w&m=KTlgQC1T5yVjjuykht4r_tb9Z8KmolfZvjbnrdrTltE&
>> s=-lWEB25n3fmFCK0XDlsLE5aD_o2TOZgcVBAwzBsEYDk&e=
>> 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_tb9Z
>> 8KmolfZvjbnrdrTltE&s=bK1VoQrU3l_ECgvjAVBHkS2ioansSJs0DE0by5fo3bg&e=
>>
>>
>>
>> "...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].
>>
> 
>> 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'!
>

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Tue, 1 Oct 2019 22:24:05 +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.

Thanks!
Deborah

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

-m

Le 2019-09-30 à 22:45, BRUNGARD, DEBORAH A a écrit :
> Cc: pce-chairs <[email-masked]>; [email-masked]; The IESG 
> <[email-masked]>; [email-masked]; 
> Hariharan Ananthakrishnan <[email-masked]>
> Subject: Re: Martin Vigoureux's No Objection on 
> draft-ietf-pce-lsp-control-request-09: (with COMMENT)
> 
> Hi Martin,
> 
>> =6UhGpW9lwi9dM7jYlxXD8w&m=KTlgQC1T5yVjjuykht4r_tb9Z8KmolfZvjbnrdrTltE
>> & s=-lWEB25n3fmFCK0XDlsLE5aD_o2TOZgcVBAwzBsEYDk&e=
>> o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=KTlgQC1T5yVjjuykht4r_tb9
>> Z 8KmolfZvjbnrdrTltE&s=bK1VoQrU3l_ECgvjAVBHkS2ioansSJs0DE0by5fo3bg&e=
>>
>>
>>
>> "...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:
>> 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.
>>
>>
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 3 Oct 2019 11:03:33 -0700

Hi Deborah,

> 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 bas…

This all makes sense to me, and I see the reasoning behind not using
Updates: for them.  I'm not sure that our discussion here has covered the
relaxation of error handling, though -- we have "this MUST NOT trigger the
error handling as specified in [RFC8231]" in one place, and IIRC a similar
thing in one other place.  In some sense, this is overriding RFC 8231 and
an implementation of this spec is no longer compliant with the base RFC
8231 specification.  So, I wonder if the Updates: tag is needed in order to
"legitimize" this weakening of the requirements, as otherwise we have two
specifications which are formally in conflict with each other, one of which
is needed in order to use the other.

Thanks,

Ben

---

From: Dhruv Dhody <[email-masked]>
Date: Fri, 4 Oct 2019 12:10:53 +0530

Hi Ben,

On Thu, Oct 3, 2019 at 11:34 PM Benjamin Kaduk <[email-masked]> wrote:

> > 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.
> >
> > 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.
>
IMHO this is similar to a protocol extension of an existing protocol
message (with an updated parsing rules represented as RBNF). The base
protocol (RBNF) might consider the extension as mangled as per the rules of
the base RFC and trigger error but the extension overrides that.

In this case, the error handling text was added as a helpful note to an
implementer of this feature: to make sure that at the time of parsing, one
should check for the C flag first before doing RFC8231 check on PLSP-ID. An
existing RFC 8231 implementation (that does not implement this feature
requires) no change.

Maybe the current text goes overboard. We could reword this -

OLD:
   The PLSP-ID of 0
   indicates that the PCE wants control over all LSPs originating from
   the PCC.  A PCC that receives a PCUpd message with C Flag set to 1
   and PLSP-ID of 0 MUST NOT trigger the error condition for unknown
   PLSP-ID in an LSP update request as per [RFC8231].
NEW:
   The PLSP-ID of 0
   indicates that the PCE wants control over all LSPs originating from
   the PCC.  An implementation of this feature needs to make sure to
   check for the LSP control feature (C flag set to 1) before any check
   for PLSP-ID (as prescribed in [RFC8231]).
END

Thanks!
Dhruv