IETF 73: Layer 2 Virtual Private Network WG (l2vpn) Agenda THURSDAY, November 20, 2008, 0900-1130 ====================================== Chairs: Vach Kompella Shane Amante WG Status Web Page: http://tools.ietf.org/wg/l2vpn/ 1) Administrivia 2) WG Status and Update - TRILL co-chair (Don Eastlake) + TRILL charter contains the following: The TRILL working will work with the L2VPN WG to develop interworking between TRILL and 802.1D bridges at the edge, such that a bridged sub-cloud could be attached to TRILL devices in more than one place for redundancy. + RBridge Base Protocol draft is currently in Last Call + Asking for review by L2VPN working group + Please send comments to the trill WG mailing list. - L2VPN WG Status & Update: + WG Charter update completed & posted to IETF Web site - New charter formally recognizes the following new items: * Multicast, (including VPMS) * Scalability * Multi-homing / Service Convergence * Inter-AS - Document status + l2vpn-signaling still stuck in RFC Editor's queue on segmented-pw + Chairs have asked for help in completing IPv6 bits of ARP-MED & IPLS + draft-ietf-l2vpn-vpls-bridge-interop-04 & draft-ietf-l2vpn-oam-req-frmk-10, have been updated to hopefully clear several IESG DISCUSS'es and proceed to publication. + Yuji working to address Security Area DISCUSS against draft-ietf-l2vpn-vpls-mcast-reqts-06. 3) VPLS MIB http://tools.ietf.org/html/draft-ietf-l2vpn-vpls-mib-02 A S Kiran Koushik (kkoushik@cisco.com) - Scope of MIB + MIB covers RFC 4761, 4762 and l2vpn-signalling-08 + Dependent on PW-MIB, BRIDGE-MIB, SNMP context MIB - Changes from previous revision + Added BGP-Autodiscovery representation * VplsBgpADConfigEntry added * VplsBgpRteTargetEntry added o Allows H-Vpls representation + VplsBgpConfigEntry * RD and RT moved from BGP into the generic Vpls Config + Few Editorial changes - VPLS MIB Architecture Diagram - Open Issues/Next Steps + Use of SNMP context MIB to map to MAC address, however Bridge-MIB has no notion of AC (PW). + Need feedback from customers/users Questions: - Kireeti Kompella: You say that VplsBgpRteTargetEntry allows H-VPLS representation, but that seems pretty orthogonal. Can you explain that? - Kiran: We'd like to take that off-line. - Norival Figueira: I have a few questions for clarification. When I read the MIB, there are a few things that I couldn't find: + A VPLS Instance ID (VC ID) in the Configuration Table; + The Class of Service to be used by the VPLS instance for tunnel selection; + The maximum number of MAC addresses to be learned by the VPLS instance. + A way to allow someone to manually clear the table of learned MAC addresses of the VPLS instance. + The VPLS MIB points to the Bridge-MIB, but I don't see a clear identification of the interfaces that are bound to a VPLS instance. I see that for the PW side, but I don't see that for the interfaces. - Kiran: Thanks for the reading the draft. Please send these questions to the mailing list, that would be best way to address them all. Thanks for the comments and keep them coming. - Sanjay (?): MIB you're using for configuration doesn't support old FEC Type using VC ID. There are a lot of existing installations today that are using FEC 128 and all of them depend on the VC ID for the identifier of the VPLS instance. Would like you to consider in the VPLS instance, if you can add the VC ID as a field so that older installations can also be included. - Kiran: Sure, we'll consider adding it to a future revision. 4) Framework and Requirements for Virtual Private Multicast Service (VPMS) http://tools.ietf.org/html/draft-kamite-l2vpn-vpms-frmwk-requirements-02 Yuji Kamite (y.kamite@ntt.com) - Introduction + VPMS is defined as a Layer 2 service that provides point-to-multipoint connectivity for a variety of Layer 2 link layers across an IP or MPLS-enabled PSN. * Unidirectional p2mp L2VPN * VPMS operate over Pseudowires (PWs) as defined by the PWE3 WG o Ethernet, ATM, TDM PW  etc. + L2VPN WG Charter has been updated * Adopted VPMS - Draft positioning + Sets reqmt's for PW signaling & encapsulation in PWE3 WG: * P2MP PW reqmt's; and, * P2MP PW solutions + Sets reqmt's for Service set-up & management in L2VPN WG: * VPMS Auto-Discovery - Reference Model, (Updated in -02): + Proposed relationship between VPN, VPMS instance, AC and P2MP PW * One VPN = One VPMS instance (always) * Each AC is uniquely mapped to one VPMS instance (always) * One VPMS instance may correspond to more than one P2MP-PW, for example in PW redundancy case. - Protection & Restoration + Dual-Homed Access Support + Single / Dual Traffic Support * Sender CE may send traffic to one or two sender PE's simultaneously * Receiver CE may receive traffic from one or two receiver PE's simultaneously - Auto-Discovery + Allows new PE's to auto-discover VPMS VPN's and automatically join them - OAM Requirement + New section on OAM requirements * Fault Mgmt, Fault Notification, Fault Isolation * Testing * Performance Mgmt - Other Changes + Removed CE's sender/receiver role * Instead, specified AC's role, because AC's role (sender or receiver) is equal to it in effect in service configuration + Elaborated on PW and PSN replication approach + Invited new co-authors - Next Steps + Finish remaining major work on security + Continue to take WG input + Ask to adopt this draft as WG document Questions: - Ali Sajassi: In slides, you map a VPMS per AC. Is there a reason why you exclude mapping a VPMS per Multicast Flow -- i.e.: selective tree and other flavors of aggregate selective / inclusive tree? VPMS per AC roughly corresponds to VPMS per Inclusive Tree. Wondering why these other flavors of Multicast trees are not covered? - Yuji: In the draft we show requirement for activation, but I'm not sure if that addresses your question. - Ali Sajassi: I was recommending that instead of mapping VPMS per AC, we map at a finer granularity of a multicast flow over a particular AC to a VPMS tree. We can discuss it further offline. - Rahul Aggarwal: Responding to previous question, the question really is should VPMS optimize for IP traffic or should it be limited to Layer-1 or Layer-2 traffic? We probably need feedback from the WG on that. - Yuji: Currently, in use cases we show reqmt's for Layer-2 technologies and we don't raise addt'l reqmt's for dynamic control based on IP multicast. We haven't recv'd any input to add that, but if you think it's necessary please send your comments to the WG mailing list. - Shane: Who read this draft? A: Only ~12 people read it. - Shane: Who thinks it should become a WG doc? A: Same # of people. - Shane: How many are opposed to making it a WG doc? A: No hands. - Shane: It would be nice to get more people to read it, but we'll take it to the mailing list and ask if it should be made a WG doc. 5) Multi-homing in BGP-based Virtual Private LAN Service http://tools.ietf.org/html/draft-kompella-l2vpn-vpls-multihoming-02 Bhupesh Kothari (bhupesh@juniper.net) - Status + Draft focuses on providing details on multi-homing in Intra- and Inter-AS scenarios. + Some of this was in RFC 4761, but focus here is to discuss path selection both in BGP and VPLS. + Last version was presented in Dublin; got some feedback on the mailing list and incorporated that into this version. - Changes in -02 version: + VPLS operation with multiple VE ID's + Minor additions for Inter-AS scenario + MAC flush operations - VPLS Operation with multiple VE ID's + Only needed for a specific customer site, only when it is multi-homed. + VE-ID must be identical on two different upstream PE's when CE site is multi-homed. - PW establishment: + For Single & Multi-homed CE's + Path Selection on PE's to determine Designated Forwarder - Link Failure: Case 1 + When multi-homed CE site loses a link to an upstream PE, it doesn't affect forwarding for single-homed site, because single-homed site's PW label doesn't change. + After upstream PE, attached to down link for a multi-homed CE, announces "D" bit in BGP, path selection occurs on remote PE and remote PE "activates" forwarding on alternate PW toward backup PE. - Link Failure: Case 2 + Describes failure of "Backup PW" to multi-homed site. + It doesn't affect forwarding to either the single- or multi-homed site. - Use of Route Origin Ext. Community + When "Option B" is used to connect CE's in different Provider ASN's. + Source PE information is lost, since next-hop is overwritten by ASBR's. + RO Ext. Community carries Source PE Identifier, (Source PE's Loopback). - MAC Flush + When AC link goes down, PE advertises "Down" bit and this alone is enough to flush all the MAC's associated with a particular site. There is no need to send an explicit flush message. + However, there are cases where we need to flush MAC's explicitly, but I'll be covering that in my next presentation. Questions: - Florin Balus: In Link Failure Case 1, I would like to see case where site A is dual-homed to PE2, as well. In that case, if link between site A and PE1 fails, then you need to switch the service label in the forwarding path, correct? You're still affecting forwarding in data-plane for unrelated, single-homed sites like B, C, etc. on PE1 when link to A fails. - Bhupesh: You're talking about Case 2, right? - Florin: No. In Case 2 you don't have anything changing on PE1. - Bhupesh: No, it's changing here too. On PE1, when it detects link to site A goes down, it starts expecting a different label on traffic its sending to PE3. In previous case, there was no change on PE1. - Florin: For next IETF put a use case together for that and let's discuss off-line, because I still think it will change when you have two dual-homed sites into two different PE's and the lowest VE-ID is affected on PE1. The order is different in your current slides, so we should discuss further. - Bhupesh: Not really, as long as PE3 has already programmed to expect traffic from the labels it already knows about. PE3 is already programmed to expect traffic from label 31 or 32. PE1 will never send traffic with both the labels. If there's a failure, PE1 will switch and it doesn't need to coordinate with PE3, since PE3 already knows, in the data-plane, to expect traffic from the other service label. - Florin: Let's analyze the right use case and discuss it off-line. - Florin: Next question on Inter-AS. The ASBR's aren't running the dual- homing algorithm, they don't care about VE ID's, so they are installing all the labels for all the sites? - Bhupesh: Correct. - Florin: But, PE4 with Route Origin Comm. identifies the grouping of VE ID's, and that's the selection? In one case (ASBR's) you don't do path selection, and in another (PE4) you do, correct? - Bhupesh: Right, the ASBR's aren't looking at VE ID's, because they are just doing the label swap and changing the BGP next-hop. It's the N-PE that will do both BGP and VPLS path selection, and that's when it matters which VE ID belongs to which PE and that info is lost when it crosses AS boundaries. - Florin: And, that's why you need the Route Origin Ext. Community so that PE4 knows where the sites are grouped? - Bhupesh: Yes. About the multiple, dual-homed sites I can take that off-line to explain that particular scenario. - Luca Martini: There's a comment in the draft that says if you don't have all PE's in the network completely upgraded to support this scheme, then you'll have a Layer-2 loop. Is it good to ask SP's to upgrade all their PE's, otherwise they'll have a loop? - Bhupesh: There is no loop. Where did you see that? - Luca: It's in the Interop section. - Bhupesh: If the PE's don't support multi-homing or don't understand path selection, then multi-homing won't work. - Luca: We should look at something else that doesn't have risky drawbacks. Also, in reading this draft, its proposing major changes to BGP including a completely new BGP path selection algorithm, RR changes, PE changes, etc. Instead, you could have a much simpler "peer" model just between the two PE's connected to the multi-homed site and you wouldn't need to do this network model. - Bhupesh: If you're deploying a new service, then all PE's have to be able to be configured for the new service and understand how to do path selection. - Luca: Also, if you have several sites that are going to be multi-homed, you're going to have a lot of VE ID's, which creates a scalability issue. This goes against the design principle discussed in L3VPN to allocate a label per VRF. For example, here if you have 8 sites and allocate a label block of 8 labels, when you add a 9th site you're adding more blocks. Now, with this scheme you're doubling the amount of blocks you're adding. - Bhupesh: Actually, you don't double label blocks. - Luca: You have to program the label on both sides of the network. - Bhupesh: But if you want redundancy, then you'll have extra state. - Luca: Yeah, but you only need to put the extra state on the two upstream PE's directly connected to the multi-homed site and then remote PE's don't need the extra state. - Kireeti: This is a non-issue. The number of labels and PW's you have in a VPLS is tiny compared to the # of labels you have in a L3PVN, especially when you have a label per-prefix and you can have 10's of 1,000's of prefixes per VPN. In VPLS, there is a PW per VE-ID, which is tiny, because you don't have a VPLS with 1,000's of sites. I'm not sure you're doubling in this case, but even if you were you're doubling a very small number. - Luca: The amount of labels in a L3PVN is proportionate to the amount of routes you have in host sites. You don't have that many routes. - Kireeti: No, it's not. - Ali Sajassi: Let me jump in here, also. The label in L3VPN is only used for de-mux'ing and if something goes wrong only a prefix gets affected. OTOH, in VPLS, you have OAM maintenance for these labels (PW's) and you don't have that in L3VPN and that's why we have VCCV, etc. to monitor these PW's. I want to highlight that it needs to be looked at in the context of PW's than just a pure label. - Florin Balus: The main issue here is that everyone in the network, including ASBR's in other AS'es is running this VE-ID selection algorithm, when it should just be the two upstream PE's directly connected to the multi-homed site. The rest of the network shouldn't be affected. You can do a MAC flush, but remote PE's shouldn't have to keep track of these VE-ID's and do this path selection every time something changes on an access link. - Shane (co-chair): I think that's a good architectural question about how active/standby PW's should work in a multi-homed environment that deserves more discussion, but we should take it to the list. - Florin: We're doing it locally in VPLS-LDP and it goes much faster than propagating all this state throughout the network. - Stewart Bryant: I'm still worried about this looping discussion we had. If I mix old & new systems or have a misconfiguration, then I can generate a data forwarding loop? - Bhupesh: If you don't have all PE's that can provide you with multi-homing, then you shouldn't be deploying multi-homing. - Stewart: Are you proposing a protocol mechanism that ensures if any of the nodes are not correctly configured, then the system is automatically shutdown so loops can't form? We never deploy new systems that are damaging to old systems in such a catastrophic way. - Bhupesh: Point taken off-line and address it on the mailing list. - Stewart: I really think this needs to be addressed, otherwise it will be too damaging to the network/service. 6) VPLS Flush in BGP-based Virtual Private LAN Service http://tools.ietf.org/html/draft-kothari-l2vpn-vpls-flush-00 Bhupesh Kothari (bhupesh@juniper.net) - This discusses where we need an explicit MAC flush. - Implicit MAC flush (1) + If you have single VE-ID's or if all PW's go down between a pair of PE's, then you don't need an explicit notification, because the 'Down' bit in BGP UPDATE will take care of it. - Implicit MAC flush (2) + When multiple sites are connected behind same remote PE, then 'Down' bit is not enough info, because it can flush MAC's for sites that are still up. - Explicit Notification * Ali Sajassi: Clarifying question. If link between PE1 and A fails, why do you need MAC flush notification? The only time you need MAC flushing is when you're dual-homed, not single-homed. * Bhupesh: Correct. This diagram should be updated so that the break is on the link from PE1 to B. - Motivation for explicit flush notification + Existing VPLS-BGP flush procedures flush all MAC's associated with a PE. + Explicit flush optimizes flush of MAC addresses when multiple VE ID's are present on the same PE. - Proposal + New BGP message, VPLS-FLUSH, that carries list of TLV's containing MAC's to be flushed. - VPLS Flush Capability + PE advertises VPLS Flush capability if it can process VPLS-FLUSH msg * Only advertised to peer if VPLS-BGP NLRI's are also exchanged - VPLS-FLUSH Message - Operation (1) + VPLS-FLUSH carries RT associated with VPLS VPN + No path selection on VPLS-FLUSH message + Regular processing of attributes occurs before VPLS-FLUSH msg is propagated to other peers. For example, RT-constraints would be run on RR's to block receipt of VPLS-FLUSH if there are no PE's that are RR clients of that RR. + No permanent state for VPLS-FLUSH messages on PE's or RR's. - Operation (2) + Link break should be on A2 to PE1 link, (not A1 to PE1). + If link between A2 to PE1 fails, PE1 generates a VPLS-FLUSH message. + VPLS-FLUSH message is scoped to just those remote PE's that have sites with the same RT. Questions: - Luca Martini: Through the RR, the VPLS-FLUSH message is broadcast, so this is like a ATM LANE Broadcast-Unknown Server? - Bhupesh: It gets flooded to all the other sessions. - Luca: How does this work when it gets to an ASBR? - Bhupesh: It does the same thing, but ASBR still does regular attribute processing (RT-constraint, etc.) before propagating flush message. - Luca: But, there is no NLRI in this message? - Bhupesh: There is no NLRI, but there are attributes. - Luca: But, this is not BGP. - Bhupesh: Why isn't this BGP? - Luca: Because you're adding new messages and strange behaviors. - Bhupesh: Although LDP is used for label distribution, what does ICCP have to do with LDP? Second point is just because this message doesn't have an NLRI, doesn't mean its not BGP. - Luca: ICCP is using LDP, because its convenient not to write a whole new protocol. What I'm saying is the same thing Florin mentioned, that the architecture of this should be that the state should be kept on the two, upstream PE's directly connected to the multihomed site. - Bhupesh: What Florin said was different, he said that the flush had to happen on the remote PE's. - Dave Ward: Different point of view than Luca. I understand what you're trying to accomplish, because you're trying to traverse RR servers, but I believe you don't have to change the protocol this drastically to accomplish it. There are potentially ways to do this with Ext. Communities, which don't require as drastic changes to the protocol. So, I recommend we do think of other ways to do this and look at the pros & cons of them. - Bhupesh: We did look at other ways to do this, but this VPLS-FLUSH method is completely stateless. If you want to make it stateful or use communities we can do that, but we wanted to design it so it was stateless. - Dave Ward: You actually do need to keep a small amount of state with VPLS-FLUSH, because you need to keep the Sequence ID of the next message you're going to receive. Not trying to prevent you from doing this functionality, just trying to get you to think about doing it a different way. - Bhupesh: RR's & ASBR's will have no permanent state, but will have Sequence # state. Sequence # has no meaning to RR's. It was added just for N-PE's. If N-PE's want to optimize dropping of duplicate messages, they need the sequence number. - Yakov Rekhter: First, if you want to discuss overloading BGP, then that discussion belongs in GROW WG. Second, let's not pursue double-standards agenda, because it's not going to get us anywhere. Third, with respect to Dave's comments, I agree to disagree. Yes, there is more than one way to accomplish this, but it's a matter of opinion on which is best. - Kireeti: When BGP is used for L3VPN's, a PE floods updates to all peers, unless you're using RT-constraints. If people are worried about this message being flooded everywhere, then use RR's with RT-constraints to prevent irrelevant PE's from receiving it. Second, I agree with Dave, I don't like to put new machinery in BGP unless you have to. But, I am willing to listen to new ways to do this. Please come up with a new proposal and let's talk about it. - Florin Balus: Because it's a new BGP message, then you're expecting the entire network (PE's, ASBR's, etc.) must be upgraded? - Bhupesh: If you don't know how to process the new VPLS-FLUSH message, then you'll continue to do the old Implicit MAC Flush on the PE's. - Florin: But, you need all the PE's, RR's, etc. to be upgraded to forward the new message, correct? - Bhupesh: Correct. It's similar to Optimized MAC Flush TLV in VPLS-LDP. You have to upgrade all the PE's to understand it. - Florin: You need to find a way to differentiate between update or withdrawal when you lose single- vs. dual-homed sites with 'D' bit set for Implicit MAC flush, because it will cause different reaction at remote PE's. - Bhupesh: That's untrue, because remote PE's do not know how many single- or dual-homed sites are behind PE's, (PE1 & PE2 in diagram). - Florin: You will have one message for single-homed sites and another one for dual-homed sites in the case of Implicit MAC Flush. At the receiving end, you need to differentiate between them, because for the single-homed site there is no point in doing a MAC Flush, because there is no other way to go. For dual-homed sites, you do need to do a MAC Flush. - Bhupesh: OK, I agree. - Florin: There are two types of MAC Flush in VPLS-LDP, and IEEE sanctioned one of them. When the link activates that's what the IEEE usually does for the MAC flush, because that's when the alternate path becomes available. And, the message is "flush all but mine". OTOH, you have the negative message, which some people like, because that tells them when to get started with the whole MAC flush process. So, do you have a way to accommodate both of them? - Bhupesh: TLV's are defined. If there is a need to define more TLV's we can do that. However, there is no applicability for what you described in BGP. - Florin: You only described negative MAC flush; however, we have two of them. You need to accommodate both of them, because there are preferences for both. - Bhupesh: In VPLS-LDP, there is no multihoming. - Ali Sajassi: In VPLS-LDP, its only positive MAC flush. in the case where U-PE is dual-homed to two, different N-PE's, only when backup PW becomes active is a MAC flush performed using "flush everything, but me" message. There is a reason for it: if you do it the other way around, you may blackhole traffic for no reason. We had this discussion a long time ago, we can resurrect it on the mailing list. - Ali: Another point wrt BGP vs. LDP, the real question is architectural differences between taking care of failure locally vs. flooding state to all PE's and having all of them take care of the failure. - Ali: Second point is I'm concerned that some things that can be done within the Bridge modules defined by IEEE, we're trying to do via signaling mechanisms in BGP. For example, in PBB, failure of an AC only affects I-component completely within the Bridge Module and they generate in-band message themselves. - Bhupesh: You're talking about C-MAC flush? - Ali: If Bridge Module takes care of it itself, why are we doing this in BGP? - Bhupesh: Are you saying that MAC flush in VPLS-LDP is not useful? - Ali: I'm saying we're going down a slippery slope, because once we get to PBB, its all being done in the Bridge Module. So, if its already there, why do we want to do it differently? This comment applies to LDP, as well. - Bhupesh: We should discuss that when talking about doing C-MAC flush in PBB. Can you clarify MAC flush in RFC 4762, because remote PE's never recv'd info about a standby PW, so aren't they flushing everything? - Ali: No, but we can take this off-line and discuss further. 7) Multicast Pruning in Provider Backbone Bridged VPLS http://tools.ietf.org/html/draft-sajassi-l2vpn-pbb-vpls-multicast-00 Ali Sajassi (sajassi@cisco.com) - What is it? + Using single VPLS instance for a group of customers, improves MAC and PW scalability. But, problem is broadcast & multicast traffic is being sent on PW's to PE's that have no customers in that VPLS instance. + This draft is about improving scalability of broadcast & multicast flooding for PBB-VPLS. - What is it? (cont'd) - Why is it needed? + Need multicast pruning scheme, because otherwise it would lead to unnecessary BW & processing in the network. - How it works? + B-MAC addresses are administratively configured + Use BGP to Auto-Discover them + Then, create an OIF list containing list of PE's interested in these multicast frames. - How it works? (cont'd) + Define new BGP NLRI: PBB-VPLS NLRI + Re-use BGP attribute: PMSI Tunnel Attribute as defined in [MVPN-BGP-Encode] and [L2VPN-MCAST] to indicate "ingress replication" used for this NLRI. - Advantages + Extending existing Auto-Discovery mechanism already defined for Multicast in VPLS. - Next Steps + Solicit comments from WG Mailing List + Eventually pursue it as WG doc Questions: - Kireeti Kompella: Comment about using BGP for Auto-Discovery is strange, but I think BGP is good for what you're trying to do. BGP wasn't made for Auto-Discovery, it was made for something else. Second, I think you need to update your slides, because its actually an existing BGP attribute. - Ali: Agreed, it's an existing attribute. - Yakov Rekhter: Is this scheme intended to be limited to ingress replication, or also when multicast is sent over P2MP LSP's? - Ali: Currently, it's intended only for ingress replication. P2MP LSP's are for further study. - Yakov: Why is that? - Ali: Because I need to think about it more. - Yakov: Additional benefits could be gained with P2MP LSP's above and beyond ingress replication. - Ali: I realize that. - Florin Balus: You're building a multicast tree in the B-VPLS? - Ali: No, it's not a multicast tree. It uses existing full-mesh of PW's, but they are pruned so that PE's only receive traffic for a given multicast group. - Florin: You need to add Ext. Community that's in BGP Auto-Discovery to indicate the Backbone VPLS component to which these I-SID's apply, because you can have multiple of them. BCB's need to know that this is related to one B-VPLS vs. another when doing BGP A-D. - Ali: This is done on a per-PE basis ... - Florin: This is initiated by a BEB? - Ali: This is initiated by the LAN Emulation side of the PE. BEB is the bridging part of it. - Florin: But, you'll have some devices in the core that just have the B-component? - Ali: No. Are you talking about VPLS core? - Florin: Yes. - Ali: VPLS core is pure MPLS. - Florin: I was talking about H-VPLS case, but I think we can take it offline. If you have H-VPLS and you don't have I-SID components in the N-PE's, then when they receive the BGP advertisement they need to correlate them the B-components or B-VPLS only components. - Ali: Where does the Auto-Discovery get initiated in H-VPLS? - Florin: In H-VPLS, everywhere. - Ali: No, it gets initiated at N-PE, not U-PE. - Florin: No, there's a way to initiate it at U-PE's using Route Targets ... - Ali: Currently, the way it's been defined is at the N-PE. We've never agreed to extend BGP to the access network. This draft is consistent with that. If we want to change H-VPLS model and do it differently, then we can mimic that in here. - Florin: We should draw a different topology and expand on that, but we can take it offline. - Ali: OK, but we need to agree on normal H-VPLS case and we would need to expand that specification before talking about it here in PBB-VPLS case. - Rahul Aggarwal: If you look at VPLS multicast work, it has notion of Selective Trees. The existing spec also allows for ingress replication, P2MP LSP's, etc. What is being done here is nothing but a selective tree, the difference is the granularity of the selective tree is not a source, group address, but rather a multicast MAC address. What I would like to see is to re-use all the procedures we have in VPLS multicast with an extension that the granularity of the selective tree can be a multicast MAC address, in addition to what we already have today. - Ali: That's not contradictory with what we've defined. Are you talking about the message definition? - Rahul: No, I'm talking about the procedures. They're already defined, so we should just use them. - Ali: Once we get to P2MP we can look at it, but wrt ingress replication ... - Rahul: Even wrt ingress replication the procedures should be the same, they already exist. - Yakov: We have existing machinery in L2VPN multicast & VPLS multicast to build selective trees. The only difference between that machinery and what you need is the existing machinery carries 4-Byte IP Address and you want to carry 6-Byte MAC. If that's the only difference, then let's just extend the existing procedures and be done. - Ali: We can look at it and if that's the only thing that needs to be done, then we'll do it. - Rahul: If that's all you need, then we can extend the VPLS multicast draft, because it would be very small extension. - Ali: In terms of selective tree, it has S,G in there, whereas I have no need for "S". - Yakov: That's why I said it's just a simple matter of what you carry in the message and how long it is. 8) PBB-VPLS Consolidation Plan http://tools.ietf.org/html/draft-sajassi-l2vpn-vpls-pbb-interop-03 http://tools.ietf.org/html/draft-balus-l2vpn-vpls-802.1ah-03 http://tools.ietf.org/html/draft-sajassi-l2vpn-pbb-vpls-multicast-00 http://tools.ietf.org/html/draft-sajassi-l2vpn-pbb-vpls-mpls-access-00 http://tools.ietf.org/html/draft-sajassi-l2vpn-pbb-vpls-cmac-flush-00 Florin Balus (florin.balus@alcatel-lucent.com) & Ali Sajassi (sajassi@cisco.com) - Number of drafts with significant overlap. We'd like to consolidate these drafts and move forward. - Where are We? - Consolidate work into 4 buckets + PBB-VPLS PE model and network architecture + Use case scenarios for Interop scenarios + MAC Flushing Mechanisms + Multicast Pruning for PBB-VPLS - PBB-VPLS PE Model and Network Architecture + Describe PE model using PBB components analogous to what we have for VPLS with PB component. + Cover different cases of PE with I & B component, or only B component + How will PE processing work when connected to different types of access networks? + How will we map customers to different VPLS instances? - Interoperability Scenarios & Use Cases + Covers interop with PBBN, PBN, MPLS access networks and how does migration work. - MAC Flushing Mechanisms + Cover native-mode (inband) as well as out-of-band signaling via LDP - Multicast Pruning for PBB-VPLS + Covered in previous talk + Might also want to add a short paragraph to describe how multicast pruning can be done using MMRP along with its applicability and scaling constraints. Questions: - Rahul Aggarwal: What is the reason for having two mechanisms to solve the same problem? - Ali: Ideally we should agree on one. - Rahul: Well, let's just say that. - Florin Balus: One of them, VPLS-LDP method is already deployed in the network and it could be used for PBB-VPLS. There is no need to extend it for PBB-VPLS, it's just a matter of adding some optimization to optimize what is being flushed at the PBB PE. - Rahul: In that case, let's just use the LDP mechanism. Why have the first one? - Ali: There are interop cases where that won't work. If you're interoperating with a native PBBN, and MAC Flush is initiated from the PBBN and it comes to the PE, then the PE needs to understand it and flush it. - Florin: In case of Native Ethernet access, in PBB they didn't put a MAC flush when they wrote the spec. There is no MAC Flush, instead there is blackholing. So you need something else, because there is no LDP. - Rahul: Doesn't this mechanism apply to the B part of the network? - Ali: It applies to the B and it applies to end-to-end. - Rahul: If you're defining B functions, we can live with one mechanism. And, at the edge of the B network, if has to, it can interoperate with whatever PBB does. - Ali: The problem is MAC flushing has to interoperate in a number of different scenarios. Specifically, MAC flushing can be initiated from PBBN, PBN or MPLS access networks and in all 3 cases it needs to work. - Rahul: If we decide there are cases where the LDP mechanism doesn't work, then we should spell out those cases very clearly. Otherwise, if the LDP based mechanism works across the board, then we should just have one mechanism and be done with it. - Ali: There is a difference between C-MAC & B-MAC flushing. The existing mechanism we have is for B-MAC flushing and LDP will work fine in that case "as is". OTOH, for C-MAC flushing, there is no C-MAC addresses in N-PE's, so there is no reason reason to send a flush message to the N-PE's. It is a lot more efficient to let the bridge do its job and send it end-to-end. - Rahul: You have two mechanisms on your slide, but now you're making a case for doing it in-band. If that's the case, then just use in-band. - Ali: In-band has a lot broader application, whereas LDP has a lot narrower application. - Rahul: What I'm hearing is the authors cannot agree on one mechanism and the WG needs to decide if you can have one mechanism across the board, then use it. If not, let's define applicabilities. - Ali: We'll take that into consideration. *) Meeting Closes