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: l2vpn-bounces@xxxxxxxx [mailto:l2vpn-bounces@xxxxxxxx] On Behalf Of Luca >> Martini >> Sent: Tuesday, September 13, 2011 6:24 PM >> To: Andrew G. Malis >> Cc: l2vpn@xxxxxxxx; 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 <iesg-secretary@xxxxxxxx> >>> <mailto:iesg-secretary@xxxxxxxx> >>> Reply-To: ietf@xxxxxxxx <mailto:ietf@xxxxxxxx> >>> To: IETF-Announce <ietf-announce@xxxxxxxx> >>> <mailto:ietf-announce@xxxxxxxx> >>> >>> >>> >>> 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 >>> ietf@xxxxxxxx <mailto:ietf@xxxxxxxx> mailing lists by 2011-09-27. >> Exceptionally, comments may be >>> sent to iesg@xxxxxxxx <mailto:iesg@xxxxxxxx> 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 >>> IETF-Announce@xxxxxxxx <mailto:IETF-Announce@xxxxxxxx> >>> https://www.ietf.org/mailman/listinfo/ietf-announce >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Ietf mailing list >>> Ietf@xxxxxxxx >>> 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 Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf