RFC Errata
Found 5 records.
Status: Verified (4)
RFC 6006, "Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths", September 2010
Note: This RFC has been obsoleted by RFC 8306
Source of RFC: pce (rtg)
Errata ID: 4867
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: DHRUV DHODY
Date Reported: 2016-11-16
Verifier Name: Deborah Brungard
Date Verified: 2017-03-13
Section 3.4 says:
<PCReq Message>::= <Common Header>
<request>
where:
<request>::= <RP>
<end-point-rro-pair-list>
[<OF>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>]
[<LOAD-BALANCING>]
where:
<end-point-rro-pair-list>::=
<END-POINTS>[<RRO-List>][<BANDWIDTH>]
[<end-point-rro-pair-list>]
<RRO-List>::=<RRO>[<BANDWIDTH>][<RRO-List>]
<metric-list>::=<METRIC>[<metric-list>]
It should say:
<PCReq Message>::= <Common Header>
[<svec-list>]
<request-list>
where:
<svec-list>::=<SVEC>
[<OF>]
[<metric-list>]
[<svec-list>]
<request-list>::=<request>[<request-list>]
<request>::= <RP>
<end-point-rro-pair-list>
[<OF>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>|<BNC>]
[<LOAD-BALANCING>]
where:
<end-point-rro-pair-list>::=
<END-POINTS>[<RRO-List>[<BANDWIDTH>]]
[<end-point-rro-pair-list>]
<RRO-List>::=(<RRO>|<SRRO>)[<RRO-List>]
<metric-list>::=<METRIC>[<metric-list>]
Notes:
o Update the Routing Backus-Naur Form (RBNF) [RFC5511] for Request
message format:
* Update the request message to allows for the bundling of
multiple path computation requests within a single Path
Computation Request (PCReq) message.
* Add <svec-list> in PCReq message. This object was missed in
[RFC6006].
* Add BNC object in PCReq message. This object is required to
support P2MP. It shares the same format as Include Route Object
(IRO) but it is a different object.
* Update the <RRO-List> format to also allow Secondary Record
Route object (SRRO). This object was missed in [RFC6006].
* Removed the BANDWIDTH Object followed by Record Route Object
(RRO) from <RRO-List>. As BANDWIDTH object doesn't need to follow
for each RRO in the <RRO-List>, there already exist BANDWIDTH
object follow <RRO-List> and is backward compatible with
[RFC5440].
* Update the <end-point-rro-pair-list> to allow optional BANDWIDTH
object only if <RRO-List> is included.
Refer https://datatracker.ietf.org/doc/draft-palleti-pce-rfc6006bis/?include_text=1
Errata ID: 4868
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: DHRUV DHODY
Date Reported: 2016-11-16
Verifier Name: Deborah Brungard
Date Verified: 2016-11-16
Section 3.5 says:
<PCRep Message>::= <Common Header>
<response>
<response>::=<RP>
[<end-point-path-pair-list>]
[<NO-PATH>]
[<attribute-list>]
where:
<end-point-path-pair-list>::=
[<END-POINTS>]<path>[<end-point-path-pair-list>]
<path> ::= (<ERO>|<SERO>) [<path>]
<attribute-list>::=[<OF>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>]
It should say:
<PCRep Message>::= <Common Header>
<response-list>
where:
<response-list>::=<response>[<response-list>]
<response>::=<RP>
[<end-point-path-pair-list>]
[<NO-PATH>]
[<UNREACH-DESTINATION>]
[<attribute-list>]
<end-point-path-pair-list>::=
[<END-POINTS>]<path>[<end-point-path-pair-list>]
<path> ::= (<ERO>|<SERO>) [<path>]
where:
<attribute-list>::=[<OF>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>]
Notes:
o Update the RBNF for Reply message format:
* Update PCEP allows for the bundling of multiple path computation
responses within a single Path Computation Reply (PCRep) message.
* Update UNREACH-DESTINATION in PCRep message. This object was
missed in [RFC6006].
Refer: https://datatracker.ietf.org/doc/draft-palleti-pce-rfc6006bis/?include_text=1
Errata ID: 3819
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Udayasree
Date Reported: 2013-12-04
Verifier Name: Adrian Farrel
Date Verified: 2013-12-05
Section 3.13.2 says:
Each message sent to the PCE, except the last one, will have the F-bit set in the RP object to signify that the response has been fragmented into multiple messages.
It should say:
Each message sent by the PCE, except the last one, will have the F-bit set in the RP object to signify that the response has been fragmented into multiple messages.
Notes:
This section is about response, and response messages are sent *by* the PCE.
Errata ID: 3830
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Udayasree
Date Reported: 2013-12-10
Verifier Name: Adrian Farrel
Date Verified: 2013-12-13
Section 3.15 says:
To indicate P2MP message fragmentation errors associated with a P2MP path request, a new Error-Type (17) and subsequent error-values are defined as follows for inclusion in the PCEP-ERROR object:
It should say:
To indicate P2MP message fragmentation errors associated with a P2MP path request, a new Error-Type (18) and subsequent error-values are defined as follows for inclusion in the PCEP-ERROR object:
Notes:
17 P2MP END-POINTS Error
18 P2MP Fragmentation Error
It should be 18 in this statement
Status: Held for Document Update (1)
RFC 6006, "Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths", September 2010
Note: This RFC has been obsoleted by RFC 8306
Source of RFC: pce (rtg)
Errata ID: 3836
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Udayasree
Date Reported: 2013-12-13
Held for Document Update by: Adrian Farrel
Date Held: 2013-12-13
Section 3.13 says:
The F-bit is used in the RP object header to signal that the initial request or response was too large to fit into a single message and will be fragmented into multiple messages.
It should say:
The F-bit is used in the RP object to signal that the initial request or response was too large to fit into a single message and will be fragmented into multiple messages.
Notes:
F-bit is used in the RP object body but not the object header