[Technical Errata Reported] RFC6016 (2557)

RFC Errata System <rfc-editor@rfc-editor.org> Tue, 12 October 2010 18:00 UTC

To: bsd@cisco.com, flefauch@cisco.com, ashokn@cisco.com, ietfdbh@comcast.net, lars.eggert@nokia.com, jmpolk@cisco.com, gorry@erg.abdn.ac.uk
Subject: [Technical Errata Reported] RFC6016 (2557)
From: RFC Errata System <rfc-editor@rfc-editor.org>
Message-Id: <20101012180148.858A8E06F2@rfc-editor.org>
Date: Tue, 12 Oct 2010 11:01:48 -0700
Cc: ah@TR-Sys.de, tsvwg@ietf.org, rfc-editor@rfc-editor.org
Precedence: list

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 <ah@TR-Sys.de>

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

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

[Technical Errata Reported] RFC6016 (2557) RFC Errata System