Last Modified: 2005-07-13
| 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 |
|
IETF 63: Layer 2 Virtual Private Network WG (l2vpn) Meeting Minutes
----------------------------------------------------------------------- Wednesday, August 3, 1030-1230 ============================== Chairs: Vach Kompella <vkompella@timetra.com> Shane Amante <shane@castlepoint.net> ----------------------------------------------------------------------- 1) Agenda Update ----------------------------------------------------------------------- Two presentations cancelled: + Florin Balus' presentation cancelled, because discussion on MS-PW occurred the day before in PWE3. + Greg Weber's presentation on "Using RADIUS for PE-Based VPN Discovery" (draft-ietf-l2vpn-radius-pe-discovery-01.txt) cancelled, due to WG scheduling conflict. ----------------------------------------------------------------------- 2) WG Document Status (Vach) ----------------------------------------------------------------------- - Documents Status + draft-ietf-l2vpn-arp-mediation-02 (ARP Mediation): There are a few comments that are being addressed. MPLS WG being asked to review code points and changes to LDP. + draft-ietf-ipls-02 (IPLS): There are a lot of edits so working group last call is being delayed. Vach asked for more review from the working group. + draft-ietf-l2vpn-signalling-04 (L2VPN Signaling): Close to WG last call, however some issues raised in PWE3 may require some changes to the draft so WG will wait to see what happens in PWE3. - Charter Status + Good progress, or almost done with most items in charter. + OAM and MIBs are significant bodies of work that still need work. + Volunteers for work on MIB are requested. - ITU Liason Statement + 36 from ITU-T SG13 Y.ethoam needs to be reviewed. + Action is to read, evaluate and respond; asked for volunteers to see Vach or Shane afterwards to review and respond. - Loa Anderson made comment that VPLS BGP has progressed into the IANA for the code point allocation, and that they are ready to assign the code point. ----------------------------------------------------------------------- 3) Update: IP-Only LAN Service (IPLS) draft-ietf-l2vpn-ipls-02.txt Himanshu Shah ----------------------------------------------------------------------- - IPLS changes: + multicast mp2p PW type changes from IPLayer2Transport to Ethernet + All ARP and multicast frames are sent over multicast PW with Ethernet headers + A copy of ARP and link local multicast packets are sent to control plane for local CE discovery + addressed other comments from the list - IPLS simplified as a result - IPLS pending changes reviewed + Proposed IANA type and status code points to use. + Code points not yet in the draft + Will send email to MPLS WG to review code points. - Asked for a final call on IPLS draft - Show of hands indicated not too many people read a draft, Vach made a call for people to read a draft and have a discussion on the mailing list. Questions raised at the microphone: - Bernard Tuy: asked about support of IPv6 in this draft. - Himanshu: This was not supported in this version of the draft. - Bernard: Why is this not supported now? It is strange to have this work being done without IPv6 supported now. - Himanshu: v6 is planned, but wanted to get IPv4 out first. - Vach: Asked Mark Townsley if we can wait on IPv6 or if we have to address it right away? - Mark: We should take it to the list. - Himanshu: emphasized again that the goal is to get IPv4 done right away, IPv6 later. - Janusz: Should not go for a protocol without IPv6 consideration, at least a section on v6 is required. - Andy Malice: asked for IPv6 supporters to offer text. - George Swallow: commented that lacking IPv6 in the document may cause the work to be rejected. - Mark: agreed that people who want IPv6 need to provide the text. ----------------------------------------------------------------------- 4) Update: ARP Mediation for IP Interworking of Layer 2 VPN draft-ietf-l2vpn-arp-mediation-02.txt Himanshu Shah ----------------------------------------------------------------------- - Final call on -01 version, good support on the list. - Major comments on: PPP AC procedures, some ID nits, IP TLV etc. Presented response to those comments. - Proposed needed IANA code points, (0x096B type, 0x00000029 status) - Conclusion: + send email to MPLS WG for code points assignment review + propose to submit draft for IESG review + can do another final call for changes Vach: Let's do another final call, comments restricted to what's in the draft (specifically changes from last final call). 2 week last call will start right after this IETF. No Questions/Discussion raised at the microphone. ----------------------------------------------------------------------- 5) Provisioning Models and Endpoint Identifiers in L2VPN Signaling draft-ietf-l2vpn-signaling-04.txt Bruce Davie ----------------------------------------------------------------------- - Presented changes from last version: + Fixed distributed VPLS case + Addressed comments on the list (editorial, clarifications, bug fixes) + Clarified use of PE address in VSI identifier + Added IANA considerations section - All comments since Minneapolis were addressed, propose last call for this draft. Questions/Discussion raised at the microphone: - Mustapha Aissaoui: It will be hard to maintain this one central document and maybe it should only be informational. We have separate documents for applications, is this to become guidance RFC? - Bruce: Would like this to not just be informational but standards track, because it shows how to do interoperability between BGP and LDP. - Hamid: If intent of the draft is to be more like a solution draft with discovery, then the title should be corrected. - Bruce: Would be happy to change title. - Hamid: Is this consistent with existing documentation? - Bruce: This document is consistent with other work. Context of a signalling message (VPLS spec) does not have enough info for BGP auto-discovery, this document flushes out the details. - Vach: Do we need distributed case described here? - Bruce: The distributed case is described in draft-ietf-l2vpn-vpls-bgp-05.txt, so it seems prudent to keep it in this draft as well, lest anyone claim that the lack of distributed VPLS support is a drawback of using LDP. - Ted Seely: There is a lot of work going on to go across ASes, but there is little work being done to address how service providers honor SLAs across these services. There is nothing on the edge to actually say that it is working. Ted says that maybe the IETF should start to think how to address this. - Bruce: Not sure which working group is best to address this question. Suggested maybe we need a new Ops specific working group area? - Bruce: Are we ready to do last call on this document? - Vach took a poll of the room of who is ready for last call. Many hands went up. Room seemed to support the idea to make final changes (related to IANA code points) and then go to last call. - Mark: Do we need IANA code points to be allocated before the final call? - Bruce: My intent was not to get the code points, simply to clarify in the document that we need to obtain code points for AGI type and AII type in the FEC 129 TLV. The actual allocation can be done later (by IANA or PWE3, whoever actually has control over those fields). ----------------------------------------------------------------------- 6) LDP-based Autodiscovery for L2 Services draft-stein-ldp-auto-00.txt Yaakov Stein ----------------------------------------------------------------------- - Presentation talked about Access Network Architecture and important characteristics of that network that need to be taken into account. - Scale, simplicity of devices, combined devices (multiservice nodes), simple tree, limited BW, limited computational power, 1000s of nodes, no BGP may not be IGP, LDP for access LSP setup. - Manual configuration to join such a network would be difficult. - Basic assumptions in the draft: network element and links are relatively static, hence network discovery not a burden, services are dynamic, manual provisioning is difficult, want auto-discovery. When BGP available in core network it could be used, when LDP is only thing available then it should be used for auto-discovery. - New LDP message: JOIN Message, like label request, but only sent to nodes that are part of the VPLS instance. Vset members nodes after receiving the message start PW setup procedures to connect the new node. Questions/Discussion raised at the microphone: - Ali Sajassi: main point appears to be avoiding BGP in DSLAM's. BruceD's presentation shows how to do this without BGP, so this works. It's already taken care of by current framework. - YaakovS: Not negating other things may work, this draft proposes a simple way of doing that. - Ali: Specific autodiscovery case, very narrow, already taken care by current framework, (general enough). - YaakovS: Thinks it doesn't scale. - Kireeti: Like to see the work. Questions scalability, if the access network is simple, building LDP mesh would be challenging, how about reflectors? - YaakovS: Referenced how others have said that LDP is not that chatty. - Kireeti: we may still need something like route reflectors. - YaakovS: had not worked on this, but interested to look into idea like LDP reflectors. - Kireeti: went on to ask about using BGP if it only carries one NLRI, for auto-discovery, and how complicated that really is? - YaakovS: had not seen studies that really help resolve whether BGP or LDP is the best. - Kireeti: If all you implement is "light" BGP, the BGP requirements may be small, BGP would be fine in this case. - Vach: "Managing DSLAMS are configuration nightmare", not a feedback he has heard. - YaakovS: Depends on DSL architecture. - Vach: Still disagrees. Re: "Hierarchical model hides CEs" statement, that model not being as scalable as the one shown, is a wrong assumption. Thinks that people know how to do redundancy on RADIUS servers so a central server approach is not an issue. - YaakovS: RADIUS is one idea, but not the only one asked for. - Sasha: Who is talking to who over targeted LDP? - YaakovS: There are sessions within an access network and then between S-PEs. - Yakov Rekhter: thinks BGP processor overhead is not an issue and that the majority of boxes can run BGP. - Yaakov Stein: he would like to see a study to compare BGP to LDP. - Pedro: Algorithmically BGP is not as complex as stated. ----------------------------------------------------------------------- 7) Requirements for Multicast Support in Virtual Private LAN Services draft-kamite-l2vpn-vpls-mcast-reqts-00.txt Yuji Kamite ----------------------------------------------------------------------- - Scalability issues for multicast, need requirement documentation as a basis, the draft clarifies issues, describes requirements, guides multicast VPLS solution design. - Illustrates multicast challenges in VPLS. Issue A: Replication to non-member sites; Issue B: Replication of PWs on shared physical paths. - Presented summary of the requirements in the draft from multiple angles (General, Customer, Service Provider). - Major open questions: requirement levels, which PE-CE protocols are consulted, etc. - Next steps: enhance document with more feedback, propose as a WG document. Questions/Discussion raised at the microphone: - Rahul: Thinks this is useful work and should move forward. Also, thinks the document needs to require both solutions A and B. - Yuji: Does not want to limit scope and thinks, ideally, both solutions A and B should be addressed. - Bernard Tuy: Need to ensure IPv6 support and multicast auto-discovery and reporting of membership. - Yuji: Haven't given this any consideration yet. Feedback requested from a mailing list - Shane: polled room to see who had read the draft? A significant # of hands raised. Asked room: should this become a WG draft? Fair # of hands raised. Will take same question to list re: becoming WG draft. ----------------------------------------------------------------------- 8) Supporting IP Multicast over VPLS draft-serbest-l2vpn-vpls-mcast-03.txt Venu Hemige ----------------------------------------------------------------------- - Solving issue A from previous presentation, (multicast traffic flooded to all sites, with or without receivers). - Draft addresses building of replication state in PEs for IGMP and PIM only, PEs on cust-facing port must perform IGMP/PIM snooping, PE on PW port may learn multicast state using either IGMP/PIM snooping (no additional work, good up to medium scale deployments but does not scale above well, hence LDP). Why LDP? Already used to setup PW, reliable, will scale well. - Overview of LDP mechanism and special considerations as per draft were presented. - Next steps: + Comments please + Talk about combining with other draft (Rahul's) Questions/Discussion raised at the microphone: - Ali: Can you alleviate with PIM refresh-reduction. Have you been in touch with the work done there? - Rahul: PIM WG is in very early stages, but we have a solution now so we should use it. - George: This draft needs review by MPLS WG - Janusz: Recommend to split doc into 2 parts: IGMP/PIM in one, LDP in another - Venu: That discussion currently in progress ----------------------------------------------------------------------- 9) Multicast in VPLS - draft-raggarwa-l2vpn-vpls-mcast-01.txt Propagation of VPLS IP Multicast Group Membership Information - draft-raggarwa-l2vpn-vpls-mcast-ctrl-00.txt Rahul Aggarwal + NOTE: Rahul made one presentation, which covered both drafts. ----------------------------------------------------------------------- - Showed multiple VPLS multicast proposals, restated again the VPLS multicast limitations focus on optimizing state and not BW. - Optimizing BW and state are conflicting goals. - Tools to do that: + VPLS Auto-Discovery (use existing Auto-Discovery methods) + Allow elimination of flooding (PE-CE IGMP/PIM snooping, PE-PE reliable exchange of multicast control messages can be done with either BGP or LDP). - Presented overview of proposed solution in the drafts, overview of functional blocks for VPLS multicast, showed how various drafts address those functional blocks. - Conclusion: lots of interest, let's align drafts to follow functional decomposition, move drafts that fit (functional decomposition) already into WG docs, move others after restructuring to WG drafts. Questions/Discussion raised at the microphone: - Ali: Breaking down drafts to follow functional decomposition is a good idea. If I have bridges, and I send multicast, how does Ethernet OAM get treated? - Rahul: Haven't thought of that. - Shane (CH): Take it to the list. - Ali: Mechanism for shared tree, PE routers need to keep state need clarifications. - Rahul: There are procedures/clarifications missing in the current specs. - Ali: How close will we come to LAN Emulation? We need to be clear in the documents what the trade offs are for each document. - Rahul: Happy to include clarification, please provide specific text. - Ben Agrovitz: Glad to see we acknowledge tradoffs of the architecture. Challenge is finding the middle ground for tree sharing procedures. - Rahul: There is already a mechism in the draft. If anything is missing, happy to add it. - Shane: who has read the drafts? Good response. - Shane: should these both be WG drafts? Some responses. Will take same questions to the list. ----------------------------------------------------------------------- 10) L2VPN OAM Requirements and Framework draft-ietf-l2vpn-oam-req-frmk-03.txt Dinesh Mohan ----------------------------------------------------------------------- - Presented update on the draft, (overview of framework and requirements) - Status: + OAM framework adopted for other related work + New draft submitted - Section 7 added - IPLS OAM is FFS - input welcomed - VPWS OAM references draft-delord-pwe3-oam-application-01.txt, (goal is to avoid duplication). - Next steps: + Add VPWS OAM Reqs + Continue refining requirements on PW OAM + Other editorial updates. + Still work in progress, no intention for last call at this time. No Questions/Discussion raised at the microphone. ----------------------------------------------------------------------- 11) OAM Procedures for VPWS Interworking draft-aissaoui-l2vpn-vpws-iw-oam-03.txt Mustapha Aissaoui ----------------------------------------------------------------------- - No slides, Mustapha gave verbal update. - Planning revision by the end of August. - BFD for reverse concatenated path - Editorial changes - Had a good show of hands on this as a WG doc, but no response on the list. No Questions/Discussion raised at the microphone. ----------------------------------------------------------------------- 12) VPLS Interoperability with CE Bridges draft-sajassi-l2vpn-vpls-bridge-interop-01.txt Ali Sajassi ----------------------------------------------------------------------- - Updates from last draft + First presented in IETF61 + Comments/discussions on a mailing list + Almost all discussions on clarification - Main objectives: + Identity interop issues between VPLS and 802.1D bridges. - Presented recap of interop issues: + CE Bridge Protocol handling + Customer network topology changes + PE redundancy + MAC address scaling + Partial-mesh PWs + Muticast + Interop with 802.1ad Provider Bridges - Next steps: + What's the consensus on the draft? + What areas need further clarification? Questions/Discussion raised at the microphone: - Vach: Some issues seem not to be bridge interop issues, (MAC address scalability). Should take them out of here. Some may be too hard to handle: perfect LAN emulation. Need more refinement what's required & what's nice-to-have, (like protocol handling). - Ali: Regarding perfect LAN emulation, some things will just not work. - Vach: For problems already solved by some other organizations, we don't need to solve them here. Would be nice to know those problems already solved. - Ali: This is not the intent, important to point out the functionality required at the PE for interoperability. Will update the draft to address these comments. - Himanshu: Draft brings up good points. How will the draft address each of these issues? - Ali: Agreed. Need to point to solutions that exist, come up with solutions for things that are missing. - Himanshu: Would you like to address these issues with solutions in this draft? - Ali: Would like to address some, more extensive things may need a separate draft. - Dinesh: Suggests we consider an applicability statement to address these issues. Meeting Adjourned @ 1230 |