Subject: Re: [Pce] [Technical Errata Reported] RFC8231 (6627)

From: Dhruv Dhody <[email-masked]>
Date: Thu, 30 Sep 2021 21:34:04 +0530

Hi John, WG,

Oscar is correct in pointing this issue with RBNF when multiple I-Ds extend
the PCEP message. The erratum could be marked as "Held for Document Update"
so that any future update to RFC8231 could handle it.

Note that the RBNF grammar inconsistency was discussed in the past [1].
Since PCEP messages will keep getting extended it might be worth checking
if a living document (wiki, GitHub) could be used to maintain the full RBNF
of PCEP messages.

Thanks!
Dhruv & Julien

[1] https://www.ietf.org/archive/id/draft-cmfg-pce-pcep-grammar-02.txt

On Thu, Jul 1, 2021 at 3:08 PM RFC Errata System <[email-masked]>
wrote:

> The following errata report has been submitted for RFC8231,
> "Path Computation Element Communication Protocol (PCEP) Extensions for
> Stateful PCE".
>
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid6627
>
> --------------------------------------
> Type: Technical
> Reported by: Oscar Gonzalez de Dios <[email-masked]>
>
> Section: 6.4
>
> Original Text
> -------------
>   <request>::= <RP>
>                       <END-POINTS>
>                       [<LSP>]
>                       [<LSPA>]
>                       [<BANDWIDTH>]
>                       [<metric-list>]
>                       [<RRO>[<BANDWIDTH>]]
>                       [<IRO>]
>                       [<LOAD-BALANCING>]
>
> Corrected Text
> --------------
>   <request>::= <RP>
>                       <END-POINTS>
>                       [<LSP>]
>                       [<CLASSTYPE>]
>                       [<LSPA>]
>                       [<BANDWIDTH>]
>                       [<metric-list>]
>                       [<RRO>[<BANDWIDTH>]]
>                       [<IRO>]
>                       [<LOAD-BALANCING>]
>
> Notes
> -----
> RFC 5455 defines the CLASSTYPE object and specifies that the CLASSTYPE
> object MUST
>    be inserted after the END-POINT objects. RFC 8231 defines the LSP
> object and specifies that  the LSP object MUST be inserted after the
> END-POINTS object. Hence, it is not clear if CLASSTYPE or LSP goes after
> END-POINTS. Hence, to disambiguate and avoid interoperability issues, the
> proposal is to include the CLASSTYPE object in the updated grammar. The
> order would be <END-POINTS>[<LSP>][<CLASSTYPE>]
>
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC8231 (draft-ietf-pce-stateful-pce-21)
> --------------------------------------
> Title               : Path Computation Element Communication Protocol
> (PCEP) Extensions for Stateful PCE
> Publication Date    : September 2017
> Author(s)           : E. Crabbe, I. Minei, J. Medved, R. Varga
> Category            : PROPOSED STANDARD
> Source              : Path Computation Element
> Area                : Routing
> Stream              : IETF
> Verifying Party     : IESG
>

---

From: John Scudder <[email-masked]>
Date: Thu, 30 Sep 2021 18:42:22 +0000

Hi Dhruv,

Regarding whether this is a verifiable erratum or not, the submitter notes, “Hence, it is not clear if CLASSTYPE or LSP goes after END-POINTS. Hence, to disambiguate and avoid interoperability issues, the proposal is to include the CLASSTYPE object in the updated grammar.” The use of the word “proposal” suggests to me that this goes beyond the scope of an erratum, which is limited to correcting errors in a manner consistent with the consensus at time of publication (https://www.ietf.org/about/groups/iesg/statements/processing-errata-ietf-stream/). Unless there was specific consensus for the proposed sorting order, it seems to me the erratum oversteps this boundary.

Thanks for your reference to draft-cmfg-pce-pcep-grammar-02. Looking at the list traffic, it doesn’t appear there was much (any, really) discussion of it, unfortunately. It also led me to find https://mailarchive.ietf.org/arch/msg/pce/VUM5GymISrBiPgoUEVH8IkaM3tU/ , where the AD at the time (Adrian) rejected erratum 3672, which is similar to 6627 in that it complains about ambiguous ordering and asks for a fix. Adrian ends his rejection comment with

“In rejecting this Errata report I note that the reported error is not a typo,
but a deliberate decision of the authors and working group. The fix, therefore,
if it is to be applied needs to be achieved through a consensus document.”

AFAICT this reasoning applies equally in the current case. Actually, it applies even more so, because the WG was offered draft-cmfg-pce-pcep-grammar-02 and didn’t do anything with it, which implies a lack of consensus to go forward with a solution to the identified problem.

I do agree that since this topic won't be going away, it seems worth expending some effort to solve it instead of ignoring it. Unless someone wants to make the argument that the RBNF grammar isn’t subject to IETF consensus, I’m not sure the methods you suggest are suitable, at least not without some additional consideration for how to make sure they reliably reflect consensus.

Finally I note this other paragraph from Adrian’s message:

“Discussion of this point led to a debate about whether the RBNF is normative and
should be "compilable". Some hold the view that being conservative in what you
send and liberal in what you receive could only make this text normative for
building messages not parsing them. Others noted that, as with RSVP, the object
ordering is advisory not mandatory except as where noted explicitly in the text.”

(FYI the discussion he references is here: https://mailarchive.ietf.org/arch/msg/pce/Og5fW8dZU2VgDjQywSIPm9jU87w/)

This implies to me that there’s at least one other possible way forward, which would be to update RFC5440, making object ordering optional. Something like this:

OLD:
An implementation MUST form the PCEP
   messages using the object ordering specified in this document.

NEW:
An implementation SHOULD form the PCEP
   messages using the object ordering specified in this and subsequent
documents when an ordering can be unambiguously determined; an
implementation MUST be prepared to receive a PCEP
message with objects in any order.

In other words, fix the problem by fiat, retroactively declaring it to be a non-problem. Let me be the first to say that this proposal might be technically unsound for some reason, but since it was mentioned in the earlier email and represents a different way forward, I thought I’d include it here.

I’ll wait for further discussion, but for now my plan is to reject the erratum for the same reason 3672 was rejected.

Thanks,

—John

On Sep 30, 2021, at 12:04 PM, Dhruv Dhody <[email-masked]<mailto:[email-masked]>> wrote:

Hi John, WG,

Oscar is correct in pointing this issue with RBNF when multiple I-Ds extend the PCEP message. The erratum could be marked as "Held for Document Update" so that any future update to RFC8231 could handle it.

Note that the RBNF grammar inconsistency was discussed in the past [1]. Since PCEP messages will keep getting extended it might be worth checking if a living document (wiki, GitHub) could be used to maintain the full RBNF of PCEP messages.

Thanks!
Dhruv & Julien

[1] https://www.ietf.org/archive/id/draft-cmfg-pce-pcep-grammar-02.txt<https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-cmfg-pce-pcep-grammar-02.txt__;!!NEt6yMaO-gk!UQN1qCMKzSbkTI8Rrsuon-yIYbBWV3jjfq4aE_B-dY1CpwZH8u0oWlaZrF1eYg$>

On Thu, Jul 1, 2021 at 3:08 PM RFC Errata System <[email-masked]<mailto:[email-masked]>> wrote:
The following errata report has been submitted for RFC8231,
"Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6627<https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid6627__;!!NEt6yMaO-gk!UQN1qCMKzSbkTI8Rrsuon-yIYbBWV3jjfq4aE_B-dY1CpwZH8u0oWlYLm_GsQA$>

--------------------------------------
Type: Technical
Reported by: Oscar Gonzalez de Dios <[email-masked]<mailto:[email-masked]>>

Section: 6.4

Original Text
-------------
  <request>::= <RP>
                      <END-POINTS>
                      [<LSP>]
                      [<LSPA>]
                      [<BANDWIDTH>]
                      [<metric-list>]
                      [<RRO>[<BANDWIDTH>]]
                      [<IRO>]
                      [<LOAD-BALANCING>]

Corrected Text
--------------
  <request>::= <RP>
                      <END-POINTS>
                      [<LSP>]
                      [<CLASSTYPE>]
                      [<LSPA>]
                      [<BANDWIDTH>]
                      [<metric-list>]
                      [<RRO>[<BANDWIDTH>]]
                      [<IRO>]
                      [<LOAD-BALANCING>]

Notes
-----
RFC 5455 defines the CLASSTYPE object and specifies that the CLASSTYPE object MUST
   be inserted after the END-POINT objects. RFC 8231 defines the LSP object and specifies that  the LSP object MUST be inserted after the END-POINTS object. Hence, it is not clear if CLASSTYPE or LSP goes after END-POINTS. Hence, to disambiguate and avoid interoperability issues, the proposal is to include the CLASSTYPE object in the updated grammar. The order would be <END-POINTS>[<LSP>][<CLASSTYPE>]

Instructions:
-------------

Title               : Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE

---

From: Robert Varga <[email-masked]>
Date: Fri, 1 Oct 2021 00:35:33 +0200

> Hi Dhruv,

Hello John, Dhruv, everyone,

(goes off to find and dust off the co-author hat)

> Regarding whether this is a verifiable erratum or not, the submitter 
> notes, “Hence, it is not clear if CLASSTYPE or LSP goes after 
> END-POINTS. Hence, to disambiguate and avoid interoperability issues, 
> the proposal is to include the CLASSTYPE object in the updated grammar.” 
> The use of the word “proposal” suggests to me that this goes beyond the 
> scope of an erratum, which is limited to correcting errors in a manner 
> consistent with the consensus at time of publication 
> (https://www.ietf.org/about/groups/iesg/statements/processing-errata-ietf-stream/ 
> <https://www.ietf.org/about/groups/iesg/statements/processing-errata-ietf-stream/>). 
> Unless there was specific consensus for the proposed sorting order, it 
> seems to me the erratum oversteps this boundary.

(now with the co-author hat on, still fits after all these years!)

This one specifically is tricky.

When we introduced draft-crabbe-pce-stateful-pce-00, while it was doing 
the bare minimum required, the WG felt it already had too big a scope -- 
it ended up being split into two (or three?) documents in the end.

The fact that RFC5440's insistence on object ordering is resulting in 
exponential complexity in terms of what each new document needs to cope 
with in terms of reconciling all previously-published document, and 
worse, all concurrently-existing drafts.

If memory serves right, we discussed this with Adrian (and JP?), and the 
agreement was to specifically limit RFC8231-to-be to extend (and 
therefore consider) ONLY RFC5440, i.e. specifically place integration 
with other extensions out of scope.

So the document reflects WG consensus accurately, and I do not believe 
the errata at hand should be accepted.

> Thanks for your reference to draft-cmfg-pce-pcep-grammar-02. Looking at 
> the list traffic, it doesn’t appear there was much (any, really) 
> discussion of it, unfortunately.

Yes, this is exactly the kind of follow up we envisioned to happen 
separately.

  It also led me to find
> https://mailarchive.ietf.org/arch/msg/pce/VUM5GymISrBiPgoUEVH8IkaM3tU/ 
> <https://mailarchive.ietf.org/arch/msg/pce/VUM5GymISrBiPgoUEVH8IkaM3tU/> 
> , where the AD at the time (Adrian) rejected erratum 3672, which is 
> similar to 6627 in that it complains about ambiguous ordering and asks 
> for a fix. Adrian ends his rejection comment with
> 
> AFAICT this reasoning applies equally in the current case. Actually, it 
> applies even more so, because the WG was offered 
> draft-cmfg-pce-pcep-grammar-02 and didn’t do anything with it, which 
> implies a lack of consensus to go forward with a solution to the 
> identified problem.

So I watched this from the sidelines already, but I believe it was more 
of a lack of determination to iron out all the issues and drive the 
consensus.

> I do agree that since this topic won't be going away, it seems worth 
> expending some effort to solve it instead of ignoring it. Unless someone 
> wants to make the argument that the RBNF grammar isn’t subject to IETF 
> consensus, I’m not sure the methods you suggest are suitable, at least 
> not without some additional consideration for how to make sure they 
> reliably reflect consensus.
> 
> (FYI the discussion he references is here: 
> https://mailarchive.ietf.org/arch/msg/pce/Og5fW8dZU2VgDjQywSIPm9jU87w/ 
> <https://mailarchive.ietf.org/arch/msg/pce/Og5fW8dZU2VgDjQywSIPm9jU87w/>)

Exactly. The crux of the issue is that RFC5440 prescribes a rigid 
protocol structure, which does not lend itself to extensible data modeling.

> This implies to me that there’s at least one other possible way forward, 
> which would be to update RFC5440, making object ordering optional. 
> Something like this:
> 
> OLD:
> In other words, fix the problem by fiat, retroactively declaring it to 
> be a non-problem. Let me be the first to say that this proposal might be 
> technically unsound for some reason, but since it was mentioned in the 
> earlier email and represents a different way forward, I thought I’d 
> include it here.

Exactly. The WG needs to make decision as to how to clean the house. 
There are two options, both of which you have referenced:

- publish a standards track document which will tie together all current 
documents, updating them as needed to resolve conflicts like the one in 
this erratum

- publish a 5440bis with saner object ordering, a compatibility section 
and all that jazz

Unless one of these is implemented, this problem will keep coming back 
and it will get worse with each new published document.

> I’ll wait for further discussion, but for now my plan is to reject the 
> erratum for the same reason 3672 was rejected.

I am okay with either holding it or rejecting it -- whichever makes more 
sense with respect to the WG's plan of solving the underlying problem.

Regards,
Robert

---

From: Dhruv Dhody <[email-masked]>
Date: Fri, 1 Oct 2021 12:18:46 +0530

Hi,

Just to clarify the suggestion to have complete RBNF grammar at a living
document was just for informational purposes (and not to bypass the IETF
process). It stemmed from trying a different approach than the one already
attempted in the past.

I am all for trying the approach suggested by John and Robert.

<snip>
> - publish a 5440bis with saner object ordering, a compatibility section
[Dhruv]: Or an independent document that only focuses on PCEP object
ordering and updates RFC 5440 (and any other document that uses "MUST" for
object ordering).

Thanks!
Dhruv