I concurr with Andy. Given that the WG has made a decision on which control plane technology is the standard track technology we should have a statement in this document pointing to the standard track rfc4447 so it is clear to anyone reading the document. In the same way we published the draft-martini documents as historical ee should publish this document as historical rfc, to document existing implementations.
Luca On 09/01/11 05:42, Andrew G. Malis wrote: > 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]> > <mailto:[email protected]> > Reply-To: [email protected] <mailto:[email protected]> > To: IETF-Announce <[email protected]> > <mailto:[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 the > [email protected] <mailto:[email protected]> mailing lists by 2011-09-27. > Exceptionally, comments may be > sent to [email protected] <mailto:[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 via > http://datatracker.ietf.org/doc/draft-kompella-l2vpn-l2vpn/ > > IESG discussion can be tracked via > http://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 list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/ietf-announce > > > > > > _______________________________________________ > Ietf mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf
