IETF 72: Layer-2 Virtual Private Network WG (l2vpn) Minutes MONDAY, July 28, 2008, 1520-1720 ================================ Chairs: Vach Kompella Shane Amante 1) Administrivia 2) WG Status and Update Agenda Bashed WG Status: See slides. 3) Setting Boundaries in L2VPN Vach Kompella, Shane Amante - What are the things happening in IEEE that should be worked on in IETF? If VPLS emulates an Ethernet, then IEEE protocols should: a) Just work -- no need for IETF drafts; b) May not work -- need Applicability Statement (AS) draft c) Work, but not efficiently -- need AS draft or protocol modifications; d) Don't work at all -- need AS draft or protocol modifications. - Concerns include: + PBB and VPLS interop; + IEEE OAM (802.1ag); + NSP functionality (802.1ah PW) affecting VPLS. - Question: Is VPLS architecture described well enough that we can identify which protocols in IEEE fall into one of those four categories? - What should we do? + Define some rules of admission of variants of IEEE functions, or protocols into L2VPN WG. + Not to say that all drafts submitted shouldn't be in L2VPN, but that we need a set of rules for what kind of work should and shouldn't here. + Suggest we require text that justifies the problem being solved and why it's needed here, (e.g.: native behavior is inadequate for the following reasons ...). + Also, need some oversight from the WG whether a draft is just repeating a protocol in IETF, or if it has some modification to VPLS behavior that requires explanation. - Concerns + It concerns us that the IEEE does not oversee what happens here, with respect to restatement of or modifications to their protocols. + Without that oversight, we need to be sure that when we change protocols and behaviors in L2VPN (in IETF), that it will not break what the IEEE has already done. + Have been a lot of emails on mailing list, but there are a lot more people in this room than have spoken on list. We would like to have wider discussion among all members of the WG. Questions: - Ali Sajassi: From last point first, I think no modification to protocol should be committed in here because we don't have expertise. Second, with respect to modeling the VPLS, LAN emulation as such when it interacts with IEEE is either going to discard some protocols, terminate, interoperate or pass transparently. We won't be concerned with first and last, and effort has to be made to keep it that way. But, certain control protocols because we are doing LAN emulation, need to terminate and interoperate, and this must be described. With respect to VPLS model, we picked the model 7 years ago. Based on that model, if the question is about LAN emulation, then to what extent do we want to get into that? If we want to model everything as just a bridge module connected with pseudowires, we can do that. Is that the direction you guys want to go? - Shane: That may be a direction we need to evaluate. However, the chief concern right now is the longevity of the current architecture of VPLS. Decisions were made in past that led us to this juncture, but if we're not clear on where the line is drawn between IETF and IEEE protocols, then perhaps we haven't been as clear as we should have been. - Ali Sajassi: Modeling connected with pseudowires is wrong model. The reason we didn't go with that model is we didn't want to run GVRP and MSTP over it, so we ended up with definition of pseudowires for every service and having split-horizon. So, there have been certain reasons why we picked that model, and after 7 years that model has been gone through so many different discussions, and has been captured in the framework doc. At this point we need to identify certain issues, see if those issues have been captured in VPLS interop or see about extending the WG charter to improve on what we've done. - Vach: We didn't say we wouldn't allow any protocols or modifications here, because our emulation is imperfect. We don't want drafts here for protocols that just work. This is about writing some rules about how we judge whether the work we bring into L2VPN WG is the right kind of work for the IETF to be working on. - Ali Sajassi: In a sense we say the same thing. There are drafts we don't need to work on here. But, to be able to deliver an end-to-end service, in certain scenarios where we need to interop with those protocols, those need to be described, and also what do we expect from the IEEE bridge model. "What" not "how" -- job of "how" is in IEEE. "What" is important so we can ensure integrity of end-to-end service. With respect to the model, question is, are we introducing drafts that talks about scenarios that lead to concerns? If there are scenarios we think we don't need to consider, let me know and we take it out and reduce those scenarios. If you want to look back and define VPLS model, which we did 7 years ago, then I object to that. That has been discussed rigorously, and has been the basis of everything we've done so far in L2VPN WG. - Vach: So we should never reconsider what we've done? - Shane: Why did IETF standardize IPv6? Wasn't IPv4 "good enough"? - Vach: The question is do we have good enough description of the architecture? We now have 7 years experience. It is OK to say we didn't describe this part well enough, so it gives us a better clue on how we take decisions about what happens in IEEE vs. IETF. - Ali Sajassi: Just for OAM aspects, we spent 2 years talking about the model. - Shane: The OAM solutions draft should just be applicability statement about what's unique about 802.1ag in a VPLS environment, i.e.: where to place MEP's and MIP's in a VPLS PE. - Don O'Connor: I support sprit of Ali's comments. I think this proposal limits some things that we define for proper interop, and I don't see anything wrong with existing drafts, I think this is just a way of limiting the content of those drafts and would do a grave disservice to the industry. - Marc Lassere: Last point, I think it's not about whether we want to discuss interop between IEEE and IETF protocols. It's about specifying the scope of this work. From Day 1, the architecture of VPLS hasn't changed. It's a transparent service, set up so that IEEE protocols weren't required as part of the setup process. It's been conceived from Day 1 such that VPLS forwarding was completely agnostic to bridging. VPLS forwarding has implications for OAM, but there are still contentious issues. There are bridging and OAM aspects that require specific functions. So we need to retain the transparency, and need to maintain applicability statements for the boundaries between bridging and forwarding. We should remain completely agnostic to the data plane format. - Stewart Bryant: As a set of principles, you do your best, if your best isn't good enough, describe limitations in an applicability statement and live with them. It gets difficult if you try to usurp IEEE functionality or move it into VPLS. If we need to start to interleave in IEEE protocols, we should only do it in an explicit joint project with IEEE to make sure what we're doing is absolutely correct. - Shane: Would like to take this conversation to mailing list. Would appreciate comments on the best path forward. We need to define clear boundaries in what we are and aren't going to do. What does that require us to do going forward so that we're not overstepping our domain of expertise. 4) VPLS MIB: CANCELLED http://tools.ietf.org/html/draft-ietf-l2vpn-vpls-mib-02 Rohit Mediratta (rohit.mediratta@alcatel-lucent.com) 5) Multi-homing in BGP-based Virtual Private LAN Service http://tools.ietf.org/html/draft-kompella-l2vpn-vpls-multihoming-01 Bhupesh Kothari (bhupesh@juniper.net) - RFC4761, Section 3.5 describes multihoming, but lacks details on path selection and Inter-AS. This draft addresses these and doesn't add anything new. - Overview given of multihoming problem. Customer site multihomed to two PE routers; only one PE should be Designated Forwarder. All VPLS PE's must elect the same Designated Forwarder. Nothing in signaling that says how to select DF. When remote PE's figure out route, they apply a set of tie breaking rules to select one or the other. This draft describes the tie breaking rules. - Also, consider if there was a route reflector, and the Route Distinguishers assigned on PE1 and PE2 are different, from BGP perspective the routes received from PE1 and PE2 would look different, since RD is part of the prefix, so RR would send routes onward and PE3 and PE4 would make decision. But, if they're assigned the same RD, they'd look like the same routes to BGP path selection algorithm. So, you can have two types of path selection, one done by BGP path selection and another one done by by VPLS path selection. - Changes in -01 version: + Site Preference -- Might want to limit one PE as DF. + Multi-homing & Inter-AS -- There are three options in RFC 4761: * Option (a): simple back to back, no changed required; * Option (b) and (c) which cross AS boundaries. - Site Preference: + RFC4761, Section 3.5 proposes to use LOCAL_PREF as a way to indicate preference for a given VE. LOCAL_PREF is not carried across AS boundary, so version -01 proposes new Ext Community to carry VE preference. - Description of Inter-AS Option (b) given, showing requirement that any LOCAL_PREF received by ASBR is written into a Site Preference Ext Community. For backwards compatibility, we always have to take care of PE's using LOCAL_PREF for path selection. - Shane: Can we ask for show of hands on who has read the draft? About 10 people raised hands. Kindly request for more to read it. Questions: - Wim Henderickx: If you have two CE's multihomed to both PE's, is it correct that both PE's have to allocate two labels from the Label Block? - Bhupesh: There's only one pseudowire in a pair of VPLS PE's. Even if you have two customer sites, you only advertise routes for one site. There might be topologies where you create two customer sites. Let's assume CE1 in this picture is site 1, and you have another customer site connected to PE1. You'll assign different Site ID's to both customer sites. If the link between CE1 and PE1 fails, PE2 will become Designated Forwarder for CE1, but PE1 will remain active for the other customer site, because it's a different site. When the link fails, you create a new pseudowire. - Wim Henderickx: So how is MAC flush working, because you need a different MAC address on a different pseudowire and different PE. - Bhupesh: When pseudowire from PE1 to ASBR1 goes down, PE1 is no longer Designated Forwarder. It will flush all MAC's. In simple scenario that works as soon as pseudowire went down. - Wim Henderickx: Can you clarify that? I read draft and was concerned that it had multiple label allocations on a given PE, and other remote PE's would have to learn different MAC addresses from each pseudowire. - Bhupesh: Consider case where you have just single site, there is no problem. When there are multiple sites, there are different cases. When pseudowire goes down, you flush everything from given PE, and you have to re-learn all MAC's for customer sites that were behind that PE. I'll address these concerns in the next revision of the draft. - Luca Martini: Can you find a better solution for avoiding loops in this design? I think that this solution isn't viable because you can't prevent loops in an acceptable manner. - Shane (co-chair): Please continue discussion on the list. 6) Framework and Requirements for Virtual Private Multicast Service (VPMS) http://tools.ietf.org/html/draft-kamite-l2vpn-vpms-frmwk-requirements-00 Yuji Kamite (y.kamite@ntt.com) - VPMS is Layer 2 service that provides point-to-multipoint connectivity. + VPMS recently added to L2VPN WG charter. + PWE3 WG also added P2MP PW's to its charter. - This draft introduces service framework and becomes base reference for solutions work by specifying functional requirements. - Three use cases enumerated: ethernet, ATM and TDM. - Basic reference model shown. - Requirements summary shown. + Section 2, customer requirements + Section 3, provider requirements - Must support multiple sender topologies in one VPMS instance. - Reverse traffic support: Every AC is considered unidirectional. In some scenarios, you can set up another VPMS instance for reverse traffic. - Auto-Discovery SHOULD be supported to minimize amount of configuration the SP must perform. - Also, SHOULD provide a way to activate/deactivate the administrative status of each CE/AC, and SHOULD allow single-sided activation at a sender PE (for centralised control). - Next steps: + Some remaining major work, e.g. on OAM and security. + This draft is being coordinated with P2MP pseudowire reqmt's work in PWE3 WG. + Propose to adopt as a WG document, to have consensus on basic framework for VPMS service. Questions: - Cao Wei: CE2 doesn't send any traffic? - Yuji: CE2 is not joining any VPMS instance. For Auto-Discovery, PE2 has no configuration to accommodate CE2. In this figure CE1,3,4,5 are configured as a minimal VPMS instance. - Cao Wei: All CE's in diagram on slide 9 receive traffic from sender? - Yuji: After initial configuration, if CE1 sends traffic, then it will be duplicated and CE3,4,5 will receive it. This figure shows after that the operator deactivates (in terms of administrative status) AC4 to CE4. This is not a fault condition. So, this kind of operation must be considered appropriately. - Shane (co-chair): Please continue discussion on the list. 7) Optimizing MAC Address Operations in VPLS with Redundancy http://tools.ietf.org/html/draft-jiang-l2vpn-vpls-mac-operation-00 Jiang Yuan-long (yljiang@huawei.com) - MAC Address Withdrawl + PE sends LDP Addr Withdraw message to peer PE's. * With empty MAC address list, all MACs are flushed except those learned from PW over which the message is received. * With list of MAC's, only the specified MAC's will be flushed. - Motivation for further optimization + MAC flushing and re-learning slows down topology convergence and introduces more traffic bursts to MPLS core with Layer 2 flooding. - Propose optimized MAC operations: + MAC address switching. + MAC address notification. - Benefits: + No MAC addr flushing/re-learning + Fewer Layer 2 frames flooded in MPLS core - Next Steps: Request more WG feedback on mailing list. Questions: - Ali Sajassi: What do you think will be faster convergence? When you flush MAC addresses, the learning is done in data plane at wire speed. Why does that prolong convergence time? - Jiang: All frames will be flooded across core. - Ali Sajassi: That doesn't affect convergence time, it just consumes more bandwidth. Second question: you consider a simple case with simple backup for primary. In cases where primary fails and traffic gets distributed among multiple PE's, how do you take care of that? - Jiang: ??? - Ali Sajassi: I will take questions to the list. - Marc Lassere: There is already an existing proposal, (draft-pdutta-l2vpn-vpls-ldp-mac-opt-03), so I'm not sure what the benefits are vs. what has been proposed already to only flush relevant MAC addresses. - Jiang: You mean Optimized MAC Withdrawl draft? The MAC flushing is restricted to just VPLS spoke PW's. - Marc Lassere: In the proposal made, the PE-id is used to find out what the MAC addresses are to be flushed. So, instead of blindly flushing, it's not an empty list, you only flush the ones behind the PE that failed. This is as optimized as can be. The second point is I'm a bit worried that you're suggesting to switch MAC addresses. You don't want to create a new learning engine in VPLS, you want to learn from data plane as they come. You don't want two FIB's, because you got some LDP-based message. - Shane (co-chair): We have several more presentations, so can you take this to list? 8) VPLS Extensions for Provider Backbone Bridging http://tools.ietf.org/html/draft-balus-l2vpn-vpls-802.1ah-03 Vach Kompella, on behalf of Florin Balus (florin.balus@alcatel-lucent.com) - I'll be working with Florin to restrict this to what's required in the WG. - As part of rechartering we wanted to address scaling issues in VPLS, and one is the explosion of MAC's and how to aggregate services so we don't have that issue. - Florin presented earlier version of his draft, so this is addressing changes made since then: + Reusing existing VPLS forwarder modules + Focused on VPLS control plane extensions - Changes in -03: + Feedback addressed, questions on PBB-VPLS reference model. + Separate VPLS addressing for customer and backbone switching domains + New section on NSP capabilities code points + Details of required extensions to VPLS MAC Flush - Two diagrams showing that in VPLS context you could have explosion of MAC's and how it would be solved if you have PBB. I-VPLS (Customer VPLS) aggregated into B-VPLS (backbone/infrastructure VPLS, switching on Backbone MAC's). - It's possible to have both I and B component right at egress point into the PBB-VPLS service. It looks like you need a .1ah pseudowire if you're using this approach, but the B-node would be just a regular pseudowire, it doesn't even have to know about the Ethernet encapsulation. But the other endpoint of the pseudowire from a logical point of view would be PE4. We don't need a pseudowire that has knowledge of the Ethernet encapsulation inside it. - One thing we probably don't need at all in the draft, is saying that Auto-Discovery will probably just work. - Something we probably do want, or at least should be discussing, is how we do a MAC flush if we use this model. Issue is, we have a failure of a link for an I-component, and a bunch of VPLS services are being backed up on another PE. So, we get a MAC flush when the link comes up. We send a message, "withdraw everything except that which you learned from me." - Shane (co-chair): [Commenting on slide "LDP MAC flush for regular VPLS"] In the future, we need a very brief applicability statement as to why this is necessary, and then why this particular piece is causing us to re-consider how we do MAC flushing for PBB-VPLS. - Vach: Then, when we get a MAC Flush from PE3 to PE4, which wipes out its entire MAC table, because PE4 has no context about why it was necessary. So, if we do something better than MAC flush, which is providing some context in the MAC flush itself, saying what the B-MAC is, that's relevant to the whole thing, and PE4 will wipe out from its table just what is relevant. That's the kind of thing we might consider because we invented the MAC flush in this group and want to see how we can optimize it in this context. Some of the other stuff about how PBB works and how VPLS works, I don't think we need to bring all that stuff back in here. - Next steps: + Discuss differences between existing PBB-VPLS drafts + Decide whether we need a different PW type + Consolidate the contents into one draft, if possible; and, + See if there is anything else we need to do in IETF to make PBB-VPLS work. Questions: - Ali Sajassi: So what parts do you not agree with in this draft? - Vach: I don't agree with some of the stuff in the draft, because some of it you have to read & understand existing drafts, RFC's and IEEE docs. We don't need to bring all of that back in here. - Shane (co-chair): It should be obvious to the implementer/reader that C-MAC flushing is an important component of PBB, hence we need to account for it within the IETF, given the current architecture of VPLS. - Ali Sajassi: So, can you tell me why PE3 needs to be involved in the C-MAC flushing given that C-MAC's are transparent to PE3? - Vach: PE3 would have to propagate the MAC flush, but would not be involved in doing anything. - Ali Sajassi: Now, if you don't mention in the B-component that this should be transparent, that point is going to be missed. - Shane (co-chair): This has to do with forwarding an LDP message from one LDP session to another at PE3. - Ali Sajassi: You'll see there'll be issues, that I'll present in my timeslot. What's important to understand is C-MAC are only visible at the edge of the network, and flushing C-MAC addresses is completely different to flushing B-MAC addresses, and these should not be confused. With B-MAC, every node is involved; with C-MAC it's only limited to the edge. - Shane (co-chair): Yes, and those details should already be within an IEEE spec. - Ali Sajassi: We're trying to say what PE devices in an end-to-end model needs to worry about C-MAC flushing. - Vach: We don't need to repeat work already completed by the IEEE. - Ali Sajassi: Agreed. - Shane (co-chair): Overall, we want to make forward progress and not re-hash work from the IEEE. - Ali Sajassi: One other procedural aspect, both chairs are co-author of single draft in this area. How does that affect their objectivity? - Shane (co-chair): If it's a matter of co-authorship on the draft in PWE3, I'm more than happy to remove myself, but I can't guarantee that'll change my personal opinion. - Mark Townsley (AD): It's never a good situation when we have two co-chairs offering a document. It's pretty obvious that objectivity can be called into question. That said you're allowed to have agreement on architectural direction. If Ali is asking for us to have a substitute co-chair sit in here for the discussion on these particular documents, maybe that's the right thing to do for this particular item. Maybe I could do that, but I'd rather not because I have other things to do, but he's right that there might be a procedural issue here, and we don't want to set ourselves up for getting stuck, because nobody's operating in that chair position. - Vach: I can also take my name off the draft. - Mark Townsley: I think it's deeper than that. We want an objective chair to look at something if it's a controversial aspect in the WG. - Danny McPherson: I just want to observe that I don't see any unobjective behavior. If someone would demonstrate it, I'd be delighted to make that recommendation, but I hope it's explicit before someone does make that recommendation. - Mark Townsley: Ali started making that assertion, but we haven't seen consensus on whether it's happening, and we wouldn't act until we had. - Alex Zinin: Objectivity of the chairs should be exercised in judging the consensus of the WG, not in the contents of the drafts. 9) VPLS OAM http://tools.ietf.org/html/draft-mohan-l2vpn-vpls-oam-00 Ali Sajassi, on behalf of Dinesh Mohan (mohand@nortel.com) - Status report: + Good agreement that draft covers VPLS monitoring using Ethernet OAM + Agreement reached to include VPLS PE model that had been implemented in L2VPN framework, but needed to be expanded for VPLS OAM. + WG draft had nice consensus in the room at Philadelphia. - Updates from -00 to -01: + Updated status of draft to informational, as per WG request. + VPLS/H-VPLS PE models, to describe how PE models are used for OAM monitoring, is included in 4 figures. - Next step: + This draft got submitted to be accepted as WG draft, as agreed in Philadelphia. + Continue work on VPLS OAM, addressing feedback, comments. Questions: - Shane (co-chair): The first question I'd like to ask WG is does this doc represent a unique body of work, in other words an Applicability Statement related to what's unique to 802.1ag in a VPLS environment? - Shane (co-chair): Sorry, let's back up. How many have read this document? Room showed roughly 15 - 20 hands. - Shane (co-chair): How many say this represents something unique to implementing 802.1ag in a VPLS PE? Room showed approx. 4 hands. - Shane (co-chair): I am concerned that this draft doesn't identify the unique aspects to running .1ag in a VPLS environment, specifically where MEP's and MIP's must be placed in a VPLS PE. I do observe that the WG believes that 802.1ag/Y.1731 are good protocols that will likely be widely used for diagnosing and troubleshooting problems in an Etnernet environment, given that 20 people have read this draft. Unfortunately, at this point, people aren't going to know how to implement 802.1ag in a VPLS PE based on the current contents of this draft. While we can ask WG to accept this as WG document "as-is", my concern would be, based on the poll of the room, that it would need to undergo substantial changes to describe what's unique to 802.1ag in a VPLS PE. - Ali Sajassi: You talk about uniqueness. We've been talking about .1ag capability for VPLS OAM for 4-5 years, when we started discussion of OAM requirement and framework draft. The important point is to describe how .1ag is applicable in VPLS, and we've gone into a great deal of details to talk about VPLS model for VPLS and H-VPLS, how it meets the requirements specified in the OAM requirements and framework draft. Considering that this is an Informational draft, and considering that it describes exactly a solution for VPLS OAM, and considering we had consensus in last meeting I wonder why we keep going over this? - Shane (co-chair): The larger concern is people already know, or should know, what are 802.1ag Loopback, LinkTrace, etc. messages, so we don't need to re-hash them in this draft. However, what people want to know is how .1ag applies to a VPLS PE? - Ali Sajassi: It says how you define them at what point in the segment. Maybe you have all this depicted in your mind, but a lot of people need some help as to how all this works together. - Vach (co-chair): Did you give us an implementation guideline, or a new protocol? Just before Thomas (Narten) stepped down as AD, he had the same concerns, and Joel Halpern said none of this stuff needs to be done in an IETF draft. At that point no one listened, so we kept going down this path. What has been expressed by the WG is that 802.1ag is useful, and that doesn't mean we should not work on how it applies to VPLS. - Ali Sajassi: So how do you know what MEP's to use? - Vach (co-chair): That's an implementation detail. - Shane (co-chair): Why can't people read .1ag and find out what Maintenance End-Points and Levels to use? - Ali Sajassi: How do you know how to put which components along the end-to-end bridges. This is an Informational draft. It's written to help the WG in terms of applicability of .1ag to VPLS. Prior to this people were saying we had to go do something else, but if something exists, then we need to describe it. - Dan O'Connor: So are you saying that the industry doesn't need a standard on how to do Ethernet Service OAM when VPLS is used to provide that Ethernet Service? I think you should be asking a different question. - Shane (co-chair): To be clear, I did not say that .1ag is not a good solution for troubleshooting an Ethernet Service, nor that it's not applicable to VPLS. I am saying: we don't need to copy 802.1ag, when standards documents already exist that describe its details. However, what people want to know is where one needs to implement 802.1ag relative to a VPLS PE. - Ali Sajassi: We discussed for 18 months on the model and we talked about MEP's and MIP's. That is described in this document. - Shane (co-chair): Right, and those details should be in an Applicability Statement, not "here's what a Loopback Message does". - Ali Sajassi: All we've done is 1 or 2 sentences, referencing to the corresponding section of the IEEE/ITU document. If we didn't do that it would have been doomed in terms of the framework and requirements, since there is no pointers on how they are being met. - Dan O'Connor: I don't think you're asking the right question. I think this is just an effort to avoid having an IETF standard for how to do OAM on VPLS. If we do what you propose there'll be no standard. - Shane (co-chair): I did poll WG and ask for raise of hands, and I saw a large amount of support for using 802.1ag for OAM for VPLS. However, based on another poll of the WG, very few people raised their hands on how to implement .1ag within VPLS PE's. - Ali Sajassi: Alex mentioned the Chairs' need to consider the WG consensus. The WG consensus at the last meeting was to adopt this. - Shane (co-chair): I think the question of an Applicability Statement needs to be asked at the same time, because people need to understand the context of this draft and how it will ultimately be used. - Alex Zinin: You seem to imply that draft gives guidelines on what needs to be implemented, is that right? - Ali Sajassi: Yes. - Alex Zinin: So why is it not going to be a Standard? - Ali Sajassi: Good point. We were having trouble with the chairs to get it through as Informational. - Alex Zinin: Do you think it should be Standard? - Ali Sajassi: For me, it doesn't matter, I just want to get it out. - Alex Zinin: If you really want to publish it and cannot get enough support, you can always go directly to RFC Editor as Individual Informational RFC. If this doesn't look like a Standards Track RFC, it shouldn't be giving implementation guidelines. - Sharam Davari: I'd like to support Ali. Informational RFC doesn't mean there has to be something new here. Also, multicast loopback doesn't exist in .1ag, so if you want something new, you got it. But, it's not explaining anything about LinkTrace or Loopback; it's just 4 - 5 pages of guidelines. - Marc Lassere: There is value in explaining how 802.1ag could be used in the context of troubleshooting an Ethernet network. I view Ali's draft as specifying a method on how you can get .1ag to work across an Ethernet VPLS network. I can see value there. To me, there's no new protocol invented in here. It's explaining how I can apply a solution, not the only solution, to perform OAM for VPLS, because it doesn't solve all the problems. I still think this could be complementary to some other VPLS OAM tools that have been produced in the past. - Dan O'Connor: This should be a standard. I think it's a step backwards to make it Informational. Worst case is it could be a Standard that is Best Current Practice. - Ali Sajassi: I would like to do a vote again. - Shane (co-chair): I don't think there's value in asking the audience again. We'll take these questions to the mailing list and have them answered by the WG at large. If the decision by WG is to make it a WG draft as it stands now, that's a decision we have to honor. - Ali: We discussed on mailing list 18 months ago, and then two meetings in a row the WG wants to make it a draft, but still we go back to the mailing list. - Shane (co-chair): Just to be clear, all decisions are made on mailing list, not here at meetings. 10) Customer MAC Address Flushing Mechanisms for Provider Backbone Bridging over VPLS http://tools.ietf.org/html/draft-sajassi-l2vpn-pbb-vpls-cmac-flush-00 Ali Sajassi (sajassi@cisco.com) - Independent from B-MAC flushing. Independent from PW types. Tomorrow we have another discussion on PW type -- some people couple these, but it's independent. It's independent of customer redundancy mechanism. - Need to solve the issue when Customer Equipment or customer network is dual-homed. If there is a failure and you switch over to backup AC, the customer MAC addresses need to get flushed, because if you don't the other PE will be pointing to stale info and traffic will get blackholed. We need to think of scenarios where we have H-VPLS with native PBBN access, or with MPLS access, or a mix of both. - Highlighting scope of C-MAC flushing, it's at the edge. Doesn't need to be known by intermediate devices -- that's scope of B-MAC flushing. - Works by sending an Ethernet in-band "flush" message from I-component of backup PE to the remote ends. This message goes in-band and is transparent to intermediate nodes. Only gets processed by the PE where the I-SID is terminated. - Backup I-component only needs to construct "flush" message with fixed fields. You just construct an Ethernet frame and send it. No need to run IEEE protocols here -- no MIRP, MVRP or MMRP. Works for PBB-VPLS with MPLS access and with PBBN access. - Advantages: + Fast convergence, since "flush" message passed through Intermediate devices as data. + Transparent to all devices operating on B-MAC addresses. + No interworking required. - Next steps: + Optimize C-MAC flushing further. + Solicit comments from mailing list. Questions: - Shane (co-chair): Why do we need this draft? - Ali Sajassi: From the MVRP message, you don't know what fields to set to generate a "flush" message. - ???: You're saying you want in-band message, which is different to what MPLS or VPLS does. - Ali Sajassi: Existing VPLS works on B-MAC addresses, this is for C-MAC addresses. Other draft talks about how to do encapsulation and so forth. If you have PBB in a U-PE, then the I-component of U-PE does encapsulation. If it's a N-PE, I-component of N-PE does encapsulation. - ???: ??? - Ali Sajassi: This says how we can use existing scheme without using IEEE protocols. How you can just get a snapshot of it and how you can apply it here. - Dave Allan: Draft has frame format. Is that not work should be done in IEEE? - Ali Sajassi: That has been mentioned in IEEE and they're talking about complete work on switch. - Dave Allan: From PBB standpoint, they have knowledge and define PBB. - Ali Sajassi: So, your issue is management of frame format? It can go into an Appendix. It is the same frame format as MVRP message, but the main point is that when you try to run MVRP you have all this state that goes with it and it's too much overhead. We don't want to plan to kill a fly with an elephant gun. - Dave Allan: You're making an extension to MVRP? I don't understand why this work is not coming from IEEE? - Shane (co-chair): Let's move discussion to mailing list, since we're running out of time. Due the meeting being 3 minutes past the end of it's scheduled time, the following two talks were cancelled this time: 11) Provider Backbone Bridges in H-VPLS with MPLS Access: CANCELLED http://tools.ietf.org/html/draft-sajassi-l2vpn-pbb-vpls-mpls-access-00 Ali Sajassi (sajassi@cisco.com) 12) Multicast Pruning in Provider Backbone Bridged VPLS: CANCELLED http://tools.ietf.org/html/draft-sajassi-l2vpn-pbb-vpls-multicast-00 Ali Sajassi (sajassi@cisco.com) 13) Simplified VPLS-PBB interworking with MMRP http://tools.ietf.org/html/draft-allan-mmrp-for-mac-in-mac-00 Dave Allan (dallan@nortel.com) - When talking about PBBN VPLS, we're talking about a VPN of VPN's. The number of sites per PE is approaching one. Number of sites per PBBN is comparatively large. If meshing with pseudowires, we'll get considerable multicast inefficiency if done with a single mesh. Desire to provide per-service multicast containment. - Trying to do this as simply as possible. Peer at B-component layer, not I-component layer. Achieve this with multicast MAC filtering at ingress to pseudowire mesh. Key is that I-component awareness is not required by VPLS. Maps client-layer flooding to well-known multicast addresses in B-MAC space. If I control flooding of those addresses, I get multicast efficiency. Side benefit of eliminating I-component awareness is eliminating some signaling. - Operational model shown. - Can take this a step further when shortest path bridging comes down the pipe, because it uses (S,G) trees rather than (*,G) trees in PBB. - Summary: + MMRP driven multicast filtering at edge of VPLS cloud eliminates need for I-component awareness. Substantial reduction in state and adjunct to scalability -- in other words, true overlay model vs. encapsulation. + Not too fussy about how we terminate the registrations or give them free run across the cloud. We have a model where we can snoop MAC registrations. ???: Is MMRP implemented? Dave Allan: We have implemented it, I know others have and I imagine there are standard implementations out there. 14) Meeting Closes