Last Modified: 2003-09-30
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 L2 VPNs--L2 service across an IP and an MPLS-enabled IP network, allowing standard IP devices to communicate with each other as if they were connected to a common LAN segment or a point- to-point circuit.
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 | |
| Oct 03 | Submit L2 framework to IESG for publication as Informational RFC | |
| Done | Identify VPLS and VPWS solutions for the WG | |
| 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 |
----====================================== ================================== Minutes L2VPN WG November 12, 1530-1730 Scribe: Kenneth Sundell <ksundell@nortelnetworks.com> Scribe: Alia Atlas <aatlas@avici.com> L2VPN wg agenda IETF58 - Minneapolis 1. Agenda bashing Loa: There is a custom in the IETF not to use two chairs from same company Rick to stay until next meeting (Rick and Vach at the same company). No objections. Loa went through the agenda No changes to agenda 2. WG Status, Vach Kompella Milestones: At risk: Aug 03 Submit an I-D describing MIB for VPLS Aug 03 Submit an I-D describing MIB for VPWS Vach: Submit Enterprise MIBs as jump start Aug 03 Submit an I-D on OAM for VPLS Aug 03 Submit an I-D on OAM for VPWS Need to follow the OaM development happening in the MPLS WG closely before persuing the work Need more participation Oct 03 Submit L2 requirements to IESG for publication as Informational RFC Into last call soon (some security considerations issues) Oct 03 Submit L2 framework to IESG for publication as Informational RFC Ready to go too Completed or threreabouts Done Identify VPLS and VPWS solutions for the WG Dec 03 Submit VPLS solution documents to IESG Dec 03 Submit VPWS solution documents to IESG A last call warning is issued to find traction. Andy Malis: Send it to the list Looking good: Jan 04 Submit IP-only L2VPN solution documents to IESG Seems Achievable Feb 04 Submit MIB for VPLS to IESG Feb 04 Submit MIB for VPWS to IESG Achievable? Working group documents a: draft-ietf-l2vpn-signaling-00.txt To be presented. b: draft-ietf-l2vpn-requirements-00.txt Waiting for Russ Housley's comments (sec advisor) otherwise ready to go c: draft-ietf-l2vpn-l2-framework-03.txt Eric Rosen d: draft-ietf-l2vpn-vpls-bgp-00.txt Kireeti Kompella e: draft-ietf-ppvpn-vpls-ldp-01.txt Need to rename draft from *ppvpn* to *l2vpn* f: draft-shah-ppvpn-ipls-02.txt Will be published as a wg doc g: draft-heinanen-radius-l2tp-vpls-00.txt (will be published as a wg doc) Mark Townsley picked up the work after Juha Heinanen, the document was already approved as a working group document (not issued as that this time). Mark Townsley: Will resend the document with wg status, but solicits comments on the list before doing do. h: draft-heinanen-radius-pe-discovery-04.txt (will be published as a wg doc) Should have wg status. Greg Weber wasn't present, but Mark said that the same procedure will be applied for this work as well. 3. Detecting and Reacting to Failures of the Full Mesh in IPLS and VPLS draft-rosen-l2vpn-mesh-failure-00.txt Eric Rosen Assuming that full mesh of PW's is present, if assuption fails, blackholes can occur. Failure modes: - data plane connectivity - PW state at edge - auto-discovery failure or configuration mismatch Bad ideas for detecting failures - local information (detection only) - mismatch between operational PWs and discovered endpoints - PW operational status changes - global information (resilience) - PWs as overlay network, Spanning tree - PWs as overlay network, run routing - but don't really want to run a routing protocol or spanning tree - overhead costs Not so quite bad idea - global information (detection only) - each edge tells every other edge "here are the PW endpoints i can talk to" - get global info, from each edge, set of other edges that can be seen - any edge not universally seen is removed from the mesh What is the reaction after constructing this information? - log the failure - or fix the failure through re-routing - most important is to get the detection part Is this worth pursuing? Yakov: Does it need to be new protocol to existing ones or done by nms (mibs) Vach: The approach is to detect, fixing things is another question Eric: By NMS do you mean some mgmt station or from each PE Yakov: From mgmt station Vach: Not necessarily need protocol, but we don't want SNMP gets between PEs Eric: In practice, using NMS to detect dynamic problems hasn't historically worked well. Yakov: Have traps when PW goes up and when goes down, so can check adjacency. Vach: If just wanting to detect, then MIB could be enough. If more than that. Eric: Be careful. One could build a tool to look at the MIB info to determine this. How happy are people with depending on NMS yet? Yakov: If all the protocol is to do is detection, then need operator action using nms to fix problem Vach: we haven't determined the scope of the problem yet, so maybe detection is sufficient Liam Casey: The detection time has to be fast, comparable to control plane. Agree to pursuing the work. Propose to do it in the control plane as opposed to the management plane for default border repair. Suggest that failure mode is "if one router can't be reached by another, then no router should be allowed to reach." Jack Lukaski/Lewkowski: Do not reinvent the weel. use existing protocols done elsewhere in this domain (SONET, ATM F4/F5 AIS). Separate in-band from out-of-band. Vach: Asking the WG if this is an important problem to solve? Yes: a fair number of hands Opposed: None Vach: The consensus to be verified on the list Eric: Had already raised on mailing list, said wasn't important and was beaten up. But dead silence now. 4. The "generalized FEC ID" in the PWE3 control messages, as discussed in draft-ietf-pwe3-control-protocol-04.txt draft-ietf-l2vpn-signaling-00.txt Eric Rosen PWE3 control protocol draft (in lc) define it Superset of signaling paradigm in VPLS-LDP spec (L2VPN WG draft) Eric: Can we all agree to use it? It has been sparsely discussed on the mailing list by a few persons. There do not seem to be any substantive technical issues with it Vach: Think we can close on this but want to hear others opinions. Naming of a VPLS is going to change substantially. Not many are involved in the discussion (even if people seem to go off and implement it) Have a couple of issues: most important is to drop the distributed VPLS part, since nobody is doing that. Eric: Some people in WG are interested in distributed VPLS. Inter-provider case may need it. Friends from Nortel should jump up. (Aside from Vach: Hamid did come to chairs and ask that it should be retained). Rick: Input from VPLS implementers? No response Eric: We got so tired doing the framework and requirements that at this point nobody cares..? Loa: Hmmm no responses. This is how we handle it, three weeks on the mailing list, no comments and we go with the solution. End of session |