Last Modified: 2004-07-29
This working group is responsible for defining and specifying a limited number of solutions for supporting provider-provisioned layer-2 virtual private networks (L2VPNs).
The WG is responsible for standardization of the following solutions:
1. Virtual Private LAN Service (VPLS)--L2 service that emulates LAN across an IP and an MPLS-enabled IP network, allowing standard Ethernet devices communicate with each other as if they were connected to a common LAN segment. 2. Virtual Private Wire Service (VPWS)--L2 service that provides L2 point-to-point connectivity (e.g. Frame Relay DLCI, ATM VPI/VCI, point-to-point Ethernet) across an IP and an MPLS-enabled IP network.
3. IP-only VPNs -- An L2 service across an IP and MPLS-enabled IP network, allowing standard IP devices to communicate with each other as if they were connected to a common LAN or with some mesh of point-to-point circuits (not necessarily fully meshed). The WG will address both of the following cases: - the customer attachment uses the same L2 protocol at all attachment points in the L2VPN. - the customer attachment uses different L2 protocols at the attachment points in the L2VPN. This case is intended to address the needs of service providers who may start out with a single L2 protocol at attachment points, but wish to incrementally upgrade individual attachment points over time to newer technologies. This is a restricted form of "interworking" that is limited to providing the facilities necessary to carry IP over the L2VPN; general L2 interworking is not in scope.
The WG will address intra-AS scenarios only at this point (other scenarios will be considered for inclusion in the updated charter when the current one is completed.) As a general rule, the WG will not create new protocols, but will provide functional requirements for extensions of the existing protocols that will be discussed in the protocol-specific WGs. As a specific example, this WG will not define new encapsulation mechanism, but will use those defined in the PWE3 WG. L2VPN WG will review proposed protocol extensions for L2VPNs before they are recommended to appropriate protocol-specific WGs.
The WG will work on the following items. Adding new work items will require rechartering.
1. Discovery of PEs participating in L2 service, and topology of required connectivity
2. Signaling of l2vpn related information for the purpose of setup and maintenance of l2vpn circuits. As much as possible PWE3 signaling procedures should be used
3. Solution documents (providing the framework for a specific solution, should include info on how discovery, signaling, and encaps work together, include security, AS as a separate document)
4. MIBs 5. L2VPN-specific OAM extensions--extensions to existing OAM solutions for VPLS, VPWS, and IP-only L2VPNs.
Where necessary, the WG will coordinate its activities with IEEE 802.1
|Aug 03||Submit an I-D describing MIB for VPLS|
|Aug 03||Submit an I-D describing MIB for VPWS|
|Aug 03||Submit an I-D on OAM for VPLS|
|Aug 03||Submit an I-D on OAM for VPWS|
|Oct 03||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|
|Dec 03||Submit VPLS solution documents to IESG|
|Dec 03||Submit VPWS solution documents to IESG|
|Jan 04||Submit IP-only L2VPN solution documents to IESG|
|Feb 04||Submit MIB for VPLS to IESG|
|Feb 04||Submit MIB for VPWS to IESG|
|Mar 04||Submit OAM for VPWS to IESG|
|Mar 04||Submit OAM for VPLS to IESG|
|Apr 04||Submit OAM for IP L2VPN to IESG|
L2 VPN meeting notes
8/3/2004 San Diego
Chairs: Vach Kompella, Loa Andersson, Rick Wilder
i. VPLS-BGP-01.txt: requested the idr WG to review but they havenít yet come back to us
ii. VPLS-LDP-01.txt: WG last call on hold, authors will get back with an updated version ďend of the weekĒ.
†† Kireeti: Will this be reviewed by MPLS WG or is the VPLS-BGP a special case in needing review by IDR WG?† Loa: its special treatment for anything that touches BGP.
iii. Signaling-00.txt: Rosen unchanged.† Loa: Author may ask for WG last call via the email list.
i. clarified address learning procedures for PE that is connected to Ethernet
ii. Clarified IPCP participation procedure
i. organization to improve idea flow
ii. references to the L2VPN Requirements document.
ii. Recovery no per VC/vp config at ATM/psn boundary
iii. Minimal to no change to ATM software
i. Addressing is key
ii. PWE identifiers: 2 identifiers for circuit: SAI & TAI, structure of SAI, TAI: AGI & AII
iii. Mismatched identifiers: ATM vs pwe3
iv. Described NSAP format
v. Described how to map identifiers
vi. MPLS/ATM interface: outside scope, but FYI.† Interface between ATM and MPLS could be pnni or other
vii. ATM setup; PAE to ME (ATM to MPLS) direction, ME terminates PNNI and initiate MPLS signaling as needed
viii. MPLS setup: MPE to ME:
i. If you have BFD, use BFD ÖÖÖ..
i. Discussion of defect loop emulation model
ii. Action over an ATM AC as a result of a PE receiving a PW defect indication for a defect in the PW transmit direction
iii. Check L2TPv3
i. Address open issues
ii. Get more feedback on email list
iii. See is this can become a WG document.
1. Node discovery
2. Service discovery
3. Service signaling
4. Tunnel signaling
ii. Meta issues
1. Should node/service discovery be combined
2. Want to minimize number of issues
i. Issues: scope of type 10 lsas
ii. Require another draft for IS-IS
iii. Canít work across areas
i. Some SPs donít use hop-by-hop LDP and may be resistant of using LDP
1. involve major changes to LDP
2. signaling via proxy may not improve scaling relative to LDP
i. Some SPs donít want to use BGP
i. Adds an additional protocol
ii. Doesnít inform PEs when PEs are added/deleted