Subject: [PWE3] Fwd: Last Call: <draft-kompella-l2vpn-l2vpn-07.txt> (Layer 2 Virtual Private Networks Using BGP for Auto-discovery and Signaling) to Informational RFC

From: Stewart Bryant <[email-masked]>
Date: Thu, 01 Sep 2011 11:50:03 +0100

Please can I draw the following document to the
attention of the PWE3 and L2VPN WGs.

Your comments would be welcome.

It is an individual AD sponsored submission.

- Stewart

-------- Original Message --------
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-masked]>
Reply-To: 	[email-masked]
To: 	IETF-Announce <[email-masked]>

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-masked] mailing lists by 2011-09-27. Exceptionally, comments may be
sent to [email-masked] 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-masked]
https://www.ietf.org/mailman/listinfo/ietf-announce

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 1 Sep 2011 07:42:00 -0400

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

> Auto-discovery and Signaling) to Informational RFC  Date: Tue, 30 Aug 2011
> 10:50:05 -0700  From: The IESG <[email-masked]><[email-masked]>  Reply-To:
> [email-masked]  To: IETF-Announce <[email-masked]><[email-masked]>
>
> final comments on this action. Please send substantive comments to [email-masked] mailing lists by 2011-09-27. Exceptionally, comments may be
> 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/
>
>
> IETF-Announce mailing [email-masked]://www.ietf.org/mailman/listinfo/ietf-announce
>
>

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 01 Sep 2011 15:55:41 +0200

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.

---

From: Luca Martini <[email-masked]>
Date: Tue, 13 Sep 2011 09:23:45 -0600

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
>     <mailto:[email-masked]>
>     Reply-To: 	[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked]>
>
>
>
>     [email-masked] <mailto:[email-masked]> mailing lists by 2011-09-27. Exceptionally, comments may be
>     sent to [email-masked] <mailto:[email-masked]> instead. In either case, please retain the
>     [email-masked] <mailto:[email-masked]>
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 13 Sep 2011 18:03:38 +0200

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.)

Regards,
     Sasha

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Luca
> Martini
> Sent: Tuesday, September 13, 2011 6:24 PM
> To: Andrew G. Malis
> Cc: [email-masked]; 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.

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.

---

From: Luca Martini <[email-masked]>
Date: Tue, 13 Sep 2011 13:16:58 -0600

> 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 descr…
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

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 13 Sep 2011 22:14:43 +0200

Luca,
The draft in question exists for almost 8 years (the -00 version has been posted 2004-01-13), has been implemented and deployed.

I have not heard that solutions compliant with RFC 6074 (which is the proper analog of 4447 in this case IMO)  have been deployed in this interval - and that in spite of 6074 sitting in the RFC Editor queue (i.e., sufficiently stable for any potential implementer) for almost 6 years (from 2006-06-12).

Hence I do not see this case as similar to what happened to the original draft-martini vs. RFC 4447.

Do I miss something substantial here?

Regards,
    Sasha
________________________________________
From: Luca Martini [[email-masked]]
Sent: Tuesday, September 13, 2011 9:16 PM
To: Alexander Vainshtein
Cc: [email-masked]; pwe3; IETF Discussion; Andrew G. Malis
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

Luca

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 14 Sep 2011 08:45:12 -0400

I agree. Historic seems go be the way to go with this document.

Sent from my iPad

---

From: "Balus, Florin Stelian (Florin)" <[email-masked]>
Date: Wed, 14 Sep 2011 12:21:31 -0500

I do not have a strong opinion on historical vs. experimental but I want to say that solutions based on RFC 6074 (so called "BGP-AD") have been deployed in multiple networks some of them with mixed vendor environment. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
Sent: Tuesday, September 13, 2011 1:15 PM
To: Luca Martini
Cc: [email-masked]; pwe3; IETF Discussion
Subject: Re: [PWE3] Last Call: <draft-kompella-l2vpn-l2vpn-07.txt> (Layer 2 Virtual Private Networks Using BGP for Auto-discovery and Signaling) to Informational RFC

Luca,

Regards,
    Sasha

Luca

_______________________________________________
pwe3 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pwe3

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 14 Sep 2011 19:13:33 +0100

It is clear that:

1) RFC6074 is the IETF recommended approach.
2) That draft-kompella-l2vpn-l2vpn is in active deployment.

The question is whether the number of independent
deployments of draft-kompella-l2vpn-l2vpn is
increasing or not. In other words is this a legacy
approach that will over time decline, or is it a
parallel alternative that will be actively chosen
by some subset of operators going forward and
which will be implemented by more than one vendor.

- Stewart

On 13/09/2011 21:14, Alexander Vainshtein wrote:
> 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
>
>>> Subject: Re: Last Call:<draft-kompella-l2vpn-l2vpn-07.txt>  (Layer 2 Virtual
>>>>      From:   The IESG<[email-masked]>
>>>>      Reply-To:       [email-masked]<mailto:[email-masked]>
>>>>      To:     IETF-Announce<[email-masked]>
>>>>      [email-masked]<mailto:[email-masked]>  mailing lists by 2011-09-27.
>>> Exceptionally, comments may be
>>>>      sent to [email-masked]<mailto:[email-masked]>  instead. In either case,
>>> please retain the
>>>>      [email-masked]<mailto:[email-masked]>

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Kireeti Kompella <[email-masked]>
Date: Wed, 14 Sep 2011 14:08:29 -0700

Hi Stewart,

> which will be implemented by more than one vendor.

a) The deployments are increasing.  This is the chosen approach for some subset of operators.  This is not a legacy approach.  I can't say what will happen going forward, but to the extent that I can see, this is the chosen direction for some subset of operators.

b) There are implementations by more than one vendor.

c) The BBF will build solutions on top of this, in parallel with other approaches.

Kireeti.