Layer 2 VPN Meeting Minutes. Anaheim, 26th March 2010 Chairs: Giles Heron & Shane Amante Scribe: Matthew Bocci WG Status Web Page: http://tools.ietf.org/wg/l2vpn/ 1) Administrivia Agenda bashing: fine Giles sends apologies. 2) WG Status and Update 10 mins WG status: L2VPN signaling slowly inching towards RFC. Reassigned some code points from L2VPN Sig to ARP mediation (0x2c). IESG needs to approve this first. Request IANA for new code point. ARP-MED and IP: on agenda today. Believe all IPv6 changes in there. Will do WG last call. Andy Malis & Nick Delregno to provide comments in last call. Multicast: VPLS and VPMS: still Work in progress Rahul Aggarwal: has 1 volunteer for VPLS reviewer. VPMS Encap is in PWE3, and autodiscovery in this WG. Will reissue before you ask for WG adoption. VPLS OAM: Probably make a WG draft call Service convergence/multi-homing: Florin to give an update on PBB draft 3) ARP Mediation http://tools.ietf.org/html/draft-ietf-l2vpn-arp-mediation-13 Himanshu Shah (hshah@force10networks.com) 5 mins Covers both ARP-MED & IPLS. Long history. Started in 2003. Originally service interworking. Issues with the service interworking text. Eventually convinced IETF to adopt the work under arp-mediation title. Currently on 13th revision. IPv4 version was WG last called. Input on IPv6 from Matthew/Andrew/Neil. Multiple implementations exist (some deployed) Most aspects of the IPv4 sections have been reviewed several times. But still need review of IPv6 sections. Last few revs dealt with IANA code point status update. ARP-med originally used 0x2c LDP status code. That had pre-allocation from IANA. 3rd draft (LDP capabilities) also had the 0x2c code point, but that was an error on their part. But arp-med now has permission to use the code point. Need WG last call ASAP. Shane: asks for more review volunteers 4) IPLS http://tools.ietf.org/html/draft-ietf-l2vpn-ipls-09 Himanshu Shah (hshah@force10networks.com) Has gone lock-step with arp-med and should also now be last called. 5) MAC Flush Loop Detection in VPLS http://tools.ietf.org/html/draft-pkwok-l2vpn-vpls-macflush-ld-01 Pranjal Dutta (pranjal.dutta@alcatel-lucent.com) 5 mins About loop detection in VPLS. First presented in IETF74. Objective is to improve robustness of existing MAC flush mechanism in RFC 4762. Presents problem statement. Failure of split horizon can cause loops. Uses path vector TLV from RFC 5036. Path vector TLV in context of MAC flush. Illustrates procedures. Asks for WG status. Ali Sajassi: in here you say reason is detecting mis-configurations, but this will result in loops in the data plane. This is much more important that loops in the control plane. Would be good to have a mechanism to address both. Pranjal: would you like this addressed in this same document? Ali: Right, because we need to solve that problem as well. Lizhong: You proposal adding TLV to withdraw addresses. That is a function of LDP. Pranjal: not a new TLV. This is used in L2VPN today for mac flush. We are also trying to standardize it for mac withdraw. Lizhong: but this is not specific for mac withdraw. Pranjal: path vector gives you an opportunity to ? Himanshu: I know what Ali said and there was this discussion on the mailing list a while back. It is difficult to lump into one draft. Data path is a bigger problem, so if you want to progress this you should keep it separate. Shane: - Do people want to advance this as a WG draft as-is, or do we want to wait until we have data plane - 1 objects to progressing as-is - any objections to advancing the work with both? Ali: need to look at if we can use data path mechanism for this. Shane: - how many support adopting this draft as-is? - 6-8 hands Nick Delregno: does that preclude adding data plane later? Agree we need data plane, but in lieu of no data plane draft, don't want to hold this up. Shane: need to see someone bring a draft on data plane. Then we can make the call as to whether to incorporate. 6) Requirements for Active/Active multi-homing customer device/network in a provider VPLS network draft-sajassi-l2vpn-vpls-active-multihoming-req (unpublished) Ali Sajassi (sajassi@cisco.com) 10 mins Deals with active-active case. Lists the requirements: 1) per-flow load balancing for a given VLAN 2) flow-based multi-pathing 3) Geo-redundancy and optimal unicast forwarding between any pair of CEs 4) Flexible redundancy grouping Issues with using VPLS as-is - Looping of traffic flooded from PE. - Duplicate frames for floods from the core. - MAC flip-flopping. Happens when aggregation node load-balances traffic in uncontrolled manner Solution can be Router VPLS. Easiest solution is to do in control plane. Treat C-MACs as routable addresses and distribute them in BGP. Skips detailed description. Distribution of MAC address over BGP. No learning in the VPLS core. Can use P2MP tunnel. Needs loop prevention to make use multicast only forwarded over one active AC. Shows operational scenario for ARP. Next steps: solicit feedback from WG, and progress as WG draft Rahul: Agree with problem. Solution: you said cannot be solved using DP. Can be solved, but it is complex. Ali: agrees Rahul: We have an unpublished draft on same topic. Let's try to avoid presentations on unpublished drafts. Florin Balus: is this going to address LAG with two CEs with two PEs Ali: what is protocol? Florin: one CE with LAG to two PEs. Marc Lasserre: you have introduced a loop with two active links. So this is technology agnostic so should this be solved here or elsewhere? Also this is more like IPLS... Wim Henderickx: Should adopt this work going forward, but would spell our requirements more clearly. Needs a separate requirements document. Ali: this is just like the active/standby solution. So does not need requirements draft. Shane: with VPLS, active standby has always been part of the technology. Active-active has not and is not part of current charter. Active standby has been there from the beginning. Shane: Ali to publish the draft and send a link to the mailing list. Should solicit input on the requirements side and use reqmt's as input to next WG recharter discussion. 7) Extensions to LDP MAC Withdraw for PBB-VPLS http://tools.ietf.org/html/draft-balus-l2vpn-pbb-ldp-ext-02 Florin Balus (florin.balus@alcatel-lucent.com) 5 mins Presents the background. Related to WG charter on scalability. Two drafts: LDP mac extensions for optimized MAC address withdrawal. Draft-balus is doing the same thing for PBB-VPLS. Shows a comparison with regular LDP MAC flush. Procedure is the same, just a little more info in the MAC withdrawal. Need ISID sub-TLV, and a BMAC sub-TLV Next steps: could merge the drafts. Authors agree procedures are complementary. Ali Sajassi: you are also co-author of PBB-VPLS interop, but this breaks some of the scenarios there. This one requires interoperability with PBB MAC flushing. Although you made comparison with regular VPLS MAC flushing. In PBB, only do the flush on the edge. Ali: Educating them is the solution. If there was a shortcoming, take care of it, but if there is an existing mechanism use it. Shane: need to take to the list so that SPs can speak up. Shane: wants to canvass the room on the two questions: - anyobe objects procedure in PBB LDP extensions? 1 hand - who agrees to incorporate: about 10 people 8) Discussion of ETREE requirements and solution space Nick DelRegno, Jim Uttaro, Florin Balus 15 mins Shane: next work can only go forward until the existing work items have cleared off the agenda. Please take the following presentations as a source of requirements for future. Shane: Any work related to E-TREE, which is the next series of presentations, can only go forward once we've completed the existing, overdue work items on our charter. We're having these presentations today so people can start to understand what, if any, work the L2VPN WG may want to do. The hope is that this work can be fed into a clear, crisp set of requirements that can be evaluated for milestones & deliverables the next time we re-charter. Florin: Describes challenges of distinguishing traffic for roots/leaves in ETREE service from MEF. Lists some example use cases. Lists technology solutions. - do not build PWs between leaf PEs - control PW topology - BGP RT approach already used in L3 VPNs - Use root/leaf tag to filter traffic between leaf endpoints. - IETF proposals to use CW - In IEEE/ITU use VLAN tag These proposals are complementary. Detailed comparison of the ETREE solutions. Should first understand if an IEEE solution is a good baseline. If it is, specify the PW CW bit or indicate to IEEE we want something from them. Ali Sajassi: for option 2, how about just using PW itself? If you are already using RT, why do you need this tag? Florin: if you have a native Ethernet domain. Ali Sajassi: John Messenger: basic mechanism does not need to be changed, but there are some proposals for enhancements. There is some text in an annex, which could do with being amplified. Nic Dolregano: Would like to figure our one best solution. DoesnŐt want to see multiple solutions. Rahul Aggarwal: excellent presentation. This spells out the problem well. Option 1 is a must. Once you have done this, how do you identify whether traffic comes from root or leaf AC? CW approach is broken. VLAN tag is appealing if it gives a homogenous solution. If it doesn't could use MPLS label. Lucy Yong: comparison is useful, but too early to link to solutions. Himanshu: could have leaf PW and root PW, but I know this is not scalable. 9) A Framework for E-Tree Service over MPLS Network http://tools.ietf.org/html/draft-key-l2vpn-etree-frwk-02 Lucy Yong (lucyyong@huawei.com) 10 mins Objective to provide a simple way to emulate etree over MPLS network. Draft specifies each component. Gives overview of MEF multipoint services. E-Tree has both root and leaf construct. IETF services are VPLS and VPMS VPMS doesnŐt rely on mac-based forwarding Proposes a solution framework for etree services. Each PE is using a VSI for ETREE. Both root and leaf ACs attached to VSI. Ethernet PW used between any pair of VSIs. E MAC based forwarding from any-to-any Ethernet VPN (VPLS) P2MP PW for optimization IP multicast in VPLS Next steps: please review draft and post comments to the mailing list. Shane: Rahul had a draft a while ago for VPMS. This would be split into PW component and auto-discovery component. Shane: Rahul has presented a solution draft for VPMS a while ago: http://tools.ietf.org/html/draft-raggarwa-l2vpn-p2mp-pw-02 ... however, this conflated the P2MP PW parts that belong in PWE3 and the Auto Discovery parts that belong in L2VPN. We've agreed to split the doc in two and progress each in the appropriate WG. I'd suggest you evaluate it and see if this meets some, or all, of your reqmt's for E-TREE. 10) Extension to VPLS for E-Tree http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-02 Lizhong Jin (lizhong.jin@zte.com.cn) 10 mins This describes solution based on VPLS. Presents the problem statement. Prerequisite is having a control word bit allocated by PWE3. Matthew: PWE3 would only progress this if there was a clear requirement from L2VPN Nic: This requires a control word, so a box has to support a control word. PW mustn't come up if a CW is not supported. 11) VPLS PE Model with E-Tree Support http://tools.ietf.org/html/draft-jiang-l2vpn-vpls-pe-etree-00 Yuanglong Jiang (yljiang@huawei.com) 10 mins Presents E-Tree requirements on VPLS. Shows etree scheme in IEEE. Requires enhanced PE models with new etree VSI. Describes the PW processing. Requires extensions to LDP to negotiate etree support Next steps: requests WG feedback. No comments. Shane: really would like to see review of the drafts and to see if the ETREE requirements are addressed in the VPMS requirements draft. 12) VPLS MIB Changes http://tools.ietf.org/html/draft-ietf-l2vpn-vpls-mib-03 Kiran Koushik (kkoushik@cisco.com) 5 mins No slides. Version 3 of VPLS MIB. Addressed outstanding comments. Asks for review from WG. At least 2 implementations.