RFC Errata
Found 1 record.
Status: Held for Document Update (1)
RFC 4448, "Encapsulation Methods for Transport of Ethernet over MPLS Networks", April 2006
Source of RFC: pwe3 (int)
Errata ID: 85
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-05-25
Held for Document Update by: Stewart Bryant
1) a subtle typo
Section 4.5 of RFC 4448, on top of page 12, says:
The Ethernet PW management model follows the general PW management
model defined in [RFC3985] and [PWE3-MIB]. Many common PW management
facilities are provided here, with no additional Ethernet specifics
necessary. Ethernet-specific parameters are defined in an additional
MIB module, [PW-MIB].
It should say, replacing "here" by "there":
The Ethernet PW management model follows the general PW management
model defined in [RFC3985] and [PWE3-MIB]. Many common PW management
| facilities are provided there, with no additional Ethernet specifics
necessary. Ethernet-specific parameters are defined in an additional
MIB module, [PW-MIB].
(2) terminological issue / violation of reference model
Section 4.4.1 of RFC 4448, on pp. 9/10, says:
--- snip ---
When the PE receives an Ethernet frame, and the frame has a VLAN tag,
we can distinguish two cases:
1. The tag is service-delimiting. This means that the tag was
placed on the frame by some piece of service provider-operated
equipment, and the tag is used by the service provider to
distinguish the traffic. For example, LANs from different
customers might be attached to the same service provider
switch, which applies VLAN tags to distinguish one customer's
traffic from another's, and then forwards the frames to the PE.
2. The tag is not service-delimiting. This means that the tag was
placed in the frame by a piece of customer equipment, and is
not meaningful to the PE.
Whether or not the tag is service-delimiting is determined by local
configuration on the PE.
--- snip ---
IMHO, this is a very unfortunate explanation.
a) The term, "service delimiting", apparently here is defined
by the origin of the tag, not by its function.
I do not believe that this is the appropriate way to deal with;
later on in RFC 4448, it (reasonably) seems to be permitted
that a service-delimiting tag has been provided by a CE device!
b) The situation described in bullet 1), with a provider owned
switch, removes the PW terminating entity from the provider
*edge*, turning it from a "PE" device into a "P" device,
which is highly inconsistent with the service model developed
in Section 1 of RFC 4448, and leads to a clash in terminology.
To stay within that model, the "coloring" function described
in bullet 1) must conceptionally be performed by the NSP
function *within* the (PW terminating) PE device. (And it might
as well be performed in customer equipment, i.e. at the CE.)
Perhaps, the above text should be improved.
I'll try at a first proposal:
--- snip ---
When the PE receives an Ethernet frame, and the frame has a VLAN tag,
we can distinguish two cases:
1. The tag is service-delimiting.
This means that the tag was introduced for the single purpose
of identifying the frame for the PW service, e.g., to select a
specific PW for transmission of the frame. A service-
delimiting tag may have been added on the CE side or in the
(conceptual) NSP function of the PE edge.
Ordinarily, any service-delimiting tag will not be transmitted
over the PW, i.e., it will be removed before PW encapsulation.
2. The tag is not service-delimiting. This means that the tag is
not meaningful to the PW endpoints and must be transmitted over
the PW.
Such tag usually was placed in the frame by a piece of customer
equipment, but it might as well be added or modified by the NSP
function of the PW terminating PE device.
Whether or not the tag is service-delimiting is determined by local
configuration on the PE.
--- snip ---
Notes:
from pending
