L2VPN WG minutes - IETF 79, Beijing. 1) Administrivia 2) WG Status & Update a) Overview of various docs and their status. -Rahul: draft-raggarwa-l2vpn-p2mp-pw-03 unfortunately probably has a wrong name. Think we should make a call to make this a WG doc. -Shane: Agreement a while ago was to split it apart and do Auto Discovery in L2VPN and signaling in PWE3. -Rahul: That's already been done, so not sure I see the issue. -Shane: Assuming that was done, then don't see a problem in having a call to make it a WG doc. b) Discussion of merging L2VPN/L3VPN -Rahul: Too much work, no merge. View is recharter L2VPN WG. With respect to re-merger, L2VPN has enough to do, no need to take L3 work. L3VPN currently has a very well scoped work, move it to mailing list. DC has mix of L2/L3 work, it is a bit premature. -Himanshu: we need to fix the backlog -Stewart: glad to see the WG excited about clearing the backlog and looking forward to that. Would like to see more active discussion on the list, and more review of documents in last call. 3) Update on LDP Extensions for Optimized MAC Address Withdrawal in H-VPLS http://tools.ietf.org/html/draft-ietf-l2vpn-vpls-ldp-mac-opt-03 Florin Balus (florin.balus@alcatel-lucent.com) Benefits of this draft. new use-case for classical Enet: * flush-all-from-me -> flushes all mac * flush-all-but-me -> flushes all mac but the one from me new in v03 1. new native ethernet access technology with non-STP environment (and will work for any multichassis technology) 2. will work with G.8032. 3. no use of PE-ID TLV. 4. but will set a flag (N=1), flush-all-from-me Q&A: -Stewart Bryant: Recommend that L2VPN chairs speak to MPLS WG chairs to get them to review it so there are no surprises during/after WG Last Call. -Florin: We're not inventing any new mechanism, we're just reusing existing MAC flush mechanism. -Stewart: I understand, however still would like MPLS WG to review it anyway. -Giles: OK, will talk to MPLS WG co-chairs. 4) E-VPN Update http://tools.ietf.org/html/draft-sajassi-raggarwa-l2vpn-evpn-req-00 http://tools.ietf.org/html/draft-raggarwa-sajassi-l2vpn-evpn-00 Rahul Aggarwal (rahul@juniper.net) update - agreed to do: separated requirements doc based on IETF78 discussion single doc illustrating the solution, had overlapping solutions in two drafts 1. requirements draft is ready. (see slide) 2. single solution draft. (see slide) Q&A: -Chairs: these aren't yet WG docs, that shouldn't stop the work/comments generation -Rahul: we will drive the discussion on the list -Himanshu: we need to take a step back. what are the principal aspects of this proposal? Are there items in the proposals that are useful for all the L2VPN services? (IPLS, VPWS etc.) -Rahul: practical drivers are: 1. adding certain features into VPLS 2. applicability to datacenters please let us know what we have missed... -Himanshu: can we generalise active/active to other L2VPNs? -Rahul: which ones -Himanshu: VPLS, IPLS. -Shane: Would recommend that if you have customers/carriers interested in pursuing those optimizations for those services that you bring those requirements forward. -Puneet: EVPN and ETREE, architecturally they do the same thing: ingress attributes traveling across the network to egress. the group should look at that, and then the applications can be looked at -Rahul: i dont agree, but in summary 1. E-Tree is specific topological issue 2. this draft can be applied to an E-Tree 3. what is the right architecture for flexible technologies, that is what EVPN is about. 4. we have a broad design in mind to point to issues with E-Tree. 5. EVPN is about exchanging the mac in the control plane (mac reachability) -Giles: polled to see who has read the drafts. Fair number -Shane: Recommend moving discussion to the list, in particular discussing what is in/out-of-scope during the debate over what will be in the new charter. 5) Flow-Aware Pseudowire for VPLS http://tools.ietf.org/html/draft-yong-l2vpn-fat-pw-4-vpls-00 Lucy Yong (lucyyong@huawei.com) Q&A -Giles: would like to hear from operators in the room if there's interest in pursuing this work. -Wim: In general support this idea, but also would like to see it solved for IPVPN's so that we have a general solution for everything. -Lucy: do you mean L3VPN's? -Wim: Yes. -Lucy: There is a separate draft that already supports IPVPN's: the entropy-label draft. -Manuel Paul: As operator, support this work moving forward. -Rahul: Would suggest that the MPLS WG should set the direction here. We should fix the problem within MPLS so that it's broadly applicable to not just L2VPN's, but also IPVPN's and anything over LSP's. -Lucy: VPLS belongs in this WG. Entropy label talks only about labels over LSPs, not PWEs. Doesn't cover the same issues. -Rahul: Why is having an entropy label on LSPs not enough? -Lucy: this is only solving for it PW's. LSP is per hop. The PWE is between two PEs. -Rahul: we need to do work in MPLS-WG first. -Lucy: I disagree. -Stewart: (To Rahul) In the past, agreement was to advance FAT-PW draft on it's own and MPLS WG would pursue a general solution with entropy-label draft; however, the MPLS WG hasn't been too active and only recently has done work on this. So, what should we do? -Rahul: still recommend that MPLS WG solve this. -Marc Lasserre: what do you do in a MS-PW case? -Lucy: T-PE's will perform deep-packet inspection and create a FAT-PW label. -Giles: Please can we have more discussion on the list and then we can take a decision. The list is where we decide. 6) Extension to LDP-VPLS for Ethernet Broadcast and Multicast http://tools.ietf.org/html/draft-delord-l2vpn-ldp-vpls-broadcast-exten-03 Zhihua Liu (zhliu@gsta.com) No questions. 7) Requirements for MEF E-Tree Support in VPLS http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-reqt-02 Manuel Paul (manuel.paul@telekom.de) Q&A: -Luca: Can you explain what does not work in the current solution? We can use BGP Auto Discovery & configuration to achieve what you want. -Manuel: Correct. But, think we can do better with simple extensions to LDP-VPLS. -Luca: Need to point out why the existing solution set is insufficient. You're trying to create a VPLS that is restricted in some way. -Manuel: This diagram is only showing 2 PE's. Do you want us to show 3 PE's to better illustrate leaf-leaf traffic restriction? -Luca: Previous slide was discussing modifications to the local VPLS PE, which doesn't require protocol changes. -Manuel: This is a requirement draft -Luca: I'm just asking why the current solution isn't sufficient. -Manuel: The details are all in the draft. -Giles: Need to take discussion to the list. (To Luca): perhaps you can document how the current solution already solves this problem to kick off that discussion on the list? -Florin: There are solutions to this problem with using RT's and BGP A-D and possible configuration of VLAN tags on PE. So, need to document requirements and then look at solutions that can solve that. -Nick Delregno: appreciate the feedback and would be happy to address it in future version of document. 8) VPLS PE Model for E-Tree Support http://tools.ietf.org/html/draft-jiang-l2vpn-vpls-pe-etree-02 Yuanlong Jiang (yljiang@huawei.com) Q&A: - Florin: Putting aside the control plane signaling, I like this approach because this provides a solution within the data-plane to solve for Native Ethernet access networks. -Yuanlong: we can signal via a PW -Rahul: Clarification question. Is IEEE procedure using reserved S-VLAN values? -Yuanlong: No, they are not reserved VLAN's. Requires provisioning of network elements to indicate what S-VLAN values are. -Rahul: OK, thanks. So you may need to configure the values? -Yuanlong. Manual or via configuration. that's a choice. 9) Virtual Subnet http://tools.ietf.org/html/draft-xu-virtual-subnet-03 Xiaohu Xu (xuxh@huawei.com) Q&A: -Florin: How do you learn which hosts are located on which side of the network? -Xiaohu: The PE routers learn the MAC addresses. -Himanshu: Overlaps a lot with IPLS. Doesn't support routers, only hosts. But IPLS supports both -Xiaohu: The document is clear that it is intended to only support servers/hosts & doesn't intend to solve for routers. It's an optimisation. -Himanshu: If there is another protocol that is using BGP to distribute reachability, which isn't good, given we use LDP for IPLS already. -Xiaohu: In IPLS the source should use its own MAC address -Himanshu: Not being able to support routers is a big disadvantage. -Xiaohu: Traffic can still be destined to an IP router, for traffic that is destined to go outside the DataCenter. That's in the draft. -Himanshu: That wasn't explained here. I'll read the draft again. -Giles: I'm concerned over which WG should take on this document, because there are Layer-3 elements in here. Also there's the ARMD BoF tomorrow. This seems to be addressing some of the same problem space. -Wim: Agree with Giles. Why are we discussing it here? There may be other ways to solve this problem. Most of the draft is local implementation (e.g. the ARP scanning mechanisms). what are you trying to achieve? ARP can be stored persistently and then you can check if your neighbours are still there. -Paul Ubenhagen: Is the PE using a directed broadcast to discover all the hosts in the subnet? -Xiaohu: Yes. -Paul: Are you concerned with a DoS attack when a PE reboots. -Xiaohu: Its not a directed broadcast, it's doing scanning of every possible IP address. there are other options but those need protocol extensions. -Lizhong: I share the same concern that the PE is going to scan all the hosts. What happens when new host joins? -Xiaohu: New host will send a gratuitous ARP and the PE will find it. Or it can be statically configured. -Giles: Let's cut here and take this to the list. 10) VPN Extensions for Private Clouds http://tools.ietf.org/html/draft-so-vepc-00 Paul Unbehagen or Mike Mangino Have determined this week that this likely belongs in a newly formed DataCenter Operations WG, so look for it there. No questions. 11) LDP Typed Wildcard PW FEC Elements http://tools.ietf.org/html/draft-raza-l2vpn-pw-typed-wc-fec-01 Sami Boutrous (sboutros@cisco.com) No questions. -Chairs: Plan is to rename the draft and take it (back) to the MPLS WG mailing list.