Subject: Re: Draft of new L2VPN WG Charter

From: Giles Heron <[email-masked]>
Date: Tue, 14 Jun 2011 00:08:02 +0100

So in the absence of any follow-up to Nabil¹s email we¹d like to propose
that we adopt the charter as below.

The only modifications from the charter Giles posted at the start of this
thread are:
1) fixed the 2011 date on VPMS Auto-Discovery to 2012 (as spotted by Ben)
2) changed E-Tree from ³technology² to ³service² (as suggested by Yuanlong)
3) we¹ve pushed the E-VPN solution and OAM/MIB milestones back a year, in
response to Joel¹s comment about deferring these.

The main area of debate seems to have been the second sentence:

³It will also address requirements driven by cloud computing services and
data centers as they apply to Layer-2 VPN services.²

Unless there¹s any strong objection to this sentence that garners some
degree of consensus we propose to leave it in.

We¹d like to wrap this up in the next couple of weeks, so let¹s bring any
debate to a close by Friday 24th June and then move forward.  Those with
sharp eyes will notice that the first of our new deadlines are fast
approaching!

Giles & Nabil

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 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 service 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 service 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 2013    Submit E-VPN solution to IESG
Nov 2013    Submit E-VPN MIB/OAM to IESG

On 08/05/2011 16:34, "Bitar, Nabil N" <[email-masked]> wrote:

> Hi,
> As we are working to firming up the charter, I think it will be good to
> address the questions raised in this thread. I am hearing question about the
> intention of that second sentence mentioned more than opposition to it.
> We are still addressing provider-provisioned L2VPN. However, nothing restricts
> the environment that this gets used in. For instance, if there is value to
> expand l2vpn such as VPLS into the data center, would that be excluded? I am
> not judging that there is value or not. If there are new requirements that
> drive additional solutions, should they be excluded?
> In addition,  Data center and data center interconnects in a cloud  could
> bring requirements to interconnect technologies that we had not looked at
> before in  the l2vpn WG. Certainly, a data center layer2 network can be based
> on Trill or 802.1aq as examples which we had not covered before in addition to
> 802.1ad or  PBB .   If there are requirements to interconnect data centers
> using these technologies, l2vpn-solutions may be needed (and if needed drafts
> will show up).  These are examples and are not to restrict the types of
> requirements. There are already drafts driven from data center and cloud
> viewpoint that have been brought in by folks. Could we live without the
> sentence in question? Probably yes. However, calling out explicitly that
> solutions that address data center and cloud requirements as they apply to
> l2vpn are within the l2vpn WG charter adds more clarity to what we could be
> taking on upfront. We all know based on industry activities, that is an area
> of interest, and there have been already drafts brought to the l2vpn WG driven
> by that although some were not layer2-based. For that reason also, I think
> calling it out as in the draft charter points out that only L2 will be
> addressed by the l2vpn WG, which may seem like calling out the obvious.
> 
> Thanks,
> Nabil
> 
> On 3/31/11 12:18 PM, "Benson Schliesser" <[email-masked]> wrote:
> 
>> 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:
>> 
>>> 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
>>> 
>>> 
>>> On Mar 31, 2011, at 10:49 AM, Giles Heron wrote:
>>> 
>>>> 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.
>>> 
>>>         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
>>> 
>>> 
>>>> 
>>>> Giles
>>>> 
>>>> On 31/03/2011 15:37, "Benson Schliesser" <[email-masked]> wrote:
>>>> 
>>>>> 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
>>>>> 
>>>>> 
>>>>> 
>>>>> On 3/18/11 1:21 PM, "Giles Heron" <[email-masked]> wrote:
>>>>> 
>>>>>> 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
>>>>>> 
>>>>>> -----------------
>>>>>> 
>>>>>> On 18/03/2011 17:41, "Giles Heron" <[email-masked]> wrote:
>>>>>> 
>>>>>>> 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
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> 
>> 
> 
> ---------------------------------------------
> Nabil Bitar, PhD
> Principal Member of Technical Staff
> Packet Network Technology
> Verizon Corporate Network and Technology
> 
> 60 Sylvan Road
> Waltham, MA 02451
> Office Phone: (781) 466-2161
>

---

From: "Shah, Himanshu" <[email-masked]>
Date: Fri, 24 Jun 2011 17:30:00 -0400

Giles/Nabil -

Nabil's email (at the bottom of this email) did not address one of points
I had raised.

This relates to specific sentence in charter (5) text
" and also supports control plane distribution of MAC addresses and IP to MAC address
bindings in the VPN."

As I had indicated before on the mailing list, control plane distribution of
MAC to IP binding is not NEW and was already introduced 7 to 8 years ago by
proposed solutions related to charter (4).

By explicitly mentioning this item in the charter (5) gives impression that
a new concept is being developed or introduced, which is not the case.

This needs to be corrected.

Thanks,
himanshu

-----Original Message-----
From: Giles Heron [mailto:[email-masked]]
Sent: Monday, June 13, 2011 7:08 PM
To: Bitar, Nabil N; Benson Schliesser; Shah, Himanshu; Thomas Nadeau
Cc: [email-masked]
Subject: Re: Draft of new L2VPN WG Charter

Giles & Nabil

Milestones:

---

From: Thomas Beckhaus <[email-masked]>
Date: Sat, 25 Jun 2011 04:48:29 +0200

Giles, Nabil,

in contrast to the other topics in the charter, the sentence in "Layer-2 VPN" topic 5 "and also supports control plane distribution of MAC addresses and IP to MAC address bindings" describes a solution and not a requirement. I think, the flexibility in the area of the solution is covered by the additional text of the charter.

I think there is no need to mention it explicit.

Thomas

Am 14.06.2011 um 01:08 schrieb Giles Heron <[email-masked]>:

> So in the absence of any follow-up to Nabil’s email we’d like to propose
> 2) changed E-Tree from “technology” to “service” (as suggested by Yuanlong)
> 3) we’ve pushed the E-VPN solution and OAM/MIB milestones back a year, in
> response to Joel’s comment about deferring these.
> 
> “It will also address requirements driven by cloud computing services and
> data centers as they apply to Layer-2 VPN services.”
> 
> Unless there’s any strong objection to this sentence that garners some
> We’d like to wrap this up in the next couple of weeks, so let’s bring any
> 4. IP-only L2VPN – An IP-only service over an MPLS PSN.  The WG will
> 6. E-Tree – a Layer-2 service 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
>>> identify gaps, then ARMD might be re-chartered to develop solutions – or we
>>> Speaking personally: I don’t have any objection to L2VPN working on data
>>> – it seems redundant.

---

From: Xu Xiaohu <[email-masked]>
Date: Sat, 25 Jun 2011 11:34:56 +0800

I have the same feeling. IMHO, IPLS and E-VPN are two alternative solutions for "routing" VPLS which supports the distribution of MAC addresses on the control plane, especially the former is LDP-based while the latter is BGP-based.

Best regards,
Xiaohu

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表 Shah,
> Himanshu
> 发送时间: 2011年6月25日 5:30
> 收件人: Giles Heron; Bitar, Nabil N; Benson Schliesser; Thomas Nadeau
> 抄送: [email-masked]
> 主题: RE: Draft of new L2VPN WG Charter
> 
> Giles/Nabil -
>