I support adoption and publishing draft-kompella-l2vpn-l2vpn-07.txt as
informational RFC. Using BGP for auto-discovery and signalling of L2VPNs
is by all means a right approach.
The draft also makes it very clear that underlying transport is opaque
and allows to use any form of encapsulation for PE-PE data exchange.
In that light I would not recommend to make any references in it to
RFC4447 and treat both specs as fully independent and unreleated documents.
Speaking as an individual, the solution in this draft has been has been
operationally deployed in a number of service provider networks, and it
should be documented in an informational RFC.
Speaking as PWE3 co-chair, I would be happier if this draft required that
routers that implement this solution also implement RFC 4447, that RFC 4447
be configured as the default mechanism for pseudowire signaling, and that
RFC 4447 was moved from an informational to a normative reference. In
practice, I know that routers that implement this also do implement RFC
4447, but I would like to see it in the RFC as well.
Subject: Last Call: (Layer 2 Virtual Private Networks Using BGP for
Auto-discovery and Signaling) to Informational RFC Date: Tue, 30 Aug 2011
10:50:05 -0700 From: The IESG
ietf(_at_)ietf(_dot_)org To: IETF-Announce
The IESG has received a request from an individual submitter to consider
the following document:
- 'Layer 2 Virtual Private Networks Using BGP for Auto-discovery and
<draft-kompella-l2vpn-l2vpn-07.txt> as an Informational RFC
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to
theietf(_at_)ietf(_dot_)org mailing lists by 2011-09-27. Exceptionally,
comments may be
sent to iesg(_at_)ietf(_dot_)org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.
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.
The file can be obtained
IESG discussion can be tracked
The following IPR Declarations may be related to this I-D:
Ietf mailing list