RFC Errata
Found 9 records.
Status: Verified (2)
RFC 6016, "Support for the Resource Reservation Protocol (RSVP) in Layer 3 VPNs", October 2010
Source of RFC: tsvwg (wit)
Errata ID: 2553
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-10-12
Verifier Name: Lars Eggert
Date Verified: 2011-01-28
Section 8.6, pg.27 says:
[[ last paragraph of section 8.6 ]] | | The flags and DSCP are identical to the same fields of the AGGREGATE- | IPv4 and AGGREGATE-IPv6 SESSION objects.
It should say:
[[ nothing ]]
Notes:
Rationale: The text in this paragraph does not match the preceding
artwork for Class = 11, C-Type = 16 and 17; it is spurious and
needs to be deleted.
Errata ID: 2558
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-10-12
Verifier Name: Lars Eggert
Date Verified: 2011-01-28
Section 8.5, pg.24 says:
| The usage of Aggregated VPN-IPv4 (or VPN-IPv6) SESSION object is described in Section 7.3. The AGGREGATE-VPN-IPv4 (respectively, AGGREGATE-IPv6-VPN) SESSION object appears in RSVP messages that ordinarily contain a AGGREGATE-IPv4 (respectively, AGGREGATE-IPv6) SESSION object as defined in [RFC3175] and are sent between ingress PE and egress PE in either direction. The GENERIC-AGGREGATE-VPN-IPv4 | (respectively, AGGREGATE-VPN-IPv6) SESSION object should appear in all RSVP messages that ordinarily contain a GENERIC-AGGREGATE-IPv4 (respectively, GENERIC-AGGREGATE-IPv6) SESSION object as defined in [RFC4860] and are sent between ingress PE and egress PE in either direction. [...]
It should say:
| The usage of the Aggregated VPN-IPv4 (or VPN-IPv6) SESSION object is described in Section 7.3. The AGGREGATE-VPN-IPv4 (respectively, AGGREGATE-IPv6-VPN) SESSION object appears in RSVP messages that ordinarily contain a AGGREGATE-IPv4 (respectively, AGGREGATE-IPv6) SESSION object as defined in [RFC3175] and are sent between ingress PE and egress PE in either direction. The GENERIC-AGGREGATE-VPN-IPv4 | (respectively, GENERIC-AGGREGATE-VPN-IPv6) SESSION object should appear in all RSVP messages that ordinarily contain a GENERIC-AGGREGATE-IPv4 (respectively, GENERIC-AGGREGATE-IPv6) SESSION object as defined in [RFC4860] and are sent between ingress PE and egress PE in either direction. [...]
Notes:
Rationale:
a) missing articles [editorial]
b) reference to wrong object
Status: Held for Document Update (7)
RFC 6016, "Support for the Resource Reservation Protocol (RSVP) in Layer 3 VPNs", October 2010
Source of RFC: tsvwg (wit)
Errata ID: 2557
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-10-12
Held for Document Update by: Lars Eggert
Section 4, pg. 15 says:
[[ last paragraph of Section 4 ]] To achieve effective admission control in the backbone, there needs to be some way to separate the data-plane traffic that has a reservation from that which does not. We assume that packets that are subject to admission control on the core will be given a | particular MPLS EXP value, and that no other packets will be allowed to enter the core with this value unless they have passed admission control. Some fraction of link resources will be allocated to queues | on core links for packets bearing that EXP value, and the MPLS-TE tunnels will use that resource pool to make their constraint-based routing and admission control decisions. This is all consistent with the principles of aggregate RSVP reservations described in [RFC3175].
It should say:
To achieve effective admission control in the backbone, there needs to be some way to separate the data-plane traffic that has a reservation from that which does not. We assume that packets that are subject to admission control on the core will be given a | particular MPLS Traffic Class value, and that no other packets will be allowed to enter the core with this value unless they have passed admission control. Some fraction of link resources will be allocated | to queues on core links for packets bearing that Traffic Class value, and the MPLS-TE tunnels will use that resource pool to make their constraint-based routing and admission control decisions. This is all consistent with the principles of aggregate RSVP reservations described in [RFC3175]. 5
Notes:
Rationale: s/EXP/Traffic Class/ !
RFC 5462 has carefully changed the terminology and updated numerous
RFCs; it has given a detailed explantion why this needs to be done
consistently and confirmed that all future RFCs should unconditionally
use the updated terms.
(See also EID 2547 for RFC 5994.)
Errata ID: 2559
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-10-12
Held for Document Update by: Lars Eggert
Section 8.5, pg.25/2 says:
a) [[ on mid-page 25: ]] | The Reserved field MUST be set to zero on transmit and ignored on receipt. b) [[ last paragraph of the section, on page 26: ]] | The Reserved field MUST be set to zero on transmit and ignored on receipt.
It should say:
a) and b) | The Reserved fields MUST be set to zero on transmit and ignored on receipt.
Notes:
Rationale:
a) There are _two_ Reserved fields in the AGGREGATE-VPN-IPv{4|6}
SESSION objects, as shown in the preceding artwork in the RFC;
the said treatment applies to both.
b) dto. for the GENERIC-AGGREGATE-VPN-IPv{4|6} SESSION objects.
Errata ID: 2561
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-10-12
Held for Document Update by: Lars Eggert
Section 8.7,pg.27/28 says:
| The usage of Aggregated VPN-IPv4 FILTER_SPEC object is described in | Section 7.3. The AGGREGATE-VPN-IPv4 FILTER_SPEC object appears in | RSVP messages that ordinarily contain a AGGREGATE-IPv4 FILTER_SPEC object as defined in [RFC3175] and [RFC4860], and are sent between ingress PE and egress PE in either direction. These objects MUST NOT be included in any RSVP messages that are sent outside of the provider's backbone (except in the inter-AS Option-B and Option-C | cases, as described above, when it may appear on inter-AS links). The processing rules for these objects are otherwise identical to | those of the VPN-IPv4 FILTER_SPEC object defined in Section 8.3. The format of the object is as follows:
It should say:
| The usage of the Aggregated VPN-IPv4 FILTER_SPEC object is described | in Section 7.3. The AGGREGATE-VPN-IPv4 (or AGGREGATE-VPN-IPv6) FILTER_SPEC object appears in RSVP messages that ordinarily contain | an AGGREGATE-IPv4 (respectively, AGGREGATE-IPv6) FILTER_SPEC object as defined in [RFC3175] and [RFC4860], and are sent between ingress PE and egress PE in either direction. These objects MUST NOT be included in any RSVP messages that are sent outside of the provider's backbone (except in the inter-AS Option-B and Option-C cases, as | described above, when they may appear on inter-AS links). The processing rules for these objects are otherwise identical to | those of the VPN-IPv4 and VPN-IPv6 FILTER_SPEC objects defined in Section 8.3. The format of the object is as follows:
Notes:
Rationale:
a) missing article
b) incomplete specification; the use of "These objects" as well as the
references to two different RFCs (one for the IPv4 case, one for the
IPv6 case) are strong indications that this text should be phrased
in a similar manner as in preceding subsections of Section 8, i.e.
it should include mention of the equivalent object for the IPv6 case
as well (this qualifies the Errata Note as Technical);
c) s/a AGGREGATE/an AGGREGATE/
d) singular/plural mismatch: s/it/they/ .
Errata ID: 2554
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-10-12
Held for Document Update by: Lars Eggert
Section Abstract says:
RFC 4364 and RFC 4659 define an approach to building provider- provisioned Layer 3 VPNs (L3VPNs) for IPv4 and IPv6. It may be | desirable to use Resource Reservation Protocol (RSVP) to perform admission control on the links between Customer Edge (CE) routers and Provider Edge (PE) routers. [...]
It should say:
RFC 4364 and RFC 4659 define an approach to building provider- provisioned Layer 3 VPNs (L3VPNs) for IPv4 and IPv6. It may be | desirable to use the Resource Reservation Protocol (RSVP) to perform admission control on the links between Customer Edge (CE) routers and Provider Edge (PE) routers. [...]
Notes:
Rationale: Missing article
Errata ID: 2555
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-10-12
Held for Document Update by: Lars Eggert
Section 3.2,1st para says:
When a Path message arrives at the ingress PE (step 3 of Section 2.1) the PE needs to establish suitable Path state and forward the Path message on to the egress PE. In the following paragraphs, we | described the steps taken by the ingress PE.
It should say:
When a Path message arrives at the ingress PE (step 3 of Section 2.1) the PE needs to establish suitable Path state and forward the Path message on to the egress PE. In the following paragraphs, we | describe the steps taken by the ingress PE.
Notes:
Rationale: inappropriate past tense; should be present tense.
Errata ID: 2556
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-10-12
Held for Document Update by: Lars Eggert
Section 3.5, pg.13 says:
Upon receiving a Resv message at the ingress PE (step 8 of | Section 2.1) with respect to data flow (i.e., PE1 in Figure 1), the PE determines the local VRF context and associated Path state for this Resv by decoding the received SESSION and FILTER_SPEC objects. [...]
It should say:
Upon receiving a Resv message at the ingress PE (step 8 of | Section 2.1) with respect to the data flow (i.e., PE1 in Figure 1), the PE determines the local VRF context and associated Path state for this Resv by decoding the received SESSION and FILTER_SPEC objects. [...]
Notes:
Rationale: missing article; cf. other parts of the document.
Errata ID: 2560
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-10-12
Held for Document Update by: Lars Eggert
Section 8.6, pg.26 says:
| The usage of Aggregated VPN-IPv4 (or VPN-IPv6) SENDER_TEMPLATE object is described in Section 7.3. [...]
It should say:
| The usage of the Aggregated VPN-IPv4 (or VPN-IPv6) SENDER_TEMPLATE object is described in Section 7.3. [...]
Notes:
Rationale: missing article (as in EID=2558)