RFC Errata
Found 1 record.
Status: Held for Document Update (1)
RFC 4448, "Encapsulation Methods for Transport of Ethernet over MPLS Networks", April 2006
Note: This RFC has been updated by RFC 5462, RFC 8469
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