Subject: Re: Draft of new L2VPN WG Charter

From: "Bitar, Nabil N" <[email-masked]>
Date: Sun, 8 May 2011 11:34:12 -0400

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: "Bitar, Nabil N" <[email-masked]>
Date: Sun, 8 May 2011 11:34:19 -0400

Hi Himanshu,
Please see inlime.

Thanks,
Nabil

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

<NB> This applies to ARMD.

<NB> I am not sure that is being said or it could be construed from the proposed WG charter. Addressing data center requirements (which define the problems and could be brought into the l2vpn WG or the Ops group) as they apply to l2vpn is what is proposed to be in the WG charter.  One may ask how do we know there are any. There are already drafts being brought in driven by that as I mentioned in the other email. Given the activities areas we may want to call it out explicitly and restrict it to l2vpn.

/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

60 Sylvan Road
Waltham, MA 02451