Search RFCs
The Series
For Authors
Sponsor
RFC Errata
Found 3 records.
Status:Verified (3)
RFC 5521, "Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions", April 2009
Source of RFC: pce (rtg)Errata ID:1775
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-05-05
Verifier Name: Adrian Farrel
Date Verified: 2010-01-02
Section 2.1.1, pg. 6 says:
Type The type of the subobject. The following subobject types are defined. Type Subobject -------------+------------------------------- 1 IPv4 prefix 2 IPv6 prefix 4 Unnumbered Interface ID 32 Autonomous system number 34 SRLG Length [...] Prefix Length [...] Attribute The Attribute field indicates how the exclusion subobject is to be interpreted. 0 Interface The subobject is to be interpreted as an interface or set of interfaces. All interfaces identified by the subobject are to be excluded from the computed path according to the setting of the| X-bit. This value is valid only for subobject types 1, 2, and 3. 1 Node The subobject is to be interpreted as a node or set of nodes. All nodes identified by the subobject are to be excluded from the computed path according to the setting of the X-bit. This value| is valid only for subobject types 1, 2, 3, and 4. 2 SRLG The subobject identifies an SRLG explicitly or indicates all of the SRLGs associated with the resource or resources identified by the subobject. Resources that share any SRLG with those identified are to be excluded from the computed path according to the setting of the X-bit. This value is valid for all subobjects.
It should say:
Attribute The Attribute field indicates how the exclusion subobject is to be interpreted. Type [...] Length [...] Prefix Length [...] Attribute The Attribute field indicates how the exclusion subobject is to be interpreted. 0 Interface The subobject is to be interpreted as an interface or set of interfaces. All interfaces identified by the subobject are to be excluded from the computed path according to the setting of the X-bit. This value is valid only for subobject types 1, 2,| and 4. ^ 1 Node The subobject is to be interpreted as a node or set of nodes. All nodes identified by the subobject are to be excluded from the computed path according to the setting of the X-bit. This| value is valid only for subobject types 1, 2, 4, and 32. ^ ^^ 2 SRLG The subobject identifies an SRLG explicitly or indicates all of the SRLGs associated with the resource or resources identified by the subobject. Resources that share any SRLG with those identified are to be excluded from the computed path according to the setting of the X-bit. This value is valid for all subobjects.
Notes:
Rationale:
a) Technical:
The enumeration of subobject types for Attribute '0 Interface'
and '1 Node' is out of sync with the table at the top of the page
and the IANA registry (cf. Section 4.1 of this RFC, on page 13).
The Corrected Text proposed above is based on the assumption that
the figures given originally refer to the position of the
subobjects in the table, i.e. that the subobjects in the table
once had been assigned sequential type numbers, 1 through 5;
this change seems to be technically reasonable.
>>> Technical change verified by original document author and cross-checked
>>> to early versions of the document.
b) Editorial: For clarity, the details for the Attribute field
values should have been indented one more step, making them
visually subordinate to 'Attribute' and not appearing like
additional common fields.
Errata ID:3750
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Dana Kutenicsova
Date Reported: 2013-10-15
Verifier Name: Stewart Bryant
Date Verified: 2013-10-23
Section 3.1.1 says:
The format and definition of PKS when it appears as an XRO subobjectare as defined in [RFC5520], except for the definition of the L bit.The L bit of the PKS subobject in the XRO MUST be ignored.
It should say:
The format and definition of PKS when it appears as an XRO subobjectare as defined in [RFC5520], except that the L bit described in [RFC5220] is replaced with the X bit as discussed in Section 2.1.1 of this document.
Notes:
The original text did not describe the value of the X bit in
PKS subobjects.
Errata ID:2705
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ramon Casellas
Date Reported: 2011-02-05
Verifier Name: Adrian Farrel
Date Verified: 2011-05-08
Section 2.1.1 says:
Unnumbered Interface ID Subobject 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |X| Type = 3 | Length | Reserved | Attribute | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TE Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The TE Router ID and Interface ID fields are as defined in [RFC3477].Oki, et al. Standards Track [Page 7] RFC 5521 Extensions to PCEP for Route Exclusions April 2009 Autonomous System Number Subobject 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |X| Type = 4 | Length | 2-Octet AS Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note that as in other PCEP objects [RFC5440] and RSVP-TE objects [RFC3209], no support for 4-octet Autonomous System (AS) Numbers is provided. It is anticipated that, as 4-octet AS Numbers become more common, both PCEP and RSVP-TE will be updated in a consistent way to add this support. SRLG Subobject 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |X| Type = 5 | Length | SRLG Id (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SRLG Id (continued) | Reserved | Attribute | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Attribute SHOULD be set to two (2) and SHOULD be ignored on receipt.
It should say:
Unnumbered Interface ID Subobject 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |X| Type = 4 | Length | Reserved | Attribute | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TE Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The TE Router ID and Interface ID fields are as defined in [RFC3477].Oki, et al. Standards Track [Page 7] RFC 5521 Extensions to PCEP for Route Exclusions April 2009 Autonomous System Number Subobject 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |X| Type = 32 | Length | 2-Octet AS Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note that as in other PCEP objects [RFC5440] and RSVP-TE objects [RFC3209], no support for 4-octet Autonomous System (AS) Numbers is provided. It is anticipated that, as 4-octet AS Numbers become more common, both PCEP and RSVP-TE will be updated in a consistent way to add this support. SRLG Subobject 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |X| Type = 34 | Length | SRLG Id (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SRLG Id (continued) | Reserved | Attribute | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Attribute SHOULD be set to two (2) and SHOULD be ignored on receipt.
Notes:
This is the correct resolution consistent with the table further up the document, and with the IANA registry