A Framework for Ethernet Tree (E-Tree) Service over a Multiprotocol Label Switching (MPLS) Network
draft-ietf-l2vpn-etree-frwk-10

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: RFC Editor <rfc-editor@rfc-editor.org>,
    l2vpn mailing list <l2vpn@ietf.org>,
    l2vpn chair <l2vpn-chairs@tools.ietf.org>
Subject: Document Action: 'A Framework for Ethernet Tree (E-Tree) Service over a Multiprotocol Label Switching (MPLS) Network' to Informational RFC (draft-ietf-l2vpn-etree-frwk-10.txt)

The IESG has approved the following document:
- 'A Framework for Ethernet Tree (E-Tree) Service over a Multiprotocol
   Label Switching (MPLS) Network'
  (draft-ietf-l2vpn-etree-frwk-10.txt) as Informational RFC

This document is the product of the Layer 2 Virtual Private Networks
Working Group.

The IESG contact persons are Adrian Farrel and Alia Atlas.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-l2vpn-etree-frwk/

Ballot Text

Technical Summary:
 
   This document describes an Ethernet-Tree (E-Tree) solution framework
   for supporting the Metro Ethernet Forum (MEF) E-Tree service over a
   Multiprotocol Label Switching (MPLS) network. The objective is to
   provide a simple and effective approach to emulate E-Tree services
   in addition to Ethernet LAN (E-LAN) services on an existing MPLS
   network.

   An E-Tree service is defined by one or more roots and one or more leaves.
   Roots can send traffic to other roots and leaves and receive traffic from 
   other roots and leaves within the same service instance. Leaves can only
   receive traffic from roots and send traffic to roots in the same service 
   instance.

Working Group Summary:

   This document is an L2VPN Working Group document. It has gone through few 
   iterations and addressed quite few comments/input/edits from the WG chairs that 
   resulted in draft version 4 that passed WG LC with many people supporting it. 
   Versions 5 and 6 addressed some indicts.

Document Quality:

   The document has good quality. It is clear on the technical content and written with 
   good English and layout. There are a couple of edits needed that can be taken up 
   during the RFC edits.

Personnel:

   Document Shepherd: Nabil Bitar (nabil.n.bitar@verizon.com)
   Area Director: Adrian Farrel (adrian@olddog.co.uk)

RFC Editor Note