L2VPN - Atlanta IETF 85 November 6th 2012 Atlanta, 1pm Tuesday November 6th (Salon D) Chairs: Nabil Bitar Giles Heron WG Status Web Page: http://tools.ietf.org/wg/l2vpn/ 1) Administrivia Giles doing the intro. Stewart - please mention IPR Giles - we would request you do this to avoid problems down the line. Giles - We have a bunch of drafts being shepherded. 2 of them have IPR, but the company that has it is not around anymore. There was no discussion on the list so far. WG needs to figure out how we address this. Giles - VPLS MIB - I done a detailed review, had gone to last call but was not ready, authors have done another spin in it. Giles - Nabil can you give us a quick update on multicast? Nabil - Comments from the author have been reflected in this draft, we are waiting for Stewart now. Giles - VPLS broadcast extension status - we can only last call this when PWE3 WG has last called P2MP PWE. Chairs not that happy with the P2MP PWE draft, this needs to be progressed. Giles - PIM snooping was dormant but authors would like to get comments to resurrect it. So comments please. Giles - VPMS. Trade done with PWE3 WG, Mathew doing expert review of this, in exchange for Giles shepherding one of theirs. Nabil - MAC flush and loop detection, there was a new draft in September, we need a final review and then we can take it from there. Giles - VPLS multihoming updates being presented today. Giles EVPN and E-Tree, good progress here, moving to last call for some of them, Ali to present 2 of them today and other individual drafts presenting today also. On E-Tree, requirements in last call, friday. Nabil - we asked the authors to show what the requirements are independent of the solution. Next week for last call for .03 for next friday Giles - This leaves the E-Etree framework to last call, and one more on VPLS-ETree, this is being discussed today also. Giles - I think this is it, so we can move to presentations. 2) BGP based multi-homing in VPLS http://tools.ietf.org/html/ietf-l2vpn-vpls-multihoming-04 Senad Palislamovic (senad.palislamovic@alcatel-lucent.com) (15 minutes) Senad presenting his slides. This problem was first brought up in Taipei. Cleaned up the draft Proposed solution - BGP portion is now clearly separated from the VPLS portion. Some additions will be made before the next IETF and bring it for final call. No Questions at the mic. 3) BGP-Based Ethernet VPN http://tools.ietf.org/html/draft-ietf-l2vpn-evpn-02 Ali Sajassi (sajassi@cisco.com) (5 minutes) Ali presenting his slides. I have many presentations so I'm keeping it short. Update on the modifications, detailed in the slides. There are a few more changes into the next revision, rev 3, and move it to last call. Mic: Lucy - Can we support multiple AS? Ali - We will add a para to clarify this, Inter-AS is already covered, but we will add something to clarify. Lucy - This draft talks about multicast all over the draft, can you consolidate this into one section. Ali - if you have a suggestion I would like to hear this, we can talk offline on this. Nabil - IDR chair comment, can we cross post the document to the IDR WG as we are talking about BGP advertising MACs Ali - Sami taking a note of this and we will do so. 4) E-TREE Support in E-VPN http://tools.ietf.org/html/draft-sajassi-l2vpn-evpn-etree-01 Ali Sajassi (sajassi@cisco.com) (5 minutes) Ali presenting his slides. To refresh we have 3 scenarios. See slides. Ali - We will publish rev 2 and ask for comments on the mailing list.. Mic: Yuanlong - How does a node know which scenario applies? Ali - Good question, you will need to do the superset, if you know for certain you can do just the scenario you know. Example, lets say i start with scenario 1 and move to 2 Yuanlong - so this is a config item not automatic? Ali - It is a matter of the protocol, and depending on what you configure. Yuanlong - We can wait for the revision Ali - We don't have to wait for this, it is in rev 0. Maria - 2 comments I have are on policy for flooding, PE to PE where it happens or does not happen. Perhaps it needs to be described. Ali - there are 2 different things, we can flood or not flood. I'm not sure what you are asking for. Maria - It should state clearly we should flood or not. Nabil - there was a statement that you could allow flooding or suppress via management. I"m not sure if statement is still in the draft. Maria - Not sure it is there, does not specify if it is there. Ali - there is a statement which says you can turn flooding off and on, per VPN we can put that statement in, but we don't need to cover the use-case in this draft. Maria - it is important to state this an have a little more explanation, to support certain applications. Nabil - maybe you should post this and your idea for behaviour to the mailing list Maria - second comment, section 11 says you can learn based on snooping certain messages, you should clarify what the messages are. Ali - MAC learning is done as part of the regular gleaning of MAC address over the interface. And it says you can learn IP as well. Do you want clarification of the IP aspects? Maria - yes clarification on what you are snooping on. There are implications. Giles - We had this debate with ARP Mediation, you are only supposed to learn the IP/MAC mappings from ARPs, but that does not work for this application. 5) E-VPN OAM Requirements and Framework http://tools.ietf.org/html/draft-salam-l2vpn-evpn-oam-req-frmwk-00 Sam Aldrin (aldrin.ietf@gmail.com) (10 minutes) Sam presenting his slides. Sam - Most of you know what E-VPN and OAM are, if you don't then I'm presenting SDN. (room laughs) Sam - Draft submitted a few weeks before IETF. Discussing objectives/OAM layering/OAM requirements. We are not trying to create something new at every layer. For example L2VPN has this well detailed in RFC6136. For MPLS have LSP ping. Ethernet has CFM. We will leverage all these standards. Sam - E-VPN service OAM slide - we have different working groups working on this, so we will use this work. This is similar to PWE OAM. And in transport layer LSP ping or trace should be able to work, and also with Ethernet at the link level. Sam - want more input from WG. Mic: Greg Mirsky - can you add throughput measurement? Are you planning to do specification for mechanisms for one sided, two sided, proactive, on demand performance measurements? Sam - the solution drafts will explain how to do this, and how we use and measure this. Greg - will you be using new mechanisms for Ethernet OAM? Sam - no, we want to use existing mechanisms and if requirements not met gone to the relevant WG. Greg - E-VPN is a point to multipoint service. are performance measurements point to point or point to multipoint? Sam - if we need point to multipoint then we need to get requirements for this. 6) 802.1aq and 802.1Qbp Support over EVPN http://tools.ietf.org/html/draft-allan-l2vpn-spbm-evpn-02 Jeff Tantsura (jeff.tantsura@ericsson.com) (5 minutes) Jeff presents his slides. We are going to talk about how we are going to connect SP islands over E-VPN Mic - No questions Giles - This has to be a record for a short presentation. Who has read this draft? Ok, just a few. Aligning with PBB-EVPN, to your point we should read that first. 7) VLAN Aware VPLS services http://tools.ietf.org/html/draft-cai-l2vpn-vpls-vlan-aware-bundling-00 Sami Boutros (sboutros@cisco.com) (10 minutes) Sami presents his slides Mic: Lucy - one comment on the bundle. I don't think the DC provider wants to use this approach to bundle the VLANS in a VPLS service, instead the DC provider wants to use a VPN to interconnect the DC underlay network. More flexible. Sami - not sure if i understand what applies for NVO3 here, what the draft is about is scaling in the core. We can signal in the core one VPLS instance. This is not an NVO3 type solution. Lucy - but if i want to increase the number of C-VLANs do I have to talk to the SP to do this? Sami - this is not the NVO3 solution, what is in context is one VPLS instance where we can mix more than one VLAN. Giles - Lucy, for now we need to forget that NVO3 will solve all the world's problems and let this be the VPLS solution, or we are going down a rathole. Lucy - ok, another clarification, you have a statement saying you have C-VLAN and S-VLAN segregation... Sami - same solution can apply, for S or C-VLAN, not limited to C-VLAN only. Lucy - does this include a combination I have some frame on S or C-VLAN? Sami - this is true depending on the type of the trunk. The idea is to make it generic and apply for both. Wim - I think we can do this already today with PBB VPLS. Sami - yes you can do this with PBB, and with scaling, but we did not want to add the PBB header, and maintain VPLS. Wim - the question is why do we need yet another solution to this problem? Giles - we need to take this to the list. The question for WG is do we need this as well as other solutions. Sami - One comment, E-VPN also calls for VLAN-aware bundling. Wim - I'm just debating the VPLS part and why PBB VPLS would not be used for that. Ali - Basically if we don't have hierarchical VPLS then going PBB VPLS does not buy us much, we don't get the MAC scaling as MACs will be on all PEs. So can we take care of PWE scale - this is one way to do that. My comment is the TLV you specify should be a SHOULD, as still I can do VLAN aware bundling without the TLV and without pruning. Lucy - I agree with Wim if you are doing this PBB VPLS that is the scenario, PBB is an overlay technology. Giles - Wow we have finally finished the debate, so we can move to the next one. 8) MAC Address Withdrawal over Static Pseudowire http://tools.ietf.org/html/draft-boutros-l2vpn-mpls-tp-mac-wd-01 Sami Boutros (sboutros@cisco.com) (5 minutes) Sami - We added the comments from the last IETF, had comments, this version has those comments addressed. Sami presenting the slides Giles - We would like to see if there is interest in this draft, specifically from Service Providers supporting VPLS over static MPLS-TP PWEs. If this is a valid case then the next question is is this the right solution. This is for the list. 9) A Network Virtualization Overlay Solution using E-VPN http://tools.ietf.org/html/draft-sajassi-nvo3-evpn-overlay-01 Ali Sajassi (sajassi@cisco.com) (10 minutes) Ali - E-VPN is like a swiss army knife. This draft talks about how we can support overlay. There are 2 drafts in this area, one by John Drake and one by me. We were hoping to consolidate the drafts, but did not have the time before this IETF. Ali presents the slides. plan is to consolidate the two drafts in the next few weeks. Nabil - comments please, have people read it? Lucy - you say you are going to consolidate 2 drafts, but the draft does not exist. there is no Layer 2 E-VPN overlay. Ali - yes this is NVO3 and it does exist. Lucy - then why not call it NVO3? Ali - cut and paste problem. Lucy - I think that supporting VXLAN and NVGRE is complex - makes it more complex than E-VPN. Using BGP control plane for multihoming makes it more complex. Ali - this is not more complex, it says the existing procedures of E-VPN need to be changed, Lucy - your intention is to have one instance to support multiple data plane encap, or just the one, or concurrent? Ali - EVPN for MPLS or GRE works as is. for the other 2 we need the modification. Lucy - my question is for one instance.. Nabil - we should take this to the list, but i have to caution we are getting ahead of ourselves. Nabil - NVO3 is not yet discussing solutions, and NVO3 is not in the L2 charter. So comments to the list please. Ali - we are very proactive :) Nabil - this is more of an FYI as to how this could work. NVO3 is not in the working group charter. So comments on the draft, but I don't know where this goes right now as it's not in any charter. Lucy - you mention the load balancing problem for GRE with existing router support, there is a MDS over UDP draft. Ali - i have read the draft and mention it in this draft, but it is not a standard and existing routers do not support this encap. Giles - I think we need to stop now. Ali - final comment, MPLS over GRE has been a standard for ages, if this is not implemented, then what are the chances for MPLS over UDP? Giles - Ali time for next draft. 10) E-VPN Seamless Interoperability with IP-VPN http://tools.ietf.org/html/draft-sajassi-l2vpn-evpn-ipvpn-interop-01 Ali Sajassi (sajassi@cisco.com) (10 minutes) Ali presents the slides but only gets part way before time runs out. Nabil - we are going to take this to the mailing list if people have comments. no time now. Luyuan - we have a lot of comments we've been waiting to make. There are too many untrue statements. Ali - Please clarify on the mailing list and elaborate. 11) Connecting Disparate TRILL-based Data Center/PBB/Campus sites using BGP http://tools.ietf.org/html/draft-balaji-l2vpn-trill-over-ip-multi-level-02 Bhargav Bhikkaji (Bhargav_Bhikkaji@dell.com) (10 minutes) Bhargav presents the slides Mic: Ali - there is a working group draft using TRILL, which maintains independent IS-IS domain and doesn't having to do mac address lookup at the PE. So I would recommend we review that draft and work on those areas. Bhargav - the draft talks about the mechanism of dividing the nickname into two parts, if I am right. Ali - there is a draft being presented in TRILL on how to do that. Sam Aldrin - you still have to do the nickname resolution, if you have to combine 2 data centres that will need to be resolved. If the draft is trying to resolve something new, this would help the draft. Giles - for this to be considered it would have to be very different to the existing WG draft, and show a clear benefit over that. Giles - this brings us to the end of the session, thank you for coming and sorry for the room temperature. See you in Orlando.