Layer 2 Virtual Private Networks (l2vpn) CHAIRS: Vach Kompella & Shane Amante One Session: IETF 75: Stockholm, Sweden THURSDAY, July 30, 2009, 0900-1130 2) WG Status and Update -- agenda bashed work in background on ARP mediation (IPv6) etc. milestones - rather aggressive dates in the charter so fallen behind on OAM soln and some of the multicast stuff. Getting to point where won't accept new work unless we see some progress - so this is your final warning! Please, for example, look at MIBs and help get it done. 3) BGP based Multi-homing in Virtual Private LAN Service -- Kireeti Kompella (kireeti@juniper.net) http://tools.ietf.org/html/draft-kothari-henderickx-l2vpn-vpls-multihoming-01 merger of Wim/Florin's spec with Kireeti/Bhupesh's one thinks have done a good job of merging the specs. Few parts are specific to BGP or LDP VPLS, but most is now generic. key thing here is that you can only have one forwarder, so all need to agree on who's forwarding/who's blocking. BGP VPLS has one VE-ID (identifies the VSI). LDP VPLS has PWEs using FEC128 or 129. No dependency in this draft on using BGP for VPLS auto-discovery. Draft has "MH-ID". Identifies that one site is connected to multiple PEs. Use the NLRI from RFC4761. Use the VE-ID as the MH-ID. But set the label base off and the label range to zero. Already overload the NLRI to do AD. So now one NLRI can be used for MH, for AD and for BGP VPLS signalling. For the designated forwarder election we use a local preference. key is that every PE must agree who the DF is for any given MH-ID in one VPLS. So we don't use distance (as different PEs would see different distances). Just use preference. Once the DF is selected it will enable its AC, and any other PEs for the same MH-ID will block their ACs. issue with multi-AS is no local pref any more. Also the originating PE might be rewritten at the AS boundary (e.g. option B). So use the loopback of the PE originating the MH NLRI and use the route origin extended community to preserve it across the AS boundary. also have "VPLS preference". this can cross ASBR. local pref and VPLS pref need to be equal - or VPLS pref of zero (intra-AS case only). Draft also discusses different models for inter-AS. 3 models (effectively the A, B, C from IP VPN). So explain how each one works for LDP and BGP. future version of draft might talk about multi-homing across ASes (so one CE connected to two PEs in different ASes). also discuss MAC flush. So if DF goes down the other PE need to MAC flush. ideally this happens implicitly, but if you have PEs that don't know about the new draft then you need to send it an explicit flush. So instead of implicitly using the updated NLRI to flush you send a MAC flush TLV. Issue with explicit flush is you may have 1000s of MACs to flush and either send a big list or just flush all MACs. please review: key points are: 1) you can do manual provisioning and still do multi-homing. 2) common procedures for BGP and LDP. Q&A 1) Albert - where is ASBR? Inside core or between CE/PE Kireeti - inside core. 2) albert - how do you do MAC switchover? Kireeti. 2 issues. How do you detect something has happened? Want to be quicker than aging. If you lose PE-CE connection you can send an update with the down bit set (or withdraw the NLRI). If remote PEs don't do anything they'll either wait for aging or wait to learn the same MACs from another PE. But for that you need the CE to send traffic into the core. If all traffic is in the reverse direction could wait for the aging timer. So for that reason you want an explicit MAC flush - which will trigger the unknown MAC flooding. Albert - so it's important for the forwarders to time out all the expired MAC forwarding tables? Kireeti - you'd need to flush the MACs you learned from that PE. The procedures for MAC flush aren't in this draft, but the draft says that "when you see a change of DF you can do implicit or explicit MAC flush". if you want to know how to do explicit MAC flush then go to RFC4761 or 4762". Shane - I didn't see explicit MAC flush in the draft. Wim - it's in section 5.1. Kireeti - please do read it and comment on it. Is it useful to keep section 5.1? show of hands as to who's read the draft. Only about 8 people! Take to list... Kireeti - who's read the 2 original docs? Also about 8 people! 4) Extensions to LDP Signaling for PBB-VPLS - (slides) Florin Balus (florin.balus@alcatel-lucent.com) http://tools.ietf.org/html/draft-balus-l2vpn-pbb-ldp-ext-00 background is that in in IETF-73 decided to break the work down into 4 areas. So we have a model draft. interop being submitted after this IETF. This is MAC flush. Scope of this draft is LDP VPLS, and aim is to reuse existing MAC flush work in RFC4762 and to be backwards compatible. Text is from the previous PBB-VPLS draft. went through the existing RFC4762 model. Showed issue of traffic blackholing when an AC goes down. So address withdraw message used to flush the faulty entry (so a re-flood will occur). issue with PBB VPLS is that we now have B-MAC entries and C-MAC entries. So going through the same example. The problem is that you don't want to flush the B-MAC (as it's still valid). Want to flush the C-MAC to B-MAC mapping. So we do a MAC flush with a new PBB TLV telling the other PEs to flush the C-MAC to B-MAC mapping, not the B-MAC. Also have 2 sub TLVs. One is the ISID, one is the source B-MAC. So indicate either one ISID, or a list of ISIDs. if no ISID then flush them all. If you have a Source B-MAC entry then can flush all the entries for that B-MAC (or all entries except from that B-MAC?) propose to adopt as WG doc. only 4 or 5 people have read this draft. All but one want it to be WG doc. 5) BGP based Virtual Private Multicast Service Auto-Discovery and Signaling -- Rahul Aggarwal (rahul@juniper.net) http://tools.ietf.org/html/draft-raggarwa-l2vpn-p2mp-pw-02 first explained P2MP PW. unidirectional P2MP service (e.g. P2MP ATM). Chartered in the PWE3 WG (has a reqs draft). then VPMS. This is a use of P2MP PWs to deliver a L2 service which carries L2 or IP multicast frames. So now we can do VPMS as well as VPWS. auto-discovery? This is in the VPMS requirements draft. Procedures are meant to apply to BGP and LDP signaling for P2MP PWEs. But at this point the LDP signaling is still in flux (work going on in PWE3 WG) so some details are missing. So this draft is only complete for BGP signaling (hope to fix in next revision). historical context is that original draft was late 2007. specified the VPMS service. But as work took off was folded into the requirements doc in this WG. Also specified P2MP PWEs in terms of forwarding/encaps. Those are in PWE3. This version of draft is now purely for A-D and BGP signalling. skipped over one slide now explained L2 multicast VPN. auto-discovery implies that sender sites need to discover receiver sites. Draft explains how this works. auto-discovery procedures enable the receivers to discover senders. PEs in the sender sites may also need to discover receivers (depends on topology). Builds on the VPLS multicast draft to do this. So BGP NLRI and MUST carry the set of RTs being exported by the VPMS. Key issue of how you map sender sites to receiver sites. Open questions still. Once resolved will define how we carry the info in BGP. so still some work to be done to really nail this down. ultimately AD is about discovering sender/receiver sites. The RT provisioned by the SP defines that. RTs advertised in the AD routes. Sender sites need to import routes from receiver sites (and vice-versa). One option is one RT each for sender and receiver sites. framework document talks about redundancy. one requirement is ingress PE redundancy (same as VPLS multi-homing that Kireeti discussed). Done by having the same CE ID on both the PEs. sImpler than VPLS multihoming for a variety of reasons. Matter of policy as to whether more than one ingress PE sends (and receivers drop packets from all but one) or if one sends and another takes over if it fails. few words on signalling. Need signalling from sender sites to receiver sites. Tunnels are P2MP PSN tunnels and use upstream assigned labels. same mechanisms as in VPLS multicast draft to assign the upstream labels. inter-AS and MS P2MP PWs again use the same principles as in VPLS-MCAST (and again can do A, B, C) but only applies when BGP is uses for signalling. Q&A 1) Kireeti - is the goal to be able to mix LDP and BGP? Rahul - goal is to do LDP or BGP, but still need work on LDP case. 2) Florin - requirements doc has a mixed case. How would you differentiate between BGP AD with LDP signalling and BGP for everything? is it just that in the former case BGP doesn't send a label Rahul - in one case the AD routes have the PMSI attribute. if that's the case then the tunnel attrribute is the signalling. if that's not there then it's just A-D. Florin - so different AFI/SAFI than for LDP VPWS and VPLS? Rahul - this is a whole can of worms. Historical context is that for VPLS AD there are two pieces. One is that for BGP VPLS the AD also carries the signaling. When doing LDP VPLS a different spec is used just for AD. But uses the same AFI/SAFI as BGP VPLS. that has caused a fair number of issues. The way things stand the AFI/SAFI for BGP VPLS and for BGP-AD for LDP VPLS are the same. Here our thinking is to use one AFI/SAFI for AD regardless of whether we use BGP or LDP for signaling. Difference here is that we're designing for BGP and LDP A-D up front. Wasn't the case with VPLS. But if it isn't feasible to have one AFI/SAFI we can split them. Kireeti - want to finish Rahul's thought. Maybe from a pure protocol point of view it's suboptimal to have AD and BGP VPLS using the same AFI/SAFI. Reason for it was to have the ability to signal one VPLS with a mix of LDP and BGP. Aim was not to have one session for AD and one for BGP VPLS signaling. Distinguish between AD and signaling messages by the length of the NLRI. That was a good thought, but not finished as 4761 was only talking about BGP signaling. One thought was to write a doc explaining how to do a draft on how AD interoperates with full BGP signaling. if we do that draft we'll show the value of one AFI/SAFI. if I'm doing BGP signaling and want to optimize multicast do I use a different SAFI? Rahul - is the same SAFI. Easier in the VPMS case. In VPLS case its kludgy to look at length to see if there are labels. In this case the signaling is in an attribute, so the NLRI can be designed off the bat to carry AD only. With a nice, clean "design hat" on we should have had different AFI/SAFI in 4761 for auto-discovery. Kireeti - I know it's kludgy, but there was a reason (interop). Need to show how to do interop. Rahul - my goal is to produce version 3 of this doc with some of this input. Meeting adjourned.