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

[John Scudder <[e-mail]>]

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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>>

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