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

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.)

Report New Errata