IETF 68: Layer-2 Virtual Private Network WG (l2vpn) Minutes Wednesday, March 21, 2007, 1510-1610 ==================================== Chairs: Vach Kompella Shane Amante 1) Administrivia No comments on the agenda 2) WG Status and Update + Two new RFC's: - draft-ietf-l2vpn-vpls-bgp-08 --> RFC 4761 - draft-ietf-l2vpn-vpls-ldp-09 --> RFC 4762 + In RFC-Editor Queue: - draft-ietf-l2vpn-signaling-08: Held on Norm. Reference to draft-ietf-pwe3-segmented-pw + Passed WG Last Call, will send to IESG: - draft-ietf-l2vpn-vpls-mcast-reqts-04 - draft-ietf-l2vpn-vpls-bridge-interop-01 + draft-ietf-l2vpn-ipls-06 - Waiting for ARP-MED. + draft-ietf-l2vpn-arp-mediation-07 - Agreed to changes to support v6. Waiting for updated draft. + draft-ietf-l2vpn-vpws-iw-oam-01 - Need to sync up with pwe3 message mapping I-D. + draft-ietf-l2vpn-oam-req-frmk-08 - In WG Last Call. Last Call ends Friday, March 30. Please send comments to the list! + VPLS MIB - Excellent progress on the MIB, since last IETF. - New draft incorporates VPLS-LDP, VPLS-BGP and generic components. - Last major component is to how to support bridge MIB per VPLS. Tom working on how to solve this problem. Hoping he is able to publish a proposal in the next few weeks. + Multicast - Solutions: several drafts out there. Need to take a closer look at them and would like to progress them by next IETF. + Expired Drafts - draft-ietf-l2vpn-radius-pe-discovery-02 - draft-ietf-l2tpext-l2vpn-07 3) UPDATE: LDP Extensions for Optimized MAC Address Withdrawal in H-VPLS http://tools.ietf.org/wg/l2vpn/draft-pdutta-l2vpn-vpls-ldp-mac-opt-02.txt Pranjal Dutta (pdutta@alcatel-lucent.com) Presentation: + Rationale: - Flush all MAC's for a corresponding VSI behind a specific PE * For SS-PW and FEC 128, Identifier = PE Addr. * For SS-PW/MS-PW and FEC 129, Identifier = AII - Benefits: prevent unnecessary re-learning and hence flooding. + History - Proposed optional TLV for FEC 128 in LDP MAC Withdrawal Message with empty MAC List for optimized/selective flushing in H-VPLS. + Updates in 02: - Extended optional TLV definition for FEC 129. - Now applicable with both FEC 128 and FEC 129 in LDP-based MAC Withdrawal. + Benefits: - Faster Convergence. - Fewer MAC's need to be relearned. * With H-VPLS full-mesh of N peers, MAC flushing happens on N-1 PWs. * With this method, MACs from a single PW can be flushed. + Next steps: - More discussion on mailing list and comments from WG. - Request for making it WG doc. Discussion: * Ali Sajasi - This is a nice way for optimizing MAC withdraw, but is it really needed, given that most boxes can do it today without any traffic hit. Is there any vendor or provider that thinks MAC flushing is an issue? * Pranjal - We have requirements for this from providers. * Marc Lasserre - It is true in PBB network, optimization would be automatically gained from PBB. But not everyone has PBB. There are implementations that might be able to handle MAC withdraws at wire speed, but that is not the problem we are solving. * Ali - Want to add that MAC flushing doesn't affect re-convergence, re-convergence is a RSTP issue and MAC flushing is a data plane issue. If flushing can be done at line rate, then this is not an issue. This happens only during failure and that's once in a blue moon. Do we really need such an optimization? * Pranjal - If you have 10,000 VSI's and multiple PW's fail at the same time, then we will have this problem. * Ali - Even in that case, all MAC's will have to be flushed. But flooding does not happen at the same time. That takes place over time and that is Poisson distribution. * Marc - We are not making an extensive change, we are just adding a new TLV to optimize something that can be optimized. 4) VPLS Interoperability with Provider Backbone Bridges http://tools.ietf.org/wg/l2vpn/draft-sajassi-l2vpn-vpls-pbb-interop-00.txt Ali Sajassi (sajassi@cisco.com) Presentation: + If a Provider needs to summarize MAC address due to scalability issues and wants to use 802.1ah, then what are the issues? + Limitations: - MAC addr. scalability at n-PE, (since MACS are aggregated at n-PE for its set of VPLS instances). - PW scalability since they need to be maintained per VSI per customer. + Proposal: - Use 802.1ah with H-VPLS * Scale # of MACs at n-PE * Scale # of PWs * Scale # of Service Instances in Ethernet access - Two Scenarios: * H-VPLS w/ 802.1ah access network * H-VPLS w/ MPLS access network + Definition of "Admin Domain" - Same admin domain = same I-SID space - Diff. admin domain = diff. I-SID spaces, (therefore I-SID translation is required) + From VPLS perspective there are two configurations - One configuration where PE is in same Admin Domain at Access Network * In this case PE can be directly connected to the Backbone Bridges, which is a regular .1ad bridge. Here operation does need the more expensive .1ah bridge. - Type 1: B-VID is service delimiter. - Type 2: I-SID is service delimiter. - Second configuration is PE is not part of the same Admin Domain * In this case PE connected via I-Tagged service intf to B-BEB. * PE devices may include B-component if I-SID processing is needed. - Type 3: I-tagged service intf with I-SID as service delimiter * 3 modes: - Port mode - I-SID mode - I-SID bundling mode * If I-SID translation needed, then can be performed according to 802.1ah spec. + Next Steps - WG to review and give feedback Discussion: * Florin Balus - I thought this was supposed to show how PBB and VPLS were supposed to work? * Ali - This wasn't supposed to be a framework document, it was supposed to be a solution document. * Florin - ? * Ali - PW Type would be needed when different access network are part of different admin domains. If they are part of same domain, you don't need I-SID delimiter. * Florin - Where would the PW type be needed? * Ali - The PW-Type would be needed for translation, so that the PE knows what processing to do at the end point, just like on Ethernet frame you need to know what to do with Tag mode and Raw mode. * Marc Lasserre - I would like to understand the extra complexity required to do MAC hiding? The simple idea would be to just do MAC-in-MAC. * Ali - The question is the model you are talking about. With PBB you have to use ... with ...., with MPLS aspect you don't need to do this. * Marc - There is a PBB domain that needs to be managed by typical MPLS OAM capabilities. I still don't understand it. * Ali - That will become clear with future contributions. Meanwhile, you can look at class 25 scenario. * Marc - Are you saying that we should use Ethernet OAM for debugging? * Ali - That is an option. This is only about 4 bytes. We need these 4 bytes for ... Why not keep it consistent? * Marc - Why carry these bits when we don't need to? * Ali - We will see that when we reach fault management. * Marc - Are you saying that we should use Ethernet OAM for debugging irrespective of the technology on top? There already exists MAC ping, MAC trace. * Ali - Where is it documented? It's only in your implementation. * Shane Amante - Can we take that to the list? However, this is an important point. Your assertion is I-SID translation is a requirement for inter-domain applications. Speaking as an SP, not as chair, I can't see the need for I-SID translation. Can you ask the providers who want this to speak up about this requirement? Any type of translation will be complex to manage & maintain. If we can avoid it, we should. * Kireeti Kompella - VLAN translation is a local function, it's not signaled, what is magical about this? * Ali - Yes it is, but you need to know what type of operation to do. * Kireeti - So are you just going to translate? * Ali - Yes. * Shane - Let's take this to the list, since we're running out of time. 5) Layer 2 Virtual Private Networks Using BGP for Auto-discovery and Signaling http://tools.ietf.org/wg/l2vpn/draft-kompella-l2vpn-l2vpn-02.txt Kireeti Kompella (kireeti@juniper.net) Presentation: + Pre-Dates VPLS-BGP + Reuses 4364 concepts - RD to make routes unique - RT for topology + What's new in BGP? - New NLRI * Contains RD and site ID * Also contains a label block - Only difference from 4761 (VPLS-BGP) is the TLV that contains a "Circuit Status Vector". + Other Extensions - Extended community L2 info to carry PW encap and other info. - Same as with VPLS-BGP, but with new encaps types. + Changes to Document - Since it predates BGP VPLS, this doc had all BGP format and processing information. - RFC 4761 referred to this one - Situtation is now reversed * Almost all BGP info is in BGP VPLS RFC + Where are we? - We now have a doc that says how to use BGP extensions for auto- discovery and signaling and is defined in 4761. Minor changes to processing, encaps types & data plane procedures here. + Next Steps - Liase with IDR as there are no serious changed, but let them decide - Change the author from kompella to ietf. - Make it an L2VPN doc. Discussion: * Ali Sajassi - In 2547, AS'es are independent and no coordination between AS's is required. In this case AS'es need to be coordinated. * Kireeti - What if we had two AS's with two IPVPN's and 10.1.1.1 was used in both, now you merge the two VPN's, then what happens? * Ali - In one case you are talking about customer addresses in the other case it's a Provider configuration that need to be changed. * Kireeti - You have to re-number in either case. However, keep in mind the current L2VPN charter is restricted to a single AS. * Ali - Thats why no other vendor implemented BGP signaling draft. * Kireeti - If Site-ID's are different the vendor has to reconfigure regardless, and we understand that it's a problem. Inter-AS is in the future. * Shane - Inter-AS is not in the charter. * Ali - The draft talks about inter-AS. * Kireeti - I thought I removed all inter-AS references, but if it still has them in there please let me know and I will remove them. * Yakov Rekhter - I am surprised that you have raised this now, and not before this. * Dave McDysan - This is an old old draft, but it does work ... Two other features would be nice in there ... the second is it would be nice to have a traffic management parameter ... * Kireeti - Wouldn't you want to do that on the PW itself? * Dave - ??? * Kireeti - Would it help to have a use case, for example, a hub and spoke kind of situation? * Luca Martini - I am trying to figure out why this draft is reappearing now? The original draft was proposed something like 3-4 yrs ago. So, I would like to propose this be an informational draft like we have done for other docs in PWE3 that have been superseded by standards drafts. * Kireeti - It is a separate document, making it an informational draft doesn't help. It should be Standards Track. There are actual extensions here that can't be Informational, this has to be Standard.