Subject: [Technical Errata Reported] RFC6016 (2557)

From: RFC Errata System <[email-masked]>
Date: Tue, 12 Oct 2010 11:01:48 -0700 (PDT)

The following errata report has been submitted for RFC6016,
"Support for the Resource Reservation Protocol (RSVP) in Layer 3 VPNs".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6016&eid=2557

--------------------------------------
Type: Technical
Reported by: Alfred Hoenes <[email-masked]>

Section: 4, pg. 15

Original Text
-------------
[[ 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].

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

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6016 (draft-ietf-tsvwg-rsvp-l3vpn-07)
--------------------------------------
Title               : Support for the Resource Reservation Protocol (RSVP) in Layer 3 VPNs
Publication Date    : October 2010
Author(s)           : B. Davie, F. Le Faucheur, A. Narayanan
Category            : PROPOSED STANDARD
Source              : Transport Area Working Group
Area                : Transport
Stream              : IETF
Verifying Party     : IESG