IETF 84 L2VPN WG Meeting 1st Aug 2012 Vancouver Giles - we will wait for an AD before we start, Stewart? Giles - ok we are to start without Stewart, he is hopefully on the way. Giles - Agenda - See slides. Many drafts in the E-VPN space. We will have various of those presented today. Note Well Blue sheets - Nabil to pass them around now. Status Document - See Slides Giles - We have 2 RFC's have got through. ARP Mediation has the longest gestation period we can think of - RFC6575. RFC6624 also passed. There is a whole stack of RFC's to get done. Looked at the VPLS MIB, which reminds us that when things go to last call, we can't have things like TBD in drafts. As a working group we need to be more vigilant. Nabil - VPLS-Multicast draft passed in working group last call, there where some changes to be made, and authors have done that. Last call for that coming, look for that after IETF. Giles - VPLS Broadcast expansions will waiting for PWE3 working group Giles - PIM snooping, author to present today. Giles - VPMS - Expert review needed as not enough comments in on the list. Pranjal - Speaking about Mac flush optimisation and loop detection. Received good comments around use cases and also around RFC 4762, we have addressed all these in next revision and they look good to go to last call. Giles - We are awaiting update from Kireeti on VPLS Multi-homing. Finally on IPLS discussed in Taipei if it's NVO3 or L2VPN scope and agreed it'd be progressed in L2VPN as informational. Sanad from Alcatel (on behalf of Kireeti) - we are doing an update on VPLS multi-homing and will have this done before next IETF. Giles - We have requirements for E-Tree and EVPN, both adopted a while back, last year. Question for the group - do we think these are fully baked? Can they go to RFC? Giles - E-VPN protocol drafts pbb-vpn and trill-evpn draft, decision to split them as discussed before. Also also to present on how the base E-VPN draft has been simplified. Giles - We need consensus on these remaining drafts and then move them to last call. We have various new E-VPN drafts being presented today. We have some expansion in the number of individual drafts, was 3 at last IETF - now 19. Many in E-VPN space, hoping for progress today. Draft Presentations. PIM Snooping over VPLS http://tools.ietf.org/html/draft-ietf-l2vpn-vpls-pim-snooping-02 Presenter: Olivier Dornon Originally presented by, see slides, have been contacted by Juniper to resubmit. We have been contacted by Jeffery from Juniper, and as we have a customer base for this we thought we would resubmit it. We have tried to move from flooding all over the place, to moving traffic to where there is a listener. We now want to do this for PIM. We do this by snooping for 'hello packets and prune', we are using a proxy to flood them to only the ports which are interested. current status - still work in progress, some re-writes, explanatory text added. previous text changed - snooping relies on traffic doing pim join, old text had ref to expired drafts, or ones now rfc, all now updated. Some objections to this in the past, we would like to discuss. Thank you and comments on the mic please Giles - we would like some comments and feedback from operators. Giles - No one at the Mic, questions go to the list. BGP MPLS Based Ethernet VPN http://tools.ietf.org/html/draft-ietf-l2vpn-evpn-01 Presentor: Ali Sajassi (sajassi@cisco.com) Many discussions had at the last ietf, conclusion to reduce options and minimise the draft. New section 7 - created to clarify the relationships in the draft. new section 9 - added to describe the multi-homing. reducing complexity, a lot of removals here to simply the options in the draft - went from 6 options to 2. don't care split horizon label - removed as there was some ambiguity when adding entropy label, so this was removed ambiguity there, and the don't care mechanism source quenching - used with ingress replication so ingress PE replicates one packet per egress PE. Would allow ingress PE to not send packet to a multi-homed site attached to itself. but was very inefficient and provided little value for complexity it added. result is removed segment ID field. added section on active/standby. let's remote PEs deduce that packet came from primary PE. remote PE can simply set adjacency to secondary PE if primary fails. new draft has big changes vs rev 0. Recommend reading it - especially if had difficulty with last rev. co-authors think draft is in good shape for working group last call. Giles - who has read this draft? It's a fair number, would be great if everyone could read. For procedure we can do requirements draft first and then progress to this one. Giles - are we in post lunch lull we are way too quiet. Someone please make some comments :) BGP MPLS Based Ethernet VPN http://tools.ietf.org/html/draft-ietf-l2vpn-evpn-01 Presenter: Ali Sajassi (sajassi@cisco.com) As working group recommended we split the draft. For requirements we did not do a good job, but it is missing a pointer for E-VPN, so we need to do some more work in this area. Feels like right now we need to go through the draft and do a better job on it. Ali presenting draft. Stewart L2 WG AD arrives Giles - do we have a comment? Nope the person is is leaving the room. Eric Grey - When we talk about trill operators, they are not offering a trill service are they? Ali - We are taking about a given admin entity, I need to clarify this on the draft Eric Grey - Data Center Operator would be nice. You talked about stitching, not sure how you can do this with the transit r-bridge. Ali - We are not changing the trill header, only encaping it in MPLS. Hence upfront requirement that addresses are unique. Eric Grey - Not seeing how control plane and data plane is separate, as the nickname is from domain edge to edge. Ali - This is why in the draft the nickname is non-dc id, there needs to be a draft on this for Trill. Nabil - So you are not extending ISIS over DC boundary. Ali - Yes, we are not extending ISIS terminated at the boundary Lucy Young - it's good to keep control plane as island, but the drawback is that trill is not completed work yet. Ali - each DC control is separate in the draft, feedback we received is that DC wants this. Lucy - we have another draft of trill over vpls, which is more transparent.. Ali - yes, but that does not address the DC operator problem. Giles - As we have WG consensus on this draft we want to move this one forward, but if you bring your draft back to WG we will consider it as it is different in scope to this one. Suggest Lucy brings the draft back to WG. Nabil - Ali are you presenting this to TRILL. Ali - yes at next IETF. Donald Eastlake (Huawei) - agreed that all these mechanisms for stitching multicast may be needed. there may be stuff which requires a bit more control info, e.g. there are local vlans, so filtering might be needed between islands, which could be done at the edge - or could be signalled. Don't want to send unnecessary data between the islands. There might be DC operators who want to interconnected several areas via MPLS, but others may want full isolation so we need mechanisms for both. Ali - no objection, yes we should take some feedback from the operators on this. Giles - yes we'd like operator feedback, especially on the multicast stitching. Don - happy to work on this draft on nicknames etc. Ali - thank you will contact you on this. LSP-Ping Mechanisms for E-VPN and PBB-EVPN http://tools.ietf.org/html/draft-jain-l2vpn-evpn-lsp-ping-00 Sami Boutros (sboutros@cisco.com) Sami presents draft Giles - feedback - who has read this draft? Only 4-5 people - who all seem reasonably happy. We would like to have more people read this and give some more feedback, and on the list too. Lucy - can we elaborate on Aliasing? Sami - what this mean is we will not advertise the MAC route from both PEs to a dual-homed device. Other may never see it. But will load balance to both using aliasing. to verify connectivity for aliasing need to include the FEC for the Ethernet AD route in the echo request. Can't include the MAC as he's never seen it. VPWS support in E-VPN http://tools.ietf.org/html/draft-boutros-l2vpn-evpn-vpws-00 Presenter: Sami Boutros (sboutros@cisco.com) Sami presents draft Kireeti - There is an RFC that does this. When I did it I was told not to use BGP for this and there is already an RFC for this. Technical comment, this only solves it for one thing, Ethernet PWs, we want to do a draft for multihoming your BGP. and that will solve it for all of this. Ali - beauty of this draft is that it used existing E-VPN with no new BGP attributes for a point to point connection. Intended for ethernet only. Giles - Can Kireeti finish his draft and we can compare? Lucy - so EVPN control plane will have option. Sami - We you will have the options, there is no PW signalling so comparing is not applicable. VLAN Aware EVPN services http://tools.ietf.org/html/draft-cai-l2vpn-evpn-vlan-aware-bundling-00 Dennis Cai (dcai@cisco.com) Dennis presents draft. Comments? Lucy - slide 2 please. so for L2 broadcast domain to topology is different? Dennis - so yes it is different, and we could have 2 configs for this. 1 for 1 VFI and 2 for 2 VFI. Nabil - From Lucy's point we need to have standard terms, VFI is really VSI. Is this not already covered for EVPN in the base spec? Dennis - I think it's beneficial to have 1 draft for EVPN and VPLS. Nabil - the title says E-VPN. As VPLS is in the appendix you should call it out as people don't read appendix. Giles - do we need more complexity to VPLS at this point. if we get it for free in E-VPN why not just do that. do we need to solve every new idea twice? Wim - do feel like this is well covered in the base spec for E-VPN. Do we need drafts to see how all this is working together for all use cases? What do others think about it? Lucy - can you handle 2 CEs on the same site connecting to the PE. Dennis - yes, all VPLS and E-VPN operations are the same as before. On the same PE can have two different ACs. Vendor specific. 802.1aq and 802.1Qbp Support over EVPN http://tools.ietf.org/html/draft-allan-l2vpn-spbm-evpn-01 Dave Allan (david.i.allan@ericsson.com) Dave presents draft Acknowledges other authors for their help. No Comments at the Mic. VPLS PE Model for E-Tree Support http://tools.ietf.org/html/draft-jiang-l2vpn-vpls-pe-etree-06 Yuanlong Jiang (jiangyuanglong@huawei.com) Yuanlong presenting draft No comments at the mic E-TREE Support in E-VPN http://tools.ietf.org/html/draft-sajassi-l2vpn-evpn-etree-00 Ali Sajassi (sajassi@cisco.com) Ali presents draft. Wim - draft needs some clarity around ingress replication vs point to multipoint. issue of upstream vs downstream labels. Ali - agreed. will update. Himanshu - We have a decision to make on how we support E-Tree in VPLS. We need to have a single solution with is applicable to both VPLS and E-VPN. Giles - yes, we'll come onto that next when we discuss E-Tree. Dave Allan - Bit of relief for the chairs, we have this sorted for E-Tree for SPBM. So you won't have to do this again. Giles - Ali - what happens if there is a broadcast or multicast packet from leaf in scenario 3. How do you avoid sending it to another leaf? Ali - For a given MAC address I know if it is leaf of root, so I can colour it, and the ESI label will show if it is a root or a leaf. Giles - Label is not my issue, the issue is when you get to the egress port and it is mixed root/leaf. Ali - that is the job of the network to take care of it, you sent the packet and the edge devices in that network take care of it. Lucy - for this you are doing a trick with ESI label? Ali - no new functions in hardware, already there for multicast. You have to colour it to do the filtering. In baseline EVPN we apply ESI label to BUM traffic, this draft you apply to unicast too. Giles - we are out of time on this draft. E-tree discussion - going forward Working Group Giles - are we agreed we want to get to one solution for VPLS and E-VPN. Not many people. But even fewer who want multiple. Checked to see if people want one solution only for E-VPN and VPLS - only a couple of hands. Himanshu - I'd prefer one solution that works on VPLS and E-VPN. Giles - not sure that's possible given how different VPLS and E-VPN are? Himanshu - e.g. if we have 2 VLANs for VPLS then that'll work on E-VPN? Nabil - fundamental difference is VPLS requires PWEs, E-VPN doesn't. MAC based learning across core (vs control plane). So we've already split them. Himanshu - 2 VLAN solution ought to work. Nabil - one thing. 2 VLAN on access side. Question is 2 VLAN VPLS vs E-VPN (in core)? Ali - E-VPN already has built in functionality based on ESI label. Asinine to have this and then use something else (whether an MPLS label or an Ether tag). Giles - For VPLS seem to have consensus that we only want one approach (but will poll list) Giles - Can we have show of hands for those who prefer the two VLAN approach. about 20 hands. Giles - what about for those who prefer do we want to get to one solution for two PWs? We have one hand. Giles - Prefer the control word approach? No hands - even the authors are not backing this one! Giles - so in this room we have consensus around 2 VLAN but we need to take this to the list. Giles - on E-VPN we'll assume we want to get to one solution. Himanshu you're welcome to put together a 2 VLAN approach there. Understand your point re having the same solution for E-VPN and VPLS but we do want to have the right solution for E-VPN.