On 09/13/11 10:03, Alexander Vainshtein wrote: > Luca, and all, > > I concur with Andy's opinion that the reference to RFC 4447 must become > Normative (this will not delay the publication is too often the case:-). > > As for Informational vs. Historical, I think that Informational is more > appropriate because, AFAIK, the technique defined in draft-kompella is not > just a documenting an existing solution - it describes is THE ONLY deployed > solution for the problem. (If this statement happens to be factually > incorrect, I would be happy to learn about the deployed alternatives.) no, there are several ( I think 3 ) implementations of the l2vpn-singalling standards track document also known as rfc6074. There are several deployments of rfc6074.
As 10 years ago we had several deployments of "draft-martini" which over time are being updated to rfc4447 , there are some deployments of the solution described in the draft-kompella-l2vpn-l2vpn-07.txt. I still think that an historical RFC would fit this solution , unless we plan on expanding it , and pursuing new enhancements to it. Luca > Regards, > Sasha > >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On Behalf Of >> Luca >> Martini >> Sent: Tuesday, September 13, 2011 6:24 PM >> To: Andrew G. Malis >> Cc: [email protected]; pwe3; IETF Discussion >> Subject: Re: Last Call: <draft-kompella-l2vpn-l2vpn-07.txt> (Layer 2 Virtual >> Private Networks Using BGP for Auto-discovery and Signaling) to Informational >> RFC >> >> 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 > > > This e-mail message is intended for the recipient only and contains > information which is CONFIDENTIAL and which may be proprietary to ECI > Telecom. If you have received this transmission in error, please inform us by > e-mail, phone or fax, and then delete the original and all copies thereof. > > _______________________________________________ Ietf mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf
