RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 5 records.

Status: Verified (3)

RFC 6006, "Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths", September 2010

Source of RFC: pce (rtg)

Errata ID: 4868

Status: Verified
Type: Technical

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

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

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: Reported (1)

RFC 6006, "Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths", September 2010

Source of RFC: pce (rtg)

Errata ID: 4867

Status: Reported
Type: Technical

Reported By: DHRUV DHODY
Date Reported: 2016-11-16

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

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

Source of RFC: pce (rtg)

Errata ID: 3836

Status: Held for Document Update
Type: Editorial

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

Report New Errata



Search RFCs
Advanced Search
×