Layer 2 Virtual Private Networks Using BGP for Auto-Discovery and Signaling
draft-kompella-l2vpn-l2vpn-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>
Subject: Document Action: 'Layer 2 Virtual Private Networks Using BGP for Auto-discovery and Signaling' to Informational RFC (draft-kompella-l2vpn-l2vpn-10.txt)

The IESG has approved the following document:
- 'Layer 2 Virtual Private Networks Using BGP for Auto-discovery and
   Signaling'
  (draft-kompella-l2vpn-l2vpn-10.txt) as an Informational RFC

This document has been reviewed in the IETF but is not the product of an
IETF Working Group.

The IESG contact person is Stewart Bryant.

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

Ballot Text

Technical Summary

Layer 2 Virtual Private Networks (L2VPNs) based on Frame Relay or ATM
circuits have been around a long time; more recently, Ethernet VPNs,
including Virtual Private LAN Service, have become popular.
Traditional L2VPNs often required a separate Service Provider
infrastructure for each type, and yet another for the Internet and IP
VPNs.  In addition, L2VPN provisioning was cumbersome.  This document
presents a new approach to the problem of offering L2VPN services
where the L2VPN customer's experience is virtually identical to that
offered by traditional Layer 2 VPNs, but such that a Service Provider
can maintain a single network for L2VPNs, IP VPNs and the Internet,
as well as a common provisioning methodology for all services.



Working Group Summary

 This is an individual contribution with AD sponsorship, and is not a WG
 document. It was presented to and reviewed by the L2VPN working group.
 However, there was not WG consensus to make it a WG draft.  Instead, the
 L2VPN chairs (along with the AD's) ultimately determined that it was best to
 proceed forward as an Individual Informational Draft in order that it was
 permanently published, along with its codepoint registry, for other
 implementers to reference.

Document Quality

 There are at least two vendors who have implemented this protocol.  The
 protocol has been implemented and deployed in operational networks.

Personnel

Ross Callon (rcallon@juniper.net) is the document shepherd.
Stewart Bryant (stbryant@cisco.com) is the responsible AD.

RFC Editor Note

Last para of section 3, i.e., before 3.1):
OLD
The second is the introduction of TLVs (Type-Length-Value triplets) in 
the VPLS NLRI (Network Layer Reachability Information). L2VPN TLVs 
can be added to extend the information carried in the NLRI, using the 
format shown in Figure 2. In L2VPN TLVs, Type is 1 octet, Length is 2 
octets and represents the size of the Value field in bits.

NEW
The second is the introduction of TLVs (Type-Length-Value triplets) in 
the VPLS NLRI (Network Layer Reachability Information). L2VPN TLVs 
can be added to extend the information carried in the NLRI, using the 
format shown in Figure 2. In L2VPN TLVs, Type is 1 octet, Length is 2 
octets and represents the size of the Value field in bits. L2VPN TLVs, if 
present, occur as the last element of a VPLS NLRI.  The length of the 
NLRI includes the total length of the TLVs, including their headers.
END

RFC Editor Note