Subject: RE: L2VPN WG (Re-)charter

From: "BALUS Florin" <[email-masked]>
Date: Tue, 1 Apr 2008 12:04:35 -0500

Hi,
See below some comments (between FB>) on selected items:

The L2VPN WG scope includes the following:
[..] 
6. Improved service convergence for multi-homed CE's to VPLS PE's.
    Specifically, upon failure of a primary path from a CE to VPLS PE,
    initiate a rapid switch-over to an alternate path.  If required,
    interactions with native service-layer resiliency mechanisms will be
    provided via solutions from other IETF WG's such as PWE3.

FB> Suggest we modify the text to include also multi-homing between 2
VPLS domains, see below an example of text:
6. Improved service convergence for multi-homing solutions: CEs to VPLS
PEs or between VPLS domains. Specifically, upon failure of a primary
path from a between CEs and VPLS PEs or between VPLS domains, initiate a
rapid switch-over to an alternate path. If required, interactions with
native service-layer resiliency mechanisms will be provided via
solutions from other IETF WG's such as PWE3.
FB>

7. Enhancements to increase the scalability of the Forwarding Database
of VPLS PE nodes.

FB> I think we should make this text more generic: i.e. 7. Enhancements
to increase VPLS scalability.
This will  address any issues that might be raised in the future. In the
milestones we have anyhow two more generic items that are already
looking beyond what the current item 7 is covering: i.e.
Nov 2009    Submit scalability solutions for VPLS Control-Plane to IESG
Nov 2009    Submit scalability solutions for VPLS Data-Plane to IESG
FB>

The L2VPN WG currently works on the following tasks:
[..]
- Identify requirements for multi-homing of CE's to VPLS PE's.
   elements.  Based on these requirements, define solutions for
achieving
   fast convergence after a switchover to an alternate path, for example
   through optimized MAC flushing within a VPLS domain.

FB> Suggest changing this one to the following text:
- Identify requirements for different multi-homing solutions: i.e. CEs
to VPLS Pes or between VPLS domains. Based on these requirements, define
solutions for achieving fast convergence after a switchover to an
alternate path, for example through optimized MAC flushing within a VPLS
domain.
FB>

Goals and Milestones:
[..]
FB> We are missing here L2VPN Auto-discovery, Signaling and Inter-AS
(see draft-ietf-l2vpn-signaling-08.txt). This was already submitted to
IESG and is waiting in the RFC queue. Suggest adding the following item:

"Done  Submit L2VPN Auto-discovery, Signaling and Inter-AS to IESG"
[..]

Nov 2008    Submit MAC learning optimization solutions for VPLS to IESG
FB> What is this about?
[..]
Mar 2009    Submit I-D on Virtual Private Multicast Service
(VPMS)requirements to IESG
[..]
Nov 2009    Submit Auto-Discovery solution for VPMS to IESG

FB> (this comment applies to the 2 previous items) Not sure I understand
what are we trying to achieve here? We stated in item 5 of the charter
that L2 VPN WG is going to deal with "5. Mechanisms to permit
optimization of multicast data traffic within a VPLS or VPWS VPN over an
IP/MPLS PSN." Is VPMS a way to optimize VPLS/VPWS or is it similar with
P2MP LSPs? Or is it P2MP PWs? I see L2VPN WG working on this just in
case we are dealing with a VPN like collection of PWs. Otherwise we
should probably address this in PWE3/MPLS to start with.
FB>

Jul 2010    Submit Inter-AS VPLS and VPWS solutions to IESG
FB> I thought we already have these items addressed in
draft-ietf-l2vpn-signaling-08.txt ("Provisioning, Autodiscovery, and
Signaling in L2VPNs"), currently in the RFC queue. 

Regards,
Florin

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Shane Amante
> Sent: Sunday, March 16, 2008 4:11 PM
> To: [email-masked]
> Subject: L2VPN WG (Re-)charter
> 
> Hi,
> 
> As mentioned during the WG meeting at IETF 71 in 
> Philadelphia, below is a proposed draft of a new charter for 
> the L2VPN WG.  Included are the following new items:
> - Multicast
> - Scalability
> - Multi-homing / Service Convergence
> - Inter-AS
> 
> Please take a look at the entire text, including suggested 
> dates for deliverables & milestones.
> 
> Please send any questions, clarifications or suggested 
> changes to the WG mailing list.  If you believe the new 
> charter (below) is fine "as- is", then please indicate your 
> support to the WG mailing list, as well.
> 
> We would like to set a time-limit for discussion and 
> agreement of the  
> new charter, in order that we can get back to the business at hand.   
> As such, let me propose that we wrap-up discussion and gauge 
> (rough) consensus by Friday, April 25, 1700 MDT (UTC -6), 
> which is a little over 1 month from now.
> 
> Thanks,
> 
> -shane & Vach
> 
> ---cut here---
> 
> 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).  Layer-2 VPN's comprise the
> following:
> 
> 1. Virtual Private LAN Service (VPLS) -- A Layer-2 service 
> that emulates
>     an Ethernet (V)LAN across an IP or an MPLS-enabled IP 
> 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 IP or 
> MPLS- enabled IP
>     PSN.
> 
> 3. IP-only L2VPN -- A point-to-point or point-to-multipoint "IP-only"
>     service over an IP or MPLS-enabled PSN.  This service is 
> similar to
>     VPWS because it supports a variety of link-layer protocols on the
>     Attachment Circuits, including Frame Relay, ATM, 
> Ethernet, PPP, etc.
>     IP-only L2VPN's are different from both VPLS and VPWS 
> because unicast
>     Layer-2 frames containing IP data packets, either IPv4 or 
> IPv6, are de-
>     encapsulated leaving only the IP data packet to be 
> transmitted over
>     the PSN.  An IP-only L2VPN service also differs from 
> L3VPN service,
>     since no routing protocol operates between the PE and CE; 
> furthermore,
>     connectivity from CE to CE is provided via an emulated 
> Layer-2 service
>     over the PSN, which results in the CE's appearing to be directly
>     attached to each other at Layer-2.  The WG will address 
> two specific
>     types of IP-only L2VPN:
> 
>     a) Those with Attachment Circuits (ACs) that use the same Layer 2
>     framing at all attachment points in the same L2VPN; and,
> 
>     b) Those with ACs that use different Layer 2 framing at various
>     attachment points in the same L2VPN. For (b), 
> inter-working between
>     link-layers is strictly out of scope beyond that which is 
> minimally
>     necessary to ensure that IP packets are transported from 
> an AC of one
>     type, across the IP or MPLS-enabled IP PSN, and to an AC 
> of another
>     type in as transparent a manner as possible to the CEs on 
> both sides
>     of the service.
> 
> VPLS and VPWS operate over Pseudowires (PWs) as defined by 
> the PWE3 WG.
> As with a single PW, an L2VPN emulates a "native" service 
> over a PSN that is reasonably faithful to, but may not be 
> entirely indistinguishable from, the native service itself. 
> Further, following in the "edge-to- edge"
> nature of the PWs that it uses, the L2VPN WG will not define 
> any new 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 PW endpoints which make up the L2VPN.
> 
> L2VPN's 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 PE's participating in a VPLS, 
> VPWS or IP-only L2VPN as well as the membership of CE devices 
> to a specific instance of a L2VPN.
> 
> The L2VPN WG will provide extensions of existing protocols 
> that will be discussed in protocol-specific WG's.  In 
> particular, the L2VPN WG will define extensions to pseudowire 
> management (OAM) mechanisms, specifically Pseudowire Virtual 
> Circuit Connectivity Verification (VCCV), for VPLS.  Those 
> VCCV extensions will be reviewed by PWE3 to ensure they are 
> inline with the overall design/architecture of VCCV.
> 
> The L2VPN WG will not define new encapsulations, control 
> (set-up, configuration, maintenance or tear-down), or 
> resiliency mechanisms specifically related to pseudowires, 
> because those must be defined by the
> PWE3 WG.  Furthermore, the L2VPN WG will not define protocol 
> inter- working between a VPLS or VPWS and native 
> service-layer control, OAM or or resiliency mechanisms, as 
> those will be defined by the PWE3 WG.  On the other hand, the 
> L2VPN WG will define how to operate native service- layer 
> control, OAM or resiliency mechanisms on top of a VPLS or 
> VPWS service.
> 
> The L2VPN WG scope includes the following:
> 
> 1. Discovery of PE's participating in a Layer-2 VPN and the associated
>     topology required for connectivity of the VPLS or VPWS service.
> 
> 2. Signaling of information related to the discovery and membership of
>     PE's 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.  Once those requirements
are
>     reviewed by the L2VPN WG, they should be provided to the PWE3 WG
to
>     derive solutions.
> 
> 3. MIB's for Layer-2 VPN solutions.
> 
> 4. Specification of requirements and framework that will 
> define Operations Administration and Management (OAM) procedures for
VPLS 
> and VPWS VPN's, related to the operation of VPLS and VPWS VPN's over 
> IP/MPLS PSN's. In addition, the L2VPN WG will define OAM solutions for

> VPLS and VPWS VPN's.
> 
> 5. Mechanisms to permit optimization of multicast data traffic within
>     a VPLS or VPWS VPN over an IP/MPLS PSN.
> 
> 6. Improved service convergence for multi-homed CE's to VPLS PE's.
>     Specifically, upon failure of a primary path from a CE to VPLS PE,
>     initiate a rapid switch-over to an alternate path.  If required,
>     interactions with native service-layer resiliency mechanisms will
be
>     provided via solutions from other IETF WG's such as PWE3.
> 
> 7. Enhancements to increase the scalability of the Forwarding 
> Database of VPLS PE nodes.
> 
> 8. Definition of requirements and solutions for Inter-AS VPLS and VPWS
>     services.
> 
> The L2VPN WG currently works on the following tasks:
> 
> - Define MIB's appropriate for each type of Layer-2 VPN.
> 
> - Specification of Operations Administration and Management (OAM)
>    mechanisms for VPLS, VPWS and IP-only VPN's.
> 
> - Specification of procedures to permit optimization of L2VPN 
> multicast
>    data traffic within the PSN.
> 
> - Define enhancements to increase scalability of VPLS PE nodes, to
>    provide aggregation of learned customer MAC addresses at VPLS PE's.
> 
> - Identify requirements for multi-homing of CE's to VPLS PE's.
>    elements.  Based on these requirements, define solutions 
> for achieving
>    fast convergence after a switchover to an alternate path, 
> for example
>    through optimized MAC flushing within a VPLS domain.
> 
> - Identify requirements for Inter-AS VPLS and VPWS services.  Define
>    Inter-AS enhancements to VPLS and VPWS based on these requirements.
> 
> Where necessary, the WG will coordinate its activities with 
> IEEE 802.1.
> 
> Goals and Milestones:
> 
> Done   Submit L2 requirements to IESG for publication as 
> Informational  
> RFC
> Done   Identify VPLS and VPWS solutions for the WG
> Done   Submit L2 framework to IESG for publication as 
> Informational RFC
> Done   Submit VPLS solution documents to IESG
> Done   Submit VPWS solution documents to IESG
> Done   Submit an I-D on OAM requirements for VPLS
> Done   Submit an I-D on OAM requirements for VPWS
> Done   Submit an I-D describing MIB for VPLS
> Done   Submit an I-D describing MIB for VPWS
> 
> Mar 2008    Submit IP-only L2VPN solution documents to IESG
> 
> Nov 2008    Submit MAC learning optimization solutions for 
> VPLS to IESG
> 
> Nov 2008    Submit multicast optimization solutions for VPLS to IESG
> 
> Mar 2009    Submit I-D on Virtual Private Multicast Service (VPMS)
>              requirements to IESG
> 
> Mar 2009    Submit OAM solutions for VPWS to IESG
> Mar 2009    Submit OAM solutions for VPLS to IESG
> Mar 2009    Submit OAM solutions for IP-only L2VPN to IESG
> 
> Jul 2009    Submit MIB for VPLS to IESG
> Jul 2009    Submit MIB for VPWS to IESG
> Jul 2009    Submit MIB for IP-only L2VPN to IESG
> 
> Nov 2009    Submit Auto-Discovery solution for VPMS to IESG
> 
> Nov 2009    Submit scalability solutions for VPLS 
> Control-Plane to IESG
> Nov 2009    Submit scalability solutions for VPLS Data-Plane to IESG
> 
> Jul 2010    Submit VPLS service convergence improvement solutions to  
> IESG
> 
> Jul 2010    Submit VPLS multi-homing solutions to IESG
> 
> Jul 2010    Submit Inter-AS VPLS and VPWS solutions to IESG
>

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Tue, 1 Apr 2008 11:50:41 -0700

Shane,

Please note the following comments regarding the re-chartering.

i) "L2VPN's will make use of existing IETF specified mechanisms unless
there are technical reasons why the existing mechanisms are insufficient
or unnecessary."

AS> This statement needs further clarification. I would suggest the
following text: "L2VPN solutions will make use of existing IETF PWs and
PSN specified mechanisms for providing L2VPN services unless there are
technical reasons why the existing mechanisms are insufficient or
unnecessary. Furthermore, L2VPN solutions will make use of native
service mechanisms when applicable for providing L2VPN services - e.g.,
use of Ethernet OAM for monitoring Ethernet native service.

ii) "The L2VPN WG will provide extensions of existing protocols that
will be discussed in protocol-specific WG's.  In particular, the L2VPN
WG will define extensions to pseudowire management (OAM) mechanisms,
specifically Pseudowire Virtual Circuit Connectivity Verification
(VCCV), for VPLS.  Those VCCV extensions will be reviewed by PWE3 to
ensure they are inline with the overall design/architecture of VCCV."

AS> This statement already assumes that VCCV extensions are needed for
VPLS which is not the case. I would prefer to either remove 2nd and 3rd
sentences from the above para. If we want to keep these sentences, then
we need to change "will" to "may" in 2nd sentence.

iii) "Furthermore, the L2VPN WG will not define protocol inter- working
between a VPLS or VPWS and native service-layer control, OAM or
resiliency mechanisms, as those will be defined by the PWE3 WG.  On the
other hand, the L2VPN WG will define how to operate native service-
layer control, OAM or resiliency mechanisms on top of a VPLS or VPWS
service."

AS> This statement needs to be refined to indicate that the interworking
between the native service-layer and its associated PW for the purpose
of control, OAM, or resiliency mechanisms, shall be defined by the PWE3
WG. However, the interworking between the native service-layer and the
VPN service, associated with a group of PWs and their forwarding tables,
will be defined by the L2VPN WG when needed.

iv) "5. Mechanisms to permit optimization of multicast data traffic
within
    a VPLS or VPWS VPN over an IP/MPLS PSN."

AS> mcast optimization should only be for VPLS based on VPWS service
definition.

v) "6. Improved service convergence for multi-homed CE's to VPLS PE's.
    Specifically, upon failure of a primary path from a CE to VPLS PE,
    initiate a rapid switch-over to an alternate path.  If required,
    interactions with native service-layer resiliency mechanisms will be
    provided via solutions from other IETF WG's such as PWE3."

AS> We should create another bullet to include multi-homing between two
or more VPLS networks.

vi) "7. Enhancements to increase the scalability of the Forwarding
Database of
    VPLS PE nodes."

AS> I would prefer a more explicit language with respect to scalability
such as "scalability of customer MAC addresses and number of PW"

vii) "- Define enhancements to increase scalability of VPLS PE nodes, to
   provide aggregation of learned customer MAC addresses at VPLS PE's."

AS> should be changed to " Define enhancements to increase scalability
of VPLS PE nodes, to
   provide aggregation of learned customer MAC addresses and to reduce
number of PWs at VPLS PE's."

Regards,
Ali

> Sent: Monday, March 31, 2008 11:46 AM
> To: [email-masked]
> Subject: Re: L2VPN WG (Re-)charter
> 
> Hi Folks,
> 
> It's been just over two weeks and we haven't heard any 
> support for or comments on the suggested charter below.  This 
> is just a gentle reminder to speak up in order that 
> current/in-flight and future projects aren't delayed or dropped.
> 
> -shane
> 
> 
> Shane Amante wrote:
> > Hi,
> > 
> Philadelphia, below 
> > is a proposed draft of a new charter for the L2VPN WG.  
> Included are 
> > the following new items:
> > - Multicast
> > - Scalability
> changes to the 
> > WG mailing list.  If you believe the new charter (below) is fine 
> > "as-is", then please indicate your support to the WG 
> mailing list, as well.
> > 
> > As such, let me propose that we wrap-up discussion and 
> gauge (rough) 
> > consensus by Friday, April 25, 1700 MDT (UTC -6), which is a little 
> > over
> > 1 month from now.
> > 
> > Thanks,
> > 
> > -shane & Vach
> > 
> > ---cut here---
> > 
> specifying a 
> > limited number of solutions for supporting provider-provisioned 
> > Layer-2 Virtual Private Networks (L2VPNs).  Layer-2 VPN's 
> comprise the following:
> > 
> >    point-to-point connectivity for a variety of link 
> layers, including
> MPLS-enabled IP
> >    Layer-2 frames containing IP data packets, either IPv4 
> or IPv6, are de-
> >    since no routing protocol operates between the PE and 
> CE; furthermore,
> >    link-layers is strictly out of scope beyond that which 
> is minimally
> >    type in as transparent a manner as possible to the CEs 
> on both sides
> >    of the service.
> > 
> over a PSN 
> > that is reasonably faithful to, but may not be entirely 
> > indistinguishable from, the native service itself. Further, 
> following in the "edge-to-edge"
> > nature of the PWs that it uses, the L2VPN WG will not 
> define any new 
> > 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 PW endpoints 
> which make up the L2VPN.
> > 
> > L2VPN's 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 PE's participating in a VPLS, VPWS or IP-only 
> L2VPN as 
> > well as the membership of CE devices to a specific instance 
> of a L2VPN.
> > 
> that will 
> > be discussed in protocol-specific WG's.  In particular, the 
> L2VPN WG 
> > will define extensions to pseudowire management (OAM) mechanisms, 
> > specifically Pseudowire Virtual Circuit Connectivity Verification 
> > (VCCV), for VPLS.  Those VCCV extensions will be reviewed 
> by PWE3 to 
> > ensure they are inline with the overall design/architecture of VCCV.
> > 
> > The L2VPN WG will not define new encapsulations, control (set-up, 
> > configuration, maintenance or tear-down), or resiliency mechanisms 
> > specifically related to pseudowires, because those must be 
> defined by 
> > the
> > PWE3 WG.  Furthermore, the L2VPN WG will not define protocol inter- 
> > working between a VPLS or VPWS and native service-layer 
> control, OAM 
> > or or resiliency mechanisms, as those will be defined by 
> the PWE3 WG.  
> > On the other hand, the L2VPN WG will define how to operate native 
> > service- layer control, OAM or resiliency mechanisms on top 
> of a VPLS 
> > or VPWS service.
> > 
> >    management procedures, or define requirements for 
> extensions of PWE3
> >    protocols to suit the needs of an L2VPN.  Once those 
> requirements are
> >    reviewed by the L2VPN WG, they should be provided to the 
> PWE3 WG to
> >    derive solutions.
> > 
> define Operations
> >    Administration and Management (OAM) procedures for VPLS 
> and VPWS VPN's,
> >    related to the operation of VPLS and VPWS VPN's over 
> IP/MPLS PSN's.
> >    In addition, the L2VPN WG will define OAM solutions for 
> VPLS and VPWS
> >    VPN's.
> > 
> > 7. Enhancements to increase the scalability of the 
> Forwarding Database of
> >    VPLS PE nodes.
> > 
> > - Specification of procedures to permit optimization of 
> L2VPN multicast
> > Jul 2010    Submit VPLS service convergence improvement 
> solutions to IESG
> >

---

From: Shane Amante <[email-masked]>
Date: Wed, 02 Apr 2008 15:05:52 -0600

Hi Loa,

I couldn't find a good place to respond to some of the items you raised, 
so I'm responding directly to those here.  Please see below.

Loa Andersson wrote:
> Shane,
> 
> just a few smaller issues
> 
> - for discovery specifiactions
>   --  does this include automated Inter-AS discovery

I'll follow-up on this in the response to Inter-AS comments.

>   --  to discover PEs that participates in a particular
>       VPMS, how different is this from discovery for PEs
>       participating in a VPLS?

It's my understanding that VPMS Auto-Discovery should be very similar to 
what is already specified in draft-ietf-l2vpn-vpls-mcast-03.  I would 
refer you to Section 4.2, "Auto-Discovery and Signaling", of 
draft-raggarwa-l2vpn-p2mp-pw-00 for more details.

>   -- how different is L2VPN discovery from L3VPN discovery?

Is this question also related to multicast?  If so, then in my 
understanding the procedures are very much the same.  Again, I'd refer 
you to draft-ietf-l2vpn-vpls-mcast-03 for more details on multicast and 
Auto-Discovery.

> - I would split the
>   milestone into two different mailstones

I'll follow-up on this in the response to Inter-AS comments.

> - I'm a bit uncertain about whether there are one or two multi-homing
>   scenarios in the text
>   -- VPLS using multi-homed CEs
>   -- multi-homed VPLS solutions

I've responded to this in the 'Service Convergence' comments.

Thanks,

-shane

---

From: Luca Martini <[email-masked]>
Date: Mon, 07 Apr 2008 08:50:57 -0600

Shane,

The charter looks good , but I would like to propose the following small 
change:

OLD:
The L2VPN WG will provide extensions of existing protocols that will be
discussed in protocol-specific WG's.  In particular, the L2VPN WG
will define extensions to pseudowire management (OAM) mechanisms,
specifically Pseudowire Virtual Circuit Connectivity Verification (VCCV),
for VPLS.  Those VCCV extensions will be reviewed by PWE3 to ensure they
are inline with the overall design/architecture of VCCV.

NEW:
The L2VPN WG will provide extensions of existing protocols that will be
discussed in protocol-specific WG's.  In particular, the L2VPN WG
will define extensions to pseudowire management (OAM) mechanisms,
specifically Pseudowire Virtual Circuit Connectivity Verification (VCCV),
for VPLS.  Those VCCV extensions will be reviewed by PWE3 to ensure they
are inline with the overall design/architecture of VCCV and MPLS.
                                                                         
                  ^^^^^^^^^
            
The concern here is that in order to do some convoluted OAM method, 
somebody will come along, and try to do something that is not in the 
MPLS architecture.

Thanks.
Luca

Shane Amante wrote:
> Hi Folks,
>
> It's been just over two weeks and we haven't heard any support for or 
> comments on the suggested charter below.  This is just a gentle 
> reminder to speak up in order that current/in-flight and future 
> projects aren't delayed or dropped.
>
> -shane
>
>
> Shane Amante wrote:
>> Hi,
>>
>> As mentioned during the WG meeting at IETF 71 in Philadelphia, below 
>> is a proposed draft of a new charter for the L2VPN WG.  Included are 
>> the following new items:
>> - Multicast
>> - Scalability
>> Please take a look at the entire text, including suggested dates for 
>> deliverables & milestones.
>>
>> Please send any questions, clarifications or suggested changes to the 
>> "as-is", then please indicate your support to the WG mailing list, as 
>> well.
>>
>> We would like to set a time-limit for discussion and agreement of the 
>> As such, let me propose that we wrap-up discussion and gauge (rough) 
>> over 1 month from now.
>> 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).  Layer-2 VPN's comprise the 
>> following:
>>
>> 1. Virtual Private LAN Service (VPLS) -- A Layer-2 service that emulates
>>    an Ethernet (V)LAN across an IP or an MPLS-enabled IP 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
>>    service over an IP or MPLS-enabled PSN.  This service is similar to
>>    Attachment Circuits, including Frame Relay, ATM, Ethernet, PPP, etc.
>>    IP-only L2VPN's are different from both VPLS and VPWS because unicast
>>    Layer-2 frames containing IP data packets, either IPv4 or IPv6, 
>> are de-
>>    encapsulated leaving only the IP data packet to be transmitted over
>>    the PSN.  An IP-only L2VPN service also differs from L3VPN service,
>>    connectivity from CE to CE is provided via an emulated Layer-2 
>> service
>>    attached to each other at Layer-2.  The WG will address two specific
>>    types of IP-only L2VPN:
>>
>>    attachment points in the same L2VPN. For (b), inter-working between
>>    link-layers is strictly out of scope beyond that which is minimally
>>    necessary to ensure that IP packets are transported from an AC of one
>>    type, across the IP or MPLS-enabled IP PSN, and to an AC of another
>>    type in as transparent a manner as possible to the CEs on both sides
>>    of the service.
>>
>> VPLS and VPWS operate over Pseudowires (PWs) as defined by the PWE3 WG.
>> As with a single PW, an L2VPN emulates a "native" service over a PSN 
>> that
>> is reasonably faithful to, but may not be entirely indistinguishable
>> from, the native service itself. Further, following in the 
>> "edge-to-edge"
>> nature of the PWs that it uses, the L2VPN WG will not define any new
>> 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 PW endpoints which make up the L2VPN.
>>
>> L2VPN's will make use of existing IETF specified mechanisms unless there
>> are technical reasons why the existing mechanisms are insufficient or
>> unnecessary.
>>
>> membership of PE's participating in a VPLS, VPWS or IP-only L2VPN as 
>> well
>> as the membership of CE devices to a specific instance of a L2VPN.
>>
>> The L2VPN WG will provide extensions of existing protocols that will be
>> discussed in protocol-specific WG's.  In particular, the L2VPN WG
>> (VCCV),
>> for VPLS.  Those VCCV extensions will be reviewed by PWE3 to ensure they
>> are inline with the overall design/architecture of VCCV.
>>
>> specifically related to pseudowires, because those must be defined by 
>> the
>> working between a VPLS or VPWS and native service-layer control, OAM or
>> or resiliency mechanisms, as those will be defined by the PWE3 WG.  On
>> the other hand, the L2VPN WG will define how to operate native service-
>> service.
>>    management procedures, or define requirements for extensions of PWE3
>>    protocols to suit the needs of an L2VPN.  Once those requirements are
>>    reviewed by the L2VPN WG, they should be provided to the PWE3 WG to
>>    derive solutions.
>>
>> 4. Specification of requirements and framework that will define 
>> Operations
>>    Administration and Management (OAM) procedures for VPLS and VPWS 
>> VPN's,
>>    related to the operation of VPLS and VPWS VPN's over IP/MPLS PSN's.
>>    In addition, the L2VPN WG will define OAM solutions for VPLS and VPWS
>>    VPN's.
>>
>> - Specification of procedures to permit optimization of L2VPN multicast
>>   elements.  Based on these requirements, define solutions for achieving
>> Where necessary, the WG will coordinate its activities with IEEE 802.1.
>>
>> Goals and Milestones:
>>
>> Done   Submit L2 framework to IESG for publication as Informational RFC

---

From: Shane Amante <[email-masked]>
Date: Mon, 7 Apr 2008 23:24:17 -0600

Hi Luca,

OK.  I will add "and MPLS" to the end of that paragraph.

-shane

On Apr 7, 2008, at 8:50 AM, Luca Martini wrote:
> Shane,
>
> The charter looks good , but I would like to propose the following  
> small change:
>
> OLD:
>                                                                                         ^ 
> ^^^^^^^^
>           The concern here is that in order to do some convoluted  
> OAM method, somebody will come along, and try to do something that  
> is not in the MPLS architecture.
>
> Thanks.
> Luca
>
>
> Shane Amante wrote:
>> Hi Folks,
>>
>> It's been just over two weeks and we haven't heard any support for  
>> or comments on the suggested charter below.  This is just a gentle  
>>> As mentioned during the WG meeting at IETF 71 in Philadelphia,  
>>> below is a proposed draft of a new charter for the L2VPN WG.   
>>> Included are the following new items:
>>> - Multicast
>>> - Scalability
>>> Please take a look at the entire text, including suggested dates  
>>> for deliverables & milestones.
>>>
>>> Please send any questions, clarifications or suggested changes to  
>>> the WG mailing list.  If you believe the new charter (below) is  
>>> fine "as-is", then please indicate your support to the WG mailing  
>>> list, as well.
>>>
>>> We would like to set a time-limit for discussion and agreement of  
>>> the new charter, in order that we can get back to the business at  
>>> hand.  As such, let me propose that we wrap-up discussion and  
>>> gauge (rough) consensus by Friday, April 25, 1700 MDT (UTC -6),  
>>> Layer-2
>>>   Frame Relay, ATM, Ethernet, PPP, etc., across an IP or MPLS- 
>>> enabled IP
>>>   PSN.
>>>
>>> As with a single PW, an L2VPN emulates a "native" service over a  
>>> PSN that
>>> from, the native service itself. Further, following in the "edge- 
>>> to-edge"
>>> necessary
>>> there
>>> membership of PE's participating in a VPLS, VPWS or IP-only L2VPN  
>>> as well
>>> specifically related to pseudowires, because those must be defined  
>>> by the
>>> Jul 2010    Submit VPLS service convergence improvement solutions  
>>> to IESG
>>>