Hi, 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. Best regards, R. > 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. > > Thanks, > Andy > > 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 >> <[email protected]><[email protected]> Reply-To: >> [email protected] To: IETF-Announce >> <[email protected]><[email protected]> >> >> 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 >> Signaling' >> <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 >> [email protected] mailing lists by 2011-09-27. Exceptionally, comments may be >> sent to [email protected] instead. In either case, please retain the >> beginning of the Subject line to allow automated sorting. >> >> Abstract >> >> >> 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 >> viahttp://datatracker.ietf.org/doc/draft-kompella-l2vpn-l2vpn/ >> >> IESG discussion can be tracked >> viahttp://datatracker.ietf.org/doc/draft-kompella-l2vpn-l2vpn/ >> >> >> The following IPR Declarations may be related to this I-D: >> >> http://datatracker.ietf.org/ipr/1149/ >> >> >> >> _______________________________________________ >> IETF-Announce mailing >> [email protected]https://www.ietf.org/mailman/listinfo/ietf-announce >> >> > _______________________________________________ Ietf mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf
