errata logo graphic

Found 9 records.

Status: Verified (2)

RFC6016, "Support for the Resource Reservation Protocol (RSVP) in Layer 3 VPNs", October 2010

Source of RFC: tsvwg (tsv)

Errata ID: 2553

Status: Verified
Type: Technical

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

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)

RFC6016, "Support for the Resource Reservation Protocol (RSVP) in Layer 3 VPNs", October 2010

Source of RFC: tsvwg (tsv)

Errata ID: 2557

Status: Held for Document Update
Type: Technical

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

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

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

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

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

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

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)


Report New Errata