Subject: RFC 4448 issues

From: Alfred Hönes <[email-masked]>
Date: Thu, 25 May 2006 16:18:20 +0200 (MESZ)

Hello,
reading the recently published RFC 4448 authored by you,
I found two issues worth being commented.

(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 ---

Perhaps, both issues should be addressed by an RFC Errata Note.
But for item (2), discussion is required before such submission,
so please comment.

Best regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+