IETF 66: Layer 2 Virtual Private Network WG (l2vpn) Minutes Thursday, July 13, 2006, 1510-1610 ================================== Chairs: Vach Kompella Shane Amante 1) Administrative - Mailing list: http://www.ietf.org/mail-archive/web/l2vpn/index.html - Scribe? - Blue Sheets - Agenda Bashing No comments on the agenda 2) WG Status and Update + In RFC-Editor Queue: - draft-ietf-l2vpn-requirements-07 - draft-ietf-l2vpn-l2-framework-05 - draft-ietf-l2vpn-vpls-bgp-08 - draft-ietf-l2vpn-vpls-ldp-09 - draft-ietf-l2vpn-signaling-08 - draft-ietf-l2tpext-l2vpn-07 + draft-ietf-l2vpn-ipls-06 - Passed WG LC, (was) waiting for ARP-MED + draft-ietf-l2vpn-arp-mediation-06 - Worked with Himanshu to finish minor tweaks. Ready to go. Will issue short WG LC. + draft-sajassi-l2vpn-vpls-bridge-interop-02 - After IETF 66, need to make a WG doc, and shortly after that WG LC. + draft-ietf-l2vpn-vpws-iw-oam-01 - Mustapha: we need to add support for a new CV Type code point for BFD encapsulation without the UDP/IP header. Need to explain if one BFD encapsulation is selected, the PE needs to stick to that one. Also, we need to review how to merge status when both PW status and BFD are used for fault detection and notification. + In Progress: - draft-ietf-l2vpn-oam-req-frmk-06 - draft-ietf-l2vpn-vpls-mcast-reqts-02 - draft-qiu-serbest-l2vpn-vpls-mcast-ldp-01 - draft-hemige-serbest-l2vpn-vpls-pim-snooping-01 - draft-ietf-l2vpn-vpls-mcast-00 - draft-nadeau-l2vpn-vpls-mib-00 - draft-weillian-l2vpn-mib-00 - draft-kompella-l2vpn-l2vpn-01 - draft-ietf-l2vpn-radius-pe-discovery-02 - draft-sajassi-l2vpn-vpls-multicast-congruency-00 3) Virtual Private Lan Services (VPLS) Management Information Base http://www.ietf.org/internet-drafts/draft-nadeau-l2vpn-vpls-mib-00.txt Rohit Medirrata (rohit.mediratta@alcatel.com) Presentation: + Scope of the MIB: limited to VPLS as per VPLS-LDP draft. Does not have VPLS-BGP, yet. + List of Tables: - vplsConfigTable contains VPLS-wide parameters. Config table has e.g. timeout for how long before you time out a MAC. - vplsPwBindTable contains PW configuration. Bind table would be e.g. "PW is spoke" or "PW is mesh". + MIB Module Architecture: - VPLS MIB sits on top of both PW MIB and Bridge MIB. - PW MIB sits on top of MPLS-MIB/PSN-MIB. * VPLS MIB is a service specific MIB. So need PW MIB and PSN MIB too. Question mark on BRIDGE MIB. Not sure if MAC addresses will be in BRIDGE MIB or in an additional table in the VPLS MIB. Looking for WG consensus on that... + MIB usage. To configure VPLS service, need 3 tables: - vplsConfigTable: indexed by vplsIndex - pwTable: indexed by PW index; and, - vplsPwBindTable: uses both indexes. * PW bind table required because there are multiple PWs per VPLS. Binds from VPLS config table to PW table (from PW MIB). + Future enhancements: - Where to store MAC addresses and related information? Bridge MIB or VPLS MIB? Constraint on BRIDGE MIB is qualified vs qualified learning. - VPLS MTU (need a VPLS-wide MTU as well as PW MTU) - Not convinced we need to be able to disable MAC learning, or to discard unknown destination addresses. - Need some way to configure MAC aging. - Need to be able to configure max MACs to learn, number learned so far, etc. - Also, no definition of how to handle multicast frames. Would be nice to have options to config IGMP and/or PIM snooping. - Requirement to modify PWE3 MIB so PW can terminate on a VSI rather than on an AC, so need to talk to PWE3 WG about that. - No way of provisioning primary/standby PWs. - Bind table: * Also good if we could configure PW as spoke or mesh. * MAC address limit may be per VPLS rather than per PW, so may remove that object. - Do we merge this with VPWS or IPLS MIBs? Discussion: * Giles Heron - Concerned that we're putting feature specific stuff into the doc. If different vendors do e.g. MAC limiting in different ways then is it OK to put it at PW level or at VPLS instance level etc.? The protocol drafts don't talk about this so why put it in the MIB? Or, should we put this in enterprise MIBs? I'd like to see what others think about this. * Vach Kompella - It is hard to draw the line between objects, but it is a good thing to have a standard. If not, make it Informational. * Bruno R. - Some of the data plane objects might be common to VPLS-LDP and VPLS-BGP. Haven't read in detail so don't know if it's really specific to LDP. If so, then could we separate out the common parts so they can be re-used for VPLS-BGP in future? * Rohit - Sure, something to consider. * Kireeti Kompella - Need per AC as well as per PW stuff. Have had requests, for example, to only allow one IP per AC (to ensure there's a router there). Two things going on: 1) VPLS standard that says how to do VPLS signalling; and, 2) VPLS MIB that has features in that are implementation specific. That's not necessary for interop, yet has become part of a proposed standard. So people say "do you support this RFC"? Local implementation things shouldn't become part of proposed standard. So maybe could have normative and non-normative stuff. Not sure if that can be done in the same document. Not necessarily an enterprise MIB, but at least a separate RFC with different status. Really a question for the AD. * Mark Townsley (as AD) - Don't understand split of doc into normative and non-normative. Came up in another WG today. Don't think we have a process. So would have to split docs. If consensus of group is that implementation specific stuff shouldn't be on standards track then should split it up. * Vach - I would throw everything in there. If people think all that stuff is a good thing to have in a standard, then that's good. If not, then we'll take that stuff out and decide whether to make it informational. The problem at that point is you can't put the objects in the standard table, so you have to put them in another one. * Andrew Dolganow - There is a compliance statement in the MIB which could be used and keep both in the same document. * Mark - I'll do some homework on this. Don't want to saddle WG with splitting docs/MIBs if there's no need. * Kireeti - If there's consensus that this is important then, let's put them in, but not if different vendors do stuff in different ways. * Mark - seems like we're agreeing, but we need to figure out the details. * Bill Fenner - You can use the compliance statement to manage mandatory and optional objects in the same MIB. If it's on a device that can do "foo" then this group is required to manage the foo. All in descriptive text, not machine readable. One big MIB with optional sections to manage features you may or may not be able to do is OK. * Mark - There's no issue about stuff that is pseudo-vendor specific being in a standard doc? * Bill - It's feature specific, not vendor specific. 4) PIM Snooping over VPLS http://www.ietf.org/internet-drafts/draft-hemige-serbest-l2vpn-vpls-pim-snooping-01.txt Venu Hemige (venu.hemige@alcatel.com) Presentation: + Background: - Specified procedures for PIM snooping which required Join- Suppression to be disabled on CE routers to provide multicast service. Not practical. Feedback from Vancouver was it was more important to have operational transparency than LAN transparency -- so it must work even if Join Suppression is disabled. PIM proxy scales better anyhow, and scaling is important. + Updates: - Addressed comments from Yiqun and Ali. - Specified procedures for PIM snooping and PIM proxy. Procedures for snooping and proxy are very similar, so doing one or both is almost the same complexity. Recommending that implementers do both. - Re-organized draft, so it is now mostly in plain English! + Follows a description of PIM snooping and PIM proxy procedures, using an example. - Example of PIM snooping. PEs send joins via LDP as well as flooding in the VPLS, (to avoid snooping on PWs). - Example of PIM proxy. PE consumes the join and then sends it via LDP. So now the remote PE has to proxy the join. - Either way data traffic follows the snooped path. - Proxy scales better as no flooding of PIM joins. + Comparison of the two: - Perceived issue about complexity of this. In fact, this is just a subset of what a PIM router does. Complexity limited to hellos and joins/prunes, (no issues about BSR's etc). - Control and data planes separated for both SM and BIDIR, (unlike PIM-SM routing). Data plane is the same as PIM router. - Snooping and proxy together provide operational transparency and should be easy to deploy. + Next Steps: - PIM-snooping on ACs is important to make VPLS multicast work. - Draft addresses "Issue A" in requirements draft. - Draft is generally in reasonably good shape so time to decide whether or not to adopt it as a WG doc. Discussion: * Kireeti - You don't need this to make multicast work, it just makes it more efficient. Also, what do you mean by "operational transparency"? * Venu - You don't need to require CEs to do anything different from what they do today. * Kireeti - So snooping provides operational transparency? * Venu - No, because it requires Join Supression to be disabled. * Kireeti - I recall from the last discussion that proxy doesn't work with authentication. * Venu - Agreed * Kireeti - So, you should put that somewhere. * Toerless Eckert - I would like to state that the statement about snooping/proxy being a subset of PIM router is not accurate. It is a subset in that you don't need a PIM router. If you don't know the group mode that a PIM Join belongs to then you can't achieve the same traffic efficiency as you get with PIM, (since don't have same knowledge). Need to know if Group is BIDIR, SM or SSM. Not saying you need it; after all even flooding will work fine. It can be a subset if you don't want as much constraint of the traffic. * Venu - I don't understand. * Toerless - Tree building in PIM is different for different tree models so can't constrain the tree unless you know that. * Venu - I think you can. Don't need to know if group is BIDIR or not. All you need is to do an RPF to add the interface to the OIF. * Yuji Kamite - Seems like there are two separate procedures here for snooping and proxy. Do SPs have to choose between them? What limitations are there in each procedure? Does the SP have to configure some additional stuff to make them work? * Venu - SP doesn't have to pick one or the other. If join supression is disabled in the VPLS, then it doesn't make sense to do proxy. PE should be able to figure that out and then do snooping or proxy. * Yuji - What happens when one VPLS instance is doing proxy and in another snooping? * Venu - It's not a config thing. All PEs will see the same thing since they are snooping on the same hellos and will agree with the same behavior. * Yuji - I think it's best to clarify this. * Yakov Rekhter - In the proxy scheme does the PE only send the Join towards the source? * Venu - If there are receivers elsewhere they will send their own Joins. * Yakov - You're suppressing joins in the backbone? * Venu - Yes * Yakov - So, aren't you losing some of the scalability of join suppression? * Venu - If Join are suppressed, then traffic won't get forwarded so multicast won't work. * Shane - How many have read the draft? About a dozen. * Shane - How many support making this a WG doc? About a dozen. * Shane - How many do not support making this a WG doc? No one. * Kireeti - Which category is this draft? * Shane - Informational. * Shane - OK, will take it to the mailing list. * Shane - OK, we're done. WG meeting ends.