Subject: Draft of new L2VPN WG Charter

From: Giles Heron <[email-masked]>
Date: Fri, 18 Mar 2011 17:41:08 +0000

We plan to re-charter the L2VPN WG - primarily to bring E-VPN and E-Tree
in-scope.

Please find attached a draft charter for discussion both on this list and at
IETF 80 in Prague.

Nabil and Giles

---

From: Giles Heron <[email-masked]>
Date: Fri, 18 Mar 2011 18:21:29 +0000

OK - looks like the attachment didn't come through as intended.  My
apologies.

Text inline:

----------------

The L2VPN working group is responsible for defining and specifying a
limited number of solutions for supporting provider-provisioned Layer-2
Virtual Private Networks (L2VPNs). It will also address requirements driven
by cloud computing services and data centers as they apply to Layer-2
VPN services.

Layer-2 VPNs defined by L2VPN operate over pseudowires (PWs) as
defined by the PWE3 WG or over MPLS PSN tunnels. A L2VPN emulates a
"native" service over a PSN that is adequately faithful to, but may not
be entirely indistinguishable from the native service itself. Further,
following in the "edge-to-edge" nature of the  service, the L2VPN WG will
not define any mechanisms which exert control over the underlying PSN.
When necessary it may, however, recommend or require the use of existing
PSN QoS and path control mechanisms between the PEs which provide the
L2VPN connectivity.

Layer-2 VPNs comprise the following:

1. Virtual Private LAN Service (VPLS) -- A Layer-2 service that emulates
a switched Ethernet (V)LAN across an MPLS Packet Switched Network (PSN).

2. Virtual Private Wire Service (VPWS) -- A Layer-2 service that
provides point-to-point connectivity for a variety of link layers,
including Frame Relay, ATM, Ethernet, PPP, etc., across an MPLS PSN.

3. Virtual Private Multicast Service (VPMS) -- A Layer-2 service that
provides point-to-multipoint connectivity for a variety of link
layers across an MPLS PSN.

4. IP-only L2VPN  An IP-only service over an MPLS PSN.  The WG will
address two specific types of IP-only L2VPN:

a) Point-to-point Layer-2 VPN.  This service is similar to VPWS, but also
supports heterogenous Attachment Circuits at either end of a single
point-to-point service.

b) Multipoint-to-multipoint Layer-2 VPN.  This service is similar to VPLS,
but learns IP and MAC address bindings from ARPs and broadcast/multicast
IP packets.

5. Ethernet VPN (E-VPN) - A Layer-2 technology that emulates an
Ethernet (V)LAN across an MPLS PSN. E-VPN supports load-sharing across
multiple connections from a Layer-2 site to an L2VPN service, and also
supports control plane distribution of MAC addresses and IP to MAC address
bindings in the VPN. E-VPN is primarily targeted to support large-scale
L2VPNs with resiliency requirements not satisfied by other L2VPN solutions.

6. E-Tree  a Layer-2 technology defined by the MEF, which provides
connectivity between one or more ³root² nodes and one or more
³leaf² nodes, with the restriction that leaves may only communicate
with roots (and not with each other).

L2VPNs will make use of existing IETF specified mechanisms unless there
are technical reasons why the existing mechanisms are insufficient or
unnecessary.

The L2VPN WG is responsible for specification of the discovery and
membership of PEs participating in a Layer-2 VPN as well as the
membership of CE devices for a specific instance of an L2VPN.

The L2VPN WG will provide extensions of existing protocols that will be
discussed in protocol-specific WGs. In particular, the L2VPN WG
may define extensions to pseudowire management mechanisms for VPLS.
Those extensions will be reviewed by the PWE3 WG to ensure they are
aligned with the overall design/architecture of PWE3.

The L2VPN WG will not define new encapsulations, control, or resiliency
mechanisms specifically related to pseudowires. Furthermore, when the
L2VPN solution is based on PWs, the L2VPN WG will not define protocol
inter-working between an L2VPN and native service Layer-2 OAM or
resiliency mechanisms. The L2VPN WG may define how to operate native
service-layer control, OAM or resiliency mechanisms on top of an L2VPN.
In addition, it may define native data plane and/or control plane
interworking between an L2VPN and an associated native Layer-2 service.

The L2VPN WG scope includes the following:

1. Discovery of PEs participating in a Layer-2 VPN and the associated
 topology required for connectivity of the VPLS, VPWS, VPMS or E-VPN
 service.

2. Signaling of information related to the discovery and membership of
PEs within a L2VPN. These procedures must use PWE3 control and
management procedures, or define requirements for extensions of PWE3
protocols to suit the needs of an L2VPN, when the L2VPN operates over
PWs. Once those requirements have been reviewed by the L2VPN WG, they
should be provided to the PWE3 WG to derive solutions.

3. MIBs for Layer-2 VPN solutions.

4. Specification of requirements, framework and solutions that
facilitate Operations Administration and Management (OAM) of any type of
L2VPN.

5. Mechanisms to permit optimization of multicast data traffic within
an L2VPN.

6. If transport does not involve PWs, mechanisms that support
load-balancing/multipathing between PEs interconnecting a Layer-2
service using an L2VPN across the MPLS PSN.

7. requirements for the multi-homing of CEs to several VPLS or
E-VPN PEs, inclusive of active/backup and active/active (load-sharing)
configurations. Based on these requirements define VPLS or E-VPN control
plane solutions for achieving fast convergence after failure of an active
path in the PSN or on the AC side.

8. Enhancements to increase the scalability of the Control Plane and
Data Plane of L2VPN PE nodes, and of core nodes that provide transport
services for L2VPN.

9. Requirements and solutions for Auto-Discovery and Signaling of
Inter-AS L2VPNs, in addition to Inter-AS solutions for multicast-optimized
L2VPNs.

10. Requirements and solutions for supporting "E-Tree" services using
VPLS. 

11. Extensions to L2VPN protocols and RFCs necessary to create an MPLS
Transport Profile (MPLS-TP). The work on the MPLS TP will be coordinated
between four primary working groups (MPLS, PWE3, L2VPN and CCAMP) that are
chartered to do MPLS TP work.

Milestones:

Done        Submit an I-D describing MIB for VPLS
Done        Submit an I-D describing MIB for VPWS
Done        Submit an I-D on OAM requirements for VPLS
Done        Submit an I-D on OAM requirements for VPWS
Done        Submit L2 requirements to IESG for publication as Informational
RFC
Done        Submit L2 framework to IESG for publication as Informational RFC
Done        Identify VPLS and VPWS solutions for the WG
Done        Submit VPLS solution documents to IESG
Done        Submit VPWS solution documents to IESG
Done        Submit Auto-Discovery and Signaling for Intra-AS and Inter-AS
            VPLS and VPWS Layer-2 VPNs
Jul 2011    Submit IP-only L2VPN solution documents to IESG
Jul 2011    Submit OAM solutions for VPWS to IESG
Jul 2011    Submit OAM solutions for VPLS to IESG
Jul 2011    Submit signaling solution for multicast-optimized VPLS to IESG
Jul 2011    Submit I-D on Virtual Private Multicast Service (VPMS)
            requirements to IESG
Jul 2011    Submit MIB for VPLS to IESG
Jul 2011    Submit MIB for VPWS to IESG
Nov 2011    Submit scalability solutions for VPLS Data-Plane to IESG
Nov 2011    Submit scalability solutions for VPLS Control-Plane to IESG
Mar 2012    Submit MIB for IP-only L2VPN to IESG
Mar 2012    Submit OAM solutions for IP-only L2VPN to IESG
Mar 2012    Submit Auto-Discovery solution for VPMS to IESG
Mar 2012    Submit VPLS service convergence improvement solutions to IESG
Mar 2012    Submit VPLS multi-homing solutions to IESG
Mar 2012    Submit E-Tree documents to IESG
Mar 2012    Submit E-VPN requirements/framework to IESG
Jul 2012    Submit E-VPN solution to IESG
Nov 2012    Submit E-VPN MIB/OAM to IESG

-----------------

---

From: Raymond Key <[email-masked]>
Date: Thu, 31 Mar 2011 07:38:39 +1100

I support the re-charter.
Raymond Key
 
> Date: Fri, 18 Mar 2011 17:41:08 +0000
> Subject: Draft of new L2VPN WG Charter
> From: [email-masked]
> To: [email-masked]
>

---

From: Benson Schliesser <[email-masked]>
Date: Thu, 31 Mar 2011 09:37:25 -0500

Hi, Giles.

I have a clarifying question about the first paragraph:  What is the purpose
of the 2nd sentence, bringing cloud and DC requirements into the mix?
Assuming this is meant to include non-provider L2VPN environments (like
enterprise data centers), then why not just remove the phrase
"provider-provisioned" from the first sentence?  Otherwise, it seems
redundant.

This is a real question, not a suggestion at this time.

Thanks,
-Benson

---

From: Giles Heron <[email-masked]>
Date: Thu, 31 Mar 2011 15:49:51 +0100

Hi Benson,

This would be provider-provisioned L2VPN environments (whether data-centre
interconnect, or scaling of a large multi-tenant data-centre).

Personally I'm not sure we need the sentence there, but others were keen to
mention the data-centre requirements.
 
Giles

---

From: "Shah, Himanshu" <[email-masked]>
Date: Thu, 31 Mar 2011 10:52:46 -0400

Another point for item 5 -

"and also supports control plane distribution of MAC addresses 
and IP to MAC address bindings in the VPN."

Well, Item 4 also supports control plane distribution of MAC addresses
and IP to MAC address bindings in the VPN.

I do not support having this explicit phrase in the item 5. What is the
justification? It is not a new concept.

/himanshu
 
-----Original Message-----
From: [email-masked] on behalf of Benson Schliesser
Sent: Thu 3/31/2011 10:37 AM
To: Giles Heron; [email-masked]
Subject: Re: Draft of new L2VPN WG Charter
 
Hi, Giles.

Thanks,
-Benson

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 31 Mar 2011 10:57:58 -0400

> mention the data-centre requirements.

	I think that is meant to explicitly field requirements for solutions 
that come from ARMD/etc... into the WG, since they cannot build their own 
solutions.  While that isn't implicitly handled in the existing charter, I
do not know either. 

	--Tom

>>> 4. IP-only L2VPN – An IP-only service over an MPLS PSN.  The WG will
>>> 6. E-Tree – a Layer-2 technology defined by the MEF, which provides
>>> connectivity between one or more “root” nodes and one or more
>>> “leaf” nodes, with the restriction that leaves may only communicate

---

From: "Shah, Himanshu" <[email-masked]>
Date: Thu, 31 Mar 2011 10:57:10 -0400

I agree with Ben (and apparently yours) concern.
I suggest we remove that sentence.
/himanshu

-----Original Message-----
From: [email-masked] on behalf of Giles Heron
Sent: Thu 3/31/2011 10:49 AM
To: Benson Schliesser; [email-masked]
Subject: Re: Draft of new L2VPN WG Charter
 
Hi Benson,

 
Giles

---

From: Giles Heron <[email-masked]>
Date: Thu, 31 Mar 2011 16:18:38 +0100

Let¹s see what others say.

I¹m off on vacation for the next 10 days but will discuss the charter again
with Nabil and the ADs when I return.

Giles

On 31/03/2011 15:57, "Shah, Himanshu" <[email-masked]> wrote:

>>> >> Jul 2011    Submit signaling solution for multicast-optimized VPLS to >>>
IESG

---

From: xuxiaohu 41208 <[email-masked]>
Date: Thu, 31 Mar 2011 17:18:26 +0200

Agree. Maybe a neutral definition of such special VPLS is more acceptable, such as, "MAC Announcement based VPLS", in contrast to the existing VPLS which uses data-driven MAC learning. E-VPN is just a special instance of such catagory, which uses BGP to announce MAC reachability information.

Best regards,
Xiaohu

----- 原邮件 -----
发件人: "Shah, Himanshu" <[email-masked]>
日期: 星期四, 三月 31日, 2011 下午4:58
主题: RE: Draft of new L2VPN WG Charter
收件人: Benson Schliesser <[email-masked]>, Giles Heron <[email-masked]>, [email-masked]

> Assuming this is meant to include non-provider L2VPN environments 
> (likeenterprise data centers), then why not just remove the phrase
> > be entirely indistinguishable from the native service itself. 
> Further,> following in the "edge-to-edge" nature of the  service, 
> the L2VPN WG will
> > When necessary it may, however, recommend or require the use of 
> existing> PSN QoS and path control mechanisms between the PEs 
> which provide the
> > L2VPN connectivity.
> > 
> > 1. Virtual Private LAN Service (VPLS) -- A Layer-2 service that 
> emulates> a switched Ethernet (V)LAN across an MPLS Packet 
> Switched Network (PSN).
> > 
> > 3. Virtual Private Multicast Service (VPMS) -- A Layer-2 service 
> that> provides point-to-multipoint connectivity for a variety of link
> > 4. IP-only L2VPN ? An IP-only service over an MPLS PSN.  The WG will
> > but learns IP and MAC address bindings from ARPs and 
> broadcast/multicast> IP packets.
> > 
> > Ethernet (V)LAN across an MPLS PSN. E-VPN supports load-sharing 
> across> multiple connections from a Layer-2 site to an L2VPN 
> service, and also
> > L2VPNs with resiliency requirements not satisfied by other L2VPN 
> solutions.> 
> > 6. E-Tree ? a Layer-2 technology defined by the MEF, which provides
> > connectivity between one or more ?root? nodes and one or more
> > ?leaf? nodes, with the restriction that leaves may only communicate
> > The L2VPN WG will not define new encapsulations, control, or 
> resiliency> mechanisms specifically related to pseudowires. 
> Furthermore, when the
> > L2VPN solution is based on PWs, the L2VPN WG will not define 
> protocol> inter-working between an L2VPN and native service Layer-
> 2 OAM or
> > service-layer control, OAM or resiliency mechanisms on top of an 
> L2VPN.> In addition, it may define native data plane and/or 
> control plane
> > interworking between an L2VPN and an associated native Layer-2 
> service.> 
> > 1. Discovery of PEs participating in a Layer-2 VPN and the 
> associated>  topology required for connectivity of the VPLS, VPWS, 
> VPMS or E-VPN
> >  service.
> > 
> > protocols to suit the needs of an L2VPN, when the L2VPN operates 
> over> PWs. Once those requirements have been reviewed by the L2VPN 
> WG, they
> > 5. Mechanisms to permit optimization of multicast data traffic 
> within> an L2VPN.
> > 
> > E-VPN PEs, inclusive of active/backup and active/active (load-
> sharing)> configurations. Based on these requirements define VPLS 
> or E-VPN control
> > Data Plane of L2VPN PE nodes, and of core nodes that provide 
> transport> services for L2VPN.
> > 
> > Inter-AS L2VPNs, in addition to Inter-AS solutions for multicast-
> optimized> L2VPNs.
> > 
> > 10. Requirements and solutions for supporting "E-Tree" services 
> using> VPLS. 
> > 
> > Transport Profile (MPLS-TP). The work on the MPLS TP will be 
> coordinated> between four primary working groups (MPLS, PWE3, 
> L2VPN and CCAMP) that are
> > Done        Submit L2 requirements to IESG for publication as 
> Informational> RFC

---

From: "Shah, Himanshu" <[email-masked]>
Date: Thu, 31 Mar 2011 11:21:02 -0400

My understanding is that, as a first step, the problem
scope needs to be understood. Solutions, if any required,
could follow only after the problem is well understood.
Solutions are part of ARMD charter but only after first step
is completed.

Although, it appears that L2VPN group has already acknowledged
and understood the problem well enough to propose solutions??

/himanshu

-----Original Message-----
From: [email-masked] on behalf of Thomas Nadeau
Sent: Thu 3/31/2011 10:57 AM
To: Giles Heron
Cc: [email-masked]
Subject: Re: Draft of new L2VPN WG Charter

	--Tom

>>> 4. IP-only L2VPN - An IP-only service over an MPLS PSN.  The WG will
>>> 6. E-Tree - a Layer-2 technology defined by the MEF, which provides
>>> connectivity between one or more "root" nodes and one or more
>>> "leaf" nodes, with the restriction that leaves may only communicate

---

From: Benson Schliesser <[email-masked]>
Date: Thu, 31 Mar 2011 11:18:05 -0500

Speaking as ARMD co-chair:  Solution development is not in our charter, but
analysis of existing solutions (and identification of gaps) is.  If we
identify gaps, then ARMD might be re-chartered to develop solutions  or we
might send our requirements into other WGs for development.  This is TBD
pending our work on the Problem Statement.

Speaking personally: I don¹t have any objection to L2VPN working on data
center solutions.  If somebody deploys e.g. VPLS inside an enterprise
network, provider data center, provider metro network, etc, I think these
are all valid use-cases.  This is why I asked my question about the 2nd
sentence  it seems redundant.

Cheers,
-Benson

On 3/31/11 10:21 AM, "Shah, Himanshu" <[email-masked]> wrote:

>>>> existing
>>>> emulates
>>>> broadcast/multicast
>>>> solutions.
>>>> coordinated
>>>> Informational