Protocol Action: 'Encapsulation Methods for Transport of Ethernet Over MPLS Networks' to Proposed Standard

The IESG <iesg-secretary@ietf.org> Mon, 19 December 2005 22:17 UTC

Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoTJo-0004ZA-FY; Mon, 19 Dec 2005 17:17:20 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoTJm-0004Yo-9T; Mon, 19 Dec 2005 17:17:18 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22772; Mon, 19 Dec 2005 17:16:15 -0500 (EST)
Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EoTM4-00081r-H2; Mon, 19 Dec 2005 17:19:40 -0500
Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1EoTJl-00074q-3u; Mon, 19 Dec 2005 17:17:17 -0500
X-test-idtracker: no
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Message-Id: <E1EoTJl-00074q-3u@newodin.ietf.org>
Date: Mon, 19 Dec 2005 17:17:17 -0500
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8
Cc: pwe3 chair <stbryant@cisco.com>, pwe3 chair <danny@arbor.net>, Internet Architecture Board <iab@iab.org>, pwe3 mailing list <pwe3@ietf.org>, RFC Editor <rfc-editor@rfc-editor.org>
Subject: Protocol Action: 'Encapsulation Methods for Transport of Ethernet Over MPLS Networks' to Proposed Standard
X-BeenThere: ietf-announce@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ietf-announce.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf-announce@ietf.org>
List-Help: <mailto:ietf-announce-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=subscribe>
Sender: ietf-announce-bounces@ietf.org
Errors-To: ietf-announce-bounces@ietf.org

The IESG has approved the following document:

- 'Encapsulation Methods for Transport of Ethernet Over MPLS Networks '
   <draft-ietf-pwe3-ethernet-encap-11.txt> as a Proposed Standard

This document is the product of the Pseudo Wire Emulation Edge to Edge Working 
Group. 

The IESG contact persons are Mark Townsley and Margaret Wasserman.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pwe3-ethernet-encap-11.txt

- Technical Summary

   This draft describes how an Ethernet Pseudowire (PW) is used to
   carry Ethernet/802.3 Protocol Data Units over an MPLS network.
   This enables service providers to offer "emulated" ethernet
   services over existing MPLS networks. This document specifies
   the encapsulation of Ethernet/802.3 PDUs within a pseudo wire.
   It also specifies the procedures for using a PW to provide
   a "point-to-point ethernet" service.

- Working Group Summary

   This work has been thoroughly analysed by the working group
   and there is consensus for the design. A complementatry
   specification exists in L2TPext WG which describes how to
   carry an Ethernet PW over L2TPv3 over IP.

- Protocol Quality

   This specification is well known in the industry and
   implementations exist.

Note to RFC Editor

At the end of Section 2, please add the following sentence:

"Additional terminology relevant to pseudowires and Layer 2 Virtual Private
Networking (L2VPN) in general may be found in [RFC4026]."

Please replace the first three paragraphs of Section 4.6 with the following
text:
 
   The Control Word defined in this section is based on the 
   Generic PW MPLS Control Word as defined in [PWE3-CW]. It
   provides the ability to sequence individual frames on the 
   PW, avoidance of equal-cost multiple-path load-balancing 
   (ECMP) [RFC2992], and OAM mechanisms including VCCV [VCCV]. 

   [PWE3-CW] states, "If a PW is sensitive to packet misordering 
   and is being carried over an MPLS PSN that uses the contents of the 
   MPLS payload to select the ECMP path, it MUST employ a mechanism which 
   prevents packet misordering." This is necessary due to the fact that 
   ECMP implementations may examine the first nibble after the MPLS label 
   stack to determine whether the labelled packet is IP or not. Thus, 
   if the source MAC address of an ethernet frame carried over 
   the PW without a control word present begins with 0x4 or 0x6, it 
   could be mistaken for an IPv4 or IPv6 packet. This could, depending
   on the configuration and topology of the MPLS network, lead to a 
   situation where all packets for a given PW do not follow the 
   same path. This may increase out-of-order frames on a given 
   PW, or cause OAM packets to follow a different path than actual 
   traffic (see section 4.4.3 on Frame Ordering).    

   The features that the control word provides may not be
   needed for a given ethernet PW. For example, ECMP may not
   be present or active on a given MPLS network, strict 
   frame sequencing may not be required, etc. If this is the 
   case, the control word provides little value and is therefore 
   optional. Early ethernet PW implementations have been deployed 
   that do not include a control word or the ability to process one if 
   present. To aid in backwards compatibility, future 
   implementations MUST be able to send and receive frames without 
   the control word present.

   In all cases the ingress PE MUST be aware of whether the egress 
   PE will send a control word over a specific PW. This may be 
   achieved by configuration of the PEs, or by signaling, as 
   defined in [PWE3-CTRL]. 

  
Additional Informational References:

   [VCCV] T. D. Nadeau, R. Aggarwal, "Pseudo Wire Virtual Circuit
          Connectivity Verification (VCCV)", draft-ietf-pwe3-vccv-07.txt,
          August 2005. (work in progress)

   [RFC2992] RFC-2992:  Analysis of an Equal-Cost Multi-Path 
             Algorithm, C. Hopps, November 2000 

   [RFC4026] Andersson, L., Madsen, T. "Provider Provisioned 
             Virtual Private Network (VPN) Terminology", RFC 
             4026, March 2005.


_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce