IETF 71: Layer-2 Virtual Private Network WG (l2vpn) Minutes THURSDAY, March 13, 2008, 0900-1130 =================================== Chairs: Vach Kompella Shane Amante 1) Administrivia 2) WG Status and Update Agenda Bashed WG Status: - l2vpn-signaling: held on Normative Reference to pwe3-segmented-pw - 3 drafts submitted to AD's and requested publication + Need to address Gen-ART & Sec-DIR comments: - draft-ietf-l2vpn-vpls-bridge-interop-02 - draft-ietf-l2vpn-oam-req-frmk-09 - Spoke to both Dinesh & Ali about the above and they're going to try to sync up with reviewers at this IETF and address their comments + Need to address Sec-DIR comments: - draft-ietf-l2vpn-vpls-mcast-reqts-05 - ARP-MED & IPLS: + draft-ietf-l2vpn-arp-mediation-09 + draft-ietf-l2vpn-ipls-08 - Completed WG Last Call on both as of Friday before IETF - Will work to complete PROTO doc and submit to IESG shortly - On slide 3, blue items to be discussed at this WG meeting, red "categories" are things not currently on the charter. Will talk about re-charter shortly. Going to hold off accepting drafts in red categories, until we successfully get category on charter. - MIB's: In Progress + draft-ietf-l2vpn-vpls-mib-01 + draft-kkoushik-snmp-context-map-mib-01: NEW - OAM: In Progress + draft-mohan-l2vpn-vpls-oam-00 + draft-stokes-l2vpn-cfm-vccv-oam-00 + draft-stokes-vkompella-l2vpn-vpls-oam-01 + draft-ietf-l2vpn-vpws-iw-oam-01: Expired - Scalability: In Progress + draft-balus-l2vpn-vpls-802.1ah-02 + draft-sajassi-l2vpn-vpls-pbb-interop-02 + draft-vkompella-l2vpn-rvpls: NEW - Service Convergence: In Progress + draft-pdutta-l2vpn-vpls-ldp-mac-opt-03 - Multicast: In Progress + draft-ietf-l2vpn-mcast-03 + draft-ietf-l2vpn-vpls-pim-snooping-01: Expired + draft-qiu-serbest-l2vpn-vpls-mcast-ldp-01: Expired, unlikely to be revived - Virtual Private Multicast Service (VPMS): potentially new L2VPN & PWE3 WG items, if it gets added to charters of both WG's. VPMS work likely to take the following two drafts as basis of work and split them apart as follows: + draft-raggarwa-l2vpn-p2mp-pw-00 + draft-jounay-pwe3-p2mp-pw-requirements-01 o P2MP PW requirements to be in draft in PWE3. o P2MP PW encapsulation solutions to be in draft in PWE3. o VPMS service requirement to be in draft in L2VPN. o BGP Auto-Discovery Procedures for VPMS to be in draft in L2VPN. - Other: In Progress + draft-kothari-l2vpn-auto-site-id-00 + draft-kompella-l2vpn-vpls-multihoming-00 - WG Charter Update + Completed rough draft of proposed re-charter and got consensus with AD's just before this IETF. + Will send out proposed draft of new WG charter just after IETF 71. + New Items that are suggested to be in the new charter are as follows: o Multicast: already working on it o Scalability: work that Ali, Dinesh, Florin & others already working on. o Multihoming / Service Convergence o Inter-AS Questions: Kireeti: OAM? Shane: OAM is already on the charter today. 3) VPLS OAM http://tools.ietf.org/html/draft-mohan-l2vpn-vpls-oam-00 Dinesh Mohan (mohand@nortel.com) - Following presentations on this draft, Vach's OAM solutions draft & Olen's CFM & VCCV-BFD OAM draft in Vancouver there have been a lot of discussions. - Agreed upon VPLS & H-VPLS PE model to be used for OAM, based on other OAM drafts, since previously those reference models were implied and not stated explicitly. - This solution draft is applicable to monitoring: + VPLS as Bridged Service + VPLS as Emulated Service + MPLS domain (PW/LSP Monitoring) - Solution proposes using: + 802.1ag/Y.1731 for Service-layer and LAN Emulation layer + VCCV (Ping/BFD) for MPLS domain - Discussion on VPLS & H-VPLS PE OAM reference models + This model was implied, but not necessarily called out explicitly in L2VPN RFC's or bridge-interop draft. + In subsequent revision to this draft, going to put this model in. - Solution applicability + Ethernet service layer & Emulated LAN monitored via Ethernet OAM to aid in fault localization to a specific network element + PW OAM (VCCV with BFD/LSP-ping) is used to determine faults in PW layer - Would like to progress this draft as WG draft, but don't want to make this call, yet, because want to update draft to include: + VPLS & H-VPLS PE (OAM) reference models; and, + Next level of details of addressing Ethernet OAM frames on Emulated LAN interfaces, etc. + Perhaps a brief primer on 802.1ag + Also want to evaluate incorporating elements of draft-stokes-l2vpn-cfm-vccv-oam, which did evaluation of Ethernet OAM and VCCV to VPLS, into an appendix of this draft. Questions: - Loa Andersson: Why not make a call to make this a WG draft now? - Dinesh: I'm OK with that, but don't want to push it if people aren't comfortable with that right now. - Loa: We seem to be raising the bar too high. If we have agreement this is an area we want to work on and we have a good start, then we should make it a WG doc. - Dinesh: I'll let the chairs make the call. - Shane: How many folks have read the draft? Fairly significant number. - Shane: How many folks think this should become a WG draft? Same number. - Shane: How many folks think this should not become a WG draft? No hands. - Vach: This doesn't add new protocol things at all, so when we're talking about making this a WG draft it's intended status should be Informational, right? - Dinesh: I'm OK with that, but I don't know whether we should pursue it as a Standards Track or not, because it's not introducing new elements, but it is providing a very specific view of how the solution can be applied using the existing protocols. - Vach: Right, so since it's not adding new protocol elements, there's no particular reason why it should become Standards Track. The other thing is a brief primer on 802.1ag & Y.1731 is unnecessary. People need to be able to read other docs from other SDO's, provided they are given references. If we include those primers it could hold things up, because people are going to critique how good is your summary of those other standards. - Dinesh: Perhaps that is a dicussion we continue to have, because some people have a feeling that it would be nice to have ... - Ali Sajassi: Regarding we might not need a primer for 802.1ag/Y.1731. I'm concerned that when it goes to IESG we'll get a comment that it's not readable. IESG has come back and said that you need to include enough material so that it's readable outside your group, not just in your group. - Shane: Related to that point, the last time I read your draft what would be helpful is making sure to properly define all the IEEE/Y.1731 specific acronyms in a glossary section. However, beyond that, we shouldn't repeat/summarize 802.1ag in here. - Olen Stokes: A conversation we had earlier this week was along the same lines. Let's make sure to use IETF terminology when possible so that someone with an IETF background can pick it up and understand it. I agree we don't need a full primer on .1ag. - Dinesh: With respect to progress we've made so far, we have agreed to make it a WG doc as an Informational RFC. - Shane: That needs to be taken to the WG list, but clearly there's a good amount of interest in the room right now to do so. - Dinesh: Agreed. - George Swallow: With respect to the comment on IETF terminology. We do have a need for a Rosetta Stone. - Dinesh: As an editor, I have enough guidance on what needs to be done next. Also, after the next revision we'll see about asking the list to make it a WG draft. - Shane: I think that's a good idea. - Dinesh: With respect to next steps. Still discussion going on with respect to applicability of draft-stokes-vkompella on enhancements to VCCV for VPLS to provide additional functional coverage. + Presented view that draft-stokes-vkompella is looking to address scenarios where RIB and FIB in VPLS PE are misaligned. In further discussions on this problem, if MEP's are located on a U-PE or N-PE they would be using provider MAC address space, but customer frames in Q-in-Q or MPLS access environment are using customer MAC address space and will not necessarily be monitored. However, if we front-end the access network with PBB, then all forwarding (OAM and customer data) in the VPLS environment will be using provider MAC address space and OAM will be more consistent. - Florin Balus: It's too early to state considerations for a protocol that isn't deployed that much, yet. And, we've seen the requirement for OAM from current deployments that aren't using PBB. - Dinesh: We are looking to continue this discussion on scoping of the problem and solutions. - Vach: What we've heard from providers about draft-stokes-vkompella is that OAM needs to really exercise the forwarding plane exactly as if a customer packet went through there. So, using a provider MAC address in place of a customer MAC address is a significant issue. What draft-stokes is trying to do is generate OAM packets, including MAC headers that look almost exactly like customer MAC headers so that we really exercise the forwarding plane. OTOH, .1ag gives you an end-to-end view of the service, but it doesn't necessarily follow the exact same forwarding plane path. In a pure Ethernet world, this may not be a problem because the header doesn't change on a hop-by-hop basis. However, in an MPLS world, the header does change, so it becomes even more important for us to follow the exact same forwarding path. So, it's important to consider that we won't be using the exact same forwarding path if we use: 1) a multicast MAC addresses; and, 2) we don't use the forwarding engine to forward the OAM packets. - Dinesh: This is still an ongoing discussion. However, if we use PBB, then this problem is mitigated. But, this is under next steps that we will be working on further. - Ali: Follow-up to Vach's comment. I think problems are similar in Ethernet and MPLS domain. Point in this draft is not the header changing, but lookup in database. In one case, lookup results in fwd'ing through another Ethernet port and another case, lookup results in forwarding through a PW. Also, in .1ag it was determined that having monitoring based on a node's address is sufficient. If that's not sufficient, then .1ag is getting amended to include monitoring of customer MAC addresses for PBB-TE. Question to ask is if I can monitor down to customer MAC address, then why do I need additional tools to do the same thing? - Shane: If a provider doesn't deploy PBB-TE, then can they still use the extension to .1ag you referred to in order to monitor VPLS by using customer MAC addresses in OAM frames? - Ali: If the extention does get done to .1ag for PBB-TE, then I think it can be leveraged to provide the same monitoring within VPLS w/out running PBB. - Kireeti: When you use .1ag today, what destination MAC address do you use? - Dinesh: Either a multicast or, in the case of Loopback, the provider's MAC address space, because that's where your MEP's are located at. - Kireeti: One of the reasons for doing draft-stokes-vkompella is people want to know where MAC addresses are located. It's important to know not only that your service and PW's are up, but also to realize that forwarding is OK for some particular MAC addresses. - Dinesh: When PBB is not deployed, then you do have disparity between the data frames that are forwarded between customer data frames and OAM packets. However, this is all part of the discussion and we have it down in our next-steps to discuss further. - Dinesh: Going to move on to next preso now. 4) MPLS and Ethernet OAM Interworking http://tools.ietf.org/id/draft-mohan-pwe3-mpls-eth-oam-iwk-00.txt Dinesh Mohan (mohand@nortel.com) - This preso is an FYI. This draft is targetted toward PWE3 WG. - OAM solution for Ethernet VPWS service to provide mapping of defect states between PW and AC. - This draft completes work started in draft-ietf-pwe3-oam-msg-map, which didn't include Ethernet OAM since it wasn't mature enough at that time. - Discussion of Reference Model, Fwd & Reverse Defects, Notification Options. - Discussed in PWE3 WG to merge this with draft-ietf-pwe3-oam-msg-map or keep it standalone. According to discussions with Stewart Bryant, we'll probably pursue it as standalone. - Work on draft is mostly complete, so are going to pursue it as a PWE3 WG draft. No questions. 5) LDP Extensions for Optimized MAC Address Withdrawal in H-VPLS http://tools.ietf.org/html/draft-pdutta-l2vpn-vpls-ldp-mac-opt-03 Pranjal Kumar Dutta (pdutta@alcatel-lucent.com) - Originally presented in San Diego, then Prague. - Draft proposes to flush all MAC addresses learned from a specific VSI behind a specific PW to prevent unnecessary re-learning and flooding in a large number of VPLS instances. - Description of PE-ID TLV. - Discussion of benefits. In RFC 4762, PE device is required to flush MAC's learned from n-1 PW's. In this draft, only need to flush MAC's from 1 PW. Questions: - Ali: With respect to optimization, is the concern with flushing customer MAC addresses? - Pranjal: It's not about flushing, it's more about flooding & re-learning. - Ali: Flooding & relearning only happens on topology change, which rarely happens and that traffic is in the noise. Are you concerned with BW consumption? - Pranjal: Not concerned with BW consumption. Concerned with re-learning that happens. - Ali: PE needs to learn at wire-speed anyway. - Pranjal: It's not about learning speed, it's about scalability and unnecessarily re-learning and flooding. - Ali: What are we trying to improve? If learning is done at wire- speed, re-learning is not an issue. If it is a BW consumption issue because of flooding during topology change, that happens once in a blue moon, so that's not an issue. If it's in terms of MAC addresses, then once we go with .1ah, then the MAC addresses are reduced. - Pranjal: Scope of this work is with respect to existing deployments that don't have .1ah. - Ali: I would like to have further discussion on the mailing list, before we decide to make this a WG doc. - Vach: Ali, did you make any comments on the mailing list? - Ali: I did not see any solicitation for comments. - Pranjal: I asked after Prague on the list, but didn't get any. - Ali: I will give you comments. - Olen: We do have redundancy implementations that use that require this TLV, because MAC-withdrawl as it stands today gives us the inverse of what we need and this is the only way we can provide a standards-bsaed solution. So, we need this for reasons that also aren't described here. - Shane: How many people have read the draft? Not a lot. If folks could read this draft, that would help discussion on the list as the draft progresses. 6) Virtual Private Lan Services (VPLS) Management Information Base http://tools.ietf.org/html/draft-ietf-l2vpn-vpls-mib-01 Rohit Mediratta (rohit.mediratta@alcatel.com) - Draft now covers RFC 4761 & RFC 4762. - Plan to incorporate BGP Auto-Discovery, hopefully by Dublin. - Review of MIB modules & dependencies. - Added mechanism to map MAC addresses to Bridge MIB using SNMP Context MIB. - Discussion of how to support VPLS-LDP, VPLS-BGP in MIB. - Reviewed questions & comments received from mailing list. - Big question for WG is that Bridge MIB doesn't have notion of PW AC. Not sure if SNMP context MIB would solve the problem. Unless we override the base port, which is defined in the Bridge MIB, then we wouldn't get this functionality. The option we have is to define some of the Bridge MIB in here or somehow override the base port. Hoping to address this before Dublin. Questions: - Kireeti: In vplsPwBind, can you take into account p2mp PW's? This is work that's happening in this WG for optimized multicast over VPLS using p2mp PW's. - Rohit: Not at this point, but it is something we can look at. - Kireeti: What granularity are you planning for the counters in the MIB -- per PW, per MAC, etc.? - Rohit: Not per PW, because that will be in PW MIB. So, it will be the number of packets/bytes received for a particular VPLS. - Kireeti: Does Bridge MIB have counters per MAC? - Rohit: Yes. - Kireeti: So, perhaps we don't need this? - Rohit: Possibly, yes. 7) SNMP Context Mapping MIB http://tools.ietf.org/html/draft-kkoushik-snmp-context-map-mib-01 Rohit Mediratta (rohit.mediratta@alcatel.com) - Presenting on behalf of Tom & Kiran. - Ingenius approach, but not sure this solves all the problems. - Two ways to introduce MIB's for new protocols: a) We deprecate old MIB's and create new one's in IETF; or, b) We take this approach and add SNMP context to distinguish between different instances of the protocol. - SNMPv3 already has contexts; SNMPv2/v1 can use mapping of community name to context. - Applicability to VPLS: map VplsConfigIndex to dot1dBasePort, which is an index into BRIDGE-MIB where MAC addresses are stored. This means we don't need multiple copies of the BRIDGE-MIB. Every VPLS instance gets its own copy of the BRIDGE-MIB, which stores MAC addresses specific to that VPLS instance. - Problem with this approach is how do we map a PW as an AC into the BRIDGE-MIB? Questions: - Kireeti: Isn't this a question for the SNMP WG, if such a thing exists? - Rohit: Agree, because using contexts is a more general solution and may present other problems with respect to scalability. This is something Tom & Kiran should probably discuss with OpsArea. - Jeff Hass: I think you've just reinvented the Entity MIB. - Rohit: Proably should take that off-line to discuss. Tom & Kiran could probably answer better than I. 8) VPLS Interoperability with Provider Backbone Bridges http://tools.ietf.org/html/draft-sajassi-l2vpn-vpls-pbb-interop-02 Ali Sajassi (sajassi@cisco.com) - No changes to draft, just an update. - Discussed changes relative to -01 revision. - Discussed Main section in document. - Discussed 1st scenario: Native 802.1ah to VPLS core. - Discussed table of VPLS with 802.1ah in draft, which describes what type of interface, the svc delimiter to expect, etc. - Discussed 2nd scenario: 802.1ah encaps over H-VPLS. - Discussed table of VPLS with MPLS access network with 802.1ah on U-PE. - Discussed migration scenario. + In one access network upgrade MPLS U-PE with 802.1ah, how do they work together? + In upgraded network, a PE needs to have inverse IB-BEB capability. Inverse IB-BEB PE needs to de-encapsulate 802.1ah frame before sending to a non-upgraded network. - Next Steps + Ready for WG call, but not going to request it at this point, because still discussing how to arrange contents of this & other drafts to cover: o data-plane interworking for native .1ah with VPLS; o data-plane interworking for native .1ah over H-VPLS & migration; o control-plane, which Florin has started on. + Other areas that need to be covered: MAC flushing, multicast, etc. + Going to work off-line in rearranging contents of these two drafts and send it out to mailing list prior to next WG meeting. + Perhaps be ready for WG call by next WG meeting Shane: Also, it's important to note that before we ask to accept these drafts as WG items we need to see that "scalability" is included in re- charter effort, which we're send out after this WG meeting. Ali: OK. Questions: - Loa: Is is true that you can have .1ah capability in some PE's and other PE's that don't have it in the same VPLS? - Ali: Yes. That was one of the scenarios we were asked by providers to cover, because providers said we can't upgrade all our PE's to support .1ah capability. - Loa: U-PE's or N-PE's in one network need to have knowledge of U-PE's in another network? - Ali: It needs to have the MAC addresses for the customers ... - Loa: ??? - Ali: It operates the same way as it does today. Today, the N-PE needs to have the MAC addresses for everybody. So, the IB-BEB will have the MAC addresses for the end-users in the non-upgraded networks. - Loa: But, he will do two operations depending on the end-nodes. He will either forward the frame or do the Inverse thing on it, so he needs to know the capability of the end-node. - Ali: Good point. Inverse IB-BEB needs to perform two different operations based on information he receives via Auto-Discovery. A-D will tell the Inverse IB-BEB if the receiving node is .1ah-capable. This is something that Florin is looking at. - Loa: So, there will be an update to the Auto-Discovery draft? - Ali: Yes, it's going to be part of the Auto-Discovery draft. - Florin: It's also important to consider the N-PE's in this diagram might be owned by 3rd parties and it might take a very long time for them to be upgraded. Another scenario that's interesting is what if you have a VPLS that spans both .1ah and MPLS access networks? In that case, you have Customer MAC and Backbone MAC interconnection in the same VPLS over the same core network. It could be handled if the VPLS model were extended. One of the challenges is going to be resiliency, because you can only have one active point of interconnection between the I-domain and Backbone domain. - Ali: The N-PE's are fully meshed, so they're resilient. - Florin: So, do you have one mesh for Backbone MAC space and another full-mesh for customer MAC space? - Ali: No. There will be one full-mesh across all N-PE's. Some PW's will be indicated as .1ah-capable and the others will not. So, it will be one full-mesh just like today's VPLS. - Florin: I think we need a more detailed picture of the network, in order to see where we need different types of PW's. - Ali: I don't think we need separate meshes. - Dinesh: To go back to what Loa was asking. From point-of-view of Inverse IB-BEB N-PE, it's only aware of what are the capabilities of the other N-PE's in the other access networks. The N-PE's don't need to know about the capabilities of each of the U-PE's. - Loa: So, we need to upgrade all the U-PE's at the same time? - Ali: No. If you change all your U-PE's at the same time, then you don't need Inverse IB-BEB functionality and everything works fine. - Loa: From my understanding, you're saying that I don't have to upgrade all my U-PE's at the same time, but Dinesh is telling me I have to. - Dinesh: All the U-PE's in a single access network have to be upgraded to be .1ah capable. - Ali: Within that access network, so far, my assumption has been, yes. But, if you have Inverse IB-BEB functionality, you can apply it not only within the VPLS core, but also to Spoke PW's from N-PE to U-PE's in partially upgraded networks and you get the same thing. - Dinesh: That part has not been expanded. - Ali: Agreed. That is a good point. We should cover this in future revision. 9) VPLS Extensions for Provider Backbone Bridging http://tools.ietf.org/html/draft-balus-l2vpn-vpls-802.1ah-02 Florin Balus (florin.balus@alcatel-lucent.com) - Reviewed Background and Objectives, Version 1 + Look at extensions to existing VPLS model to accommodate 802.1ah. - Reviewed changes in Version 2 - Discussed next steps + Need more input on requirements from WG - Look at backup slides for more info. - Would like feedback from WG on: a) How we split up solutions components between drafts? b) MAC flush section. Everybody uses empty MAC list to flush all MAC's, not a specific list of MAC's. Questions: - Florin: Question to Shane. You think this is an area we want to study, it's just a matter of making sure the language in the charter is the right one to put in the charter? - Shane: This draft and the previous draft are areas that are not covered by the present charter, specifically scalability and the details behind what we mean by scalability are not in there. So, we need to ask the wider WG if there is interest in this area and then include it into the new charter. - Florin: Understood. - Nurit Sprecher: Is this draft complementary to the other draft or overlapping with the other draft? - Florin: Initially in version 1 there was some overlap in terms of reqmt's and use cases. In version 2, I think we tried hard to eliminate the overlap between the two drafts and didn't see any comments from Ali or Dinesh that there was overlap. So, ultimately, they are trying to be complementary. - Ali: It is getting better in terms of not overlapping. This is the draft that I mentioned at the end of my presentation that is hopefully going to cover the Auto-Discovery and signaling components of .1ah and VPLS interoperability. - Dinesh: When we talk about solution in the WG, that implies we're talking about a new protocol or enhancements to an existing protocol. On the other hand, if a draft specifies how existing protocols or specs can be utilized, then it may not be perceived necessarily as a solution. - Florin: I didn't mean that. What I'm saying is what are the changes required across the different types of networks and what are the changes needed in the protocols maintained by L2VPN and PWE3. - Dinesh: Right. I wanted to point out the draft-sajassi, which discusses interoperability also has solution components more on the data-plane, particularly with respect to applying existing protocols to .1ah networks. - Florin: When I say basic solution components, I'm more focused on communicating what new TLV's are needed in RFC 4664, in terms of framework and other details. Also, helping people understand what components come together, similar to what Loa was asking about when PW's are mixed up. - Luyuan Fang: Similar question to what Dinesh asked. We are clear on the framework that Ali presented, with respect to interworking H-VPLS and .1ah, plus migration scenarios between the two. When we come to the solutions part, I'm not clear on what areas of the details you are referring to that are not already covered in Ali's draft? - Florin: Did you read version 2? - Luyuan: No, I read version 1. - Florin: If you read version 2, I think it should be more clear what this draft is trying to address. Also, we'll take it onto the mailing list. - Ali: The data-plane solutions are already covered in my draft. With respect to control-plane solutions, that is going to be covered in Florin's draft. And, other areas, as needed, we're going to create new drafts. - Luyuan: ??? - Florin: MAC flush, from tLDP (non-IEEE) perspective, is already covered in version 2. - Ali: With respect to MAC flushing, there are other areas we need to consider. When you do MAC flushing in .1ah, you're flushing C-MAC addresses associated with B-MAC addresses at the U-PE's. Trying to send signaling message hop-by-hop and transfering that signaling message between two LDP sessions where you don't perform anything at the intermediate node needs to be evaluated against other mechanisms. - Florin: That was actually already implemented for VPLS resiliency: active & standby PW's, which I think you already have an implemention of. - Ali: I was talking about .1ah & MAC flushing. - Florin: Yes, so was I. I was talking about the propogation of MAC flush messages in regular VPLS for active/standby PW's. - Ali: In regular VPLS, you're flushing MAC addresses in the N-PE's, because C-MAC addresses are in the N-PE's. In .1ah, you want to flush the MAC addresses at the very end-points. - Florin: In regular VPLS, you go through two hops of N-PE's. What's the problem with going through two or more hops of N-PE with .1ah? I think that should work OK. - Ali: My point is in one case you take action at the N-PE. In another case, if you don't take action at the intermediate N-PE, then that's a different issue. - Florin: You're saying you shouldn't intercept that message, because it's in the customer MAC space, right? - Ali: Yes. - Florin: That's what we covered here. It's not going to intercept the message and it isn't going to flush it. Did you read the MAC flush section? - Ali: It doesn't intercept the message, but it gets it from one LDP session and passes it to another LDP session. You don't call that interception. - Florin: It won't react, it won't flush the MAC's. The N-PE's don't have to flush the MAC's. - Ali: There is another mechanism that needs to be evaluated. - Shane: Ali, please take it to the list, we're out of time. 10) Regional VPLS http://tools.ietf.org/html/draft-vkompella-l2vpn-rvpls-00 Vach Kompella (vach.kompella@alcatel-lucent.com) - Another thing not yet in charter. - How do you scale a VPLS when you get a large number of nodes? + One approach is a full-mesh, but you have too many sessions, lots of replication. Good news is you don't use too many labels. - Came up with another model called Hierarchical VPLS. + Reduces number of sessions and reduces replication at each of the edges, but it does increase the number of MAC's learned at N-PE's. As the total number of VPLS instances increase, then you could have a large number of MAC's at N-PE's. It also has more PW's, which means increased number of labels. - If you use MS-PW's, then you keep # of sessions low and MAC address learning to a minimum, but you still have the replication problem and we use a lot more labels. - Learned there are multiple dimensions to scaling a VPLS: number of sessions, amount of replication, MAC address learning and total number of labels being used. + What we're trying to do is break up the sessions and have stitch points in the H-VPLS or MS-PW context, which would reduce the number of sessions. Also, by learning MAC addresses somewhere in the middle of the network, then you would reduce the amount of replication. + The absolute minimum in terms of state for MAC addresses would happen if only the edge nodes learned MAC addresses, but if you introduce that hierarchy, then you start learning MAC addresses in the middle. + Three models before only address some parts of the scaling problem - Came up with Regional VPLS: + Sort of use MS-PW for scaling sessions + Sort of use hierarchy to scale replication & labels + Use regional labels to reduce amount of MAC addresses being learned - Regional VPLS model: + End-points (edges) need to maintain full FIB + Half-FIB: you don't learn all the MAC addresses in a VPLS context, just those from the region + Regional PE: behaves differently than regular VPLS PE. Like S-PE toward the core and N-PE to the region. - Discussion of how R-VPLS forwarding works with MAC learning - Discussion of how to optimize R-VPLS forwarding, by using a Flooding PW inside the region. - Discussion of how R-VPLS forwarding works in reverse direction - Discussion of how R-VPLS forwarding works for unicast traffic, after MAC learning has completed. - Advantages of R-VPLS + Optimzied flooding, fewer PW's, fewer sessions, smaller # of labels, limited MAC learning at N-PE's. - Next Steps + Auto-Discovery + Dual-homing of R-PE's + Quantifying how R-VPLS scales comapared to other solutions + Potentially ask for WG consensus to make this a WG draft after re-charter and if there's enough interest Questions: - Ali: Question on second diagram: we should have fewer PW's here compared to if you went end-to-end, correct? - Vach: A particular node may have more labels to deal with, like the N-PE, than if you went end-to-end. - Ali: For every region we're going to have one PW from a PE to the R-PE for each remote region? - Vach: Yes. - Ali: As opposed to a single PW between the PE and the R-PE and the R-PE looks at the MAC address. So, there is a trade-off here? - Vach: Yes. The trade-off is do you want to have what looks like a MS-PW sort of behavior vs. learning everywhere? - Ali: If I'm doing .1ah encap at PE's, then that takes care of MAC address scalability at the R-PE's and takes care of PW scalability. - Vach: Yes, it does. But, people have said that they don't want another encap or don't want to run another protocol model in the access networks. Basically, it's a provider's choice. - Ali: This is a whole new protocol & new mechanism, though, right? - Vach: It's the same tLDP, it's roughly the same behavior ... - Ali: You do half-learning in one direction, but not the other. This is a whole new paradigm, right? - Vach: Yes. - Kireeti: This is not really optimized flooding ... this is better flooding. You're still doing ingress replication in each region and in the core, but you're reducing the scope of that. Optimized flooding is when every hop does replication. What that points to is use P2MP LSP's. - Vach: Yes, but that's an orthogonal question. - Kireeti: It's not orthogonal. You're putting replication points at certain points in the network, rather than putting them everywhere. - Vach: This could be used in conjunction with P2MP LSP's within a region. - Kireeti: But, you could do flat P2MP everywhere. - Vach: That assumes you want to do flat P2MP across regions. - Kireeti: Take a step back and ask: do I have to even use hierarchy at all, when flat P2MP is easier to deal with? - Vach: But, what if the different regions are different administrative domains? - Kireeti: Understood, but if you start with the problem of replication and sessions, and not administrative domains, then R-VPLS is a creative solution, but it changes the forwarding paradigm in a fairly complex way. If you say you need different administrative domains, then that's a different thing. Use BGP, use route-reflectors -- you're done with scaling sessions, use P2MP and you're done with the flooding problem. - Shane: But, have you solved MAC address scaling? - Kireeti: The MAC addresses only live in PE's, so the scaling should be the same between VPLS-BGP and R-VPLS. - Ali: With P2MP, you don't do any MAC learning at the R-PE's. There are two ways to address this: 1) use .1ah encapsulation; or, 2) use P2MP. The question is: do we need a 3rd mechanism to solve this problem? - Vach: One of the things we wanted to do was also limit the size of every multicast tree. So, if I had to do huge multicast trees, if I could limit the size of those trees, then that would make everything better. - Kireeti: You have MAC tables every place, which means you need a complex OAM mechanism. A flat network is easier to run. - Vach: That is easiest, but is not necessarily manageable in terms of a large network that has a large VPLS that spans multiple areas. Even if a VPLS spans multiple areas and its in the same administrative domain. I wouldn't say multicast trees are easy to do. - Kireeti: The number of PE's have to be constrained in a single VPLS. If there are 10,000 PE's in a single VPLS, you're doomed. - Vach: We have such networks with more than 1,000. - Kireeti: End-points for a single VPLS networks? - Vach: Yes. - Kireeti: That's broken. - Vach: I wrote this draft in 2002, but thought: who's going to do this? We're running into customers now that need this sort of thing. There are a large number of PE's in a single VPLS, and we can't solve it with flat meshes. We need to break up a VPLS with stitch points in the middle. - Florin: When you reach a certain size in VPLS, you can't do it with full-mesh. You will always need hierarchy at a certain point in the network. Even Enterprises aren't doing a full-mesh w/out hierarchy. - Hamid Ould-Brahim: All PE's and R-PE's must participate in the R-VPLS operations? - Vach: Yes. - Hamid: If there are some regions that don't participate, then the R-PE's will end up learning all the MAC's for that region, in which case the benefits of this are minimal? - Vach: Yes. That would be a problem, so you would have to be mindful of that. 11) Multi-homing in BGP-based Virtual Private LAN Service http://tools.ietf.org/html/draft-kompella-l2vpn-vpls-multihoming-00 Kireeti Kompella (kireeti@juniper.net) - People want multiple connections from a CE to multiple VPLS PE's. - One solution is to run Spanning Tree on CE's. Problem is: + provider wants control to avoid customer's making a mistake; and, + provider wants to influence choice of the PE that is used by CE. - Solution: + PE1 and PE2 know they are connected to same CE site by configuring the same site-ID or VPLS-ID on the two VPLS PE's. + The prefix the two PE's advertise is roughly the same, so a remote PE can use BGP path selection to select one of the two. The winning PE knows he's connected to the CE and the other PE is "silent". - Discussion of multi-homing diagram - Differences with VPLS and IPVPN path selection: + Can't do ECMP -- must pick one of PE1 or PE2 and do it consistently. + Specifically, can't use IGP metric in BGP path selection. + Losing PE also must know it lost. - Chanages to BGP Path Selection. Details in draft. - Result is only Designated PE forwards packets to/from CE. Non-Designated PE's drop packets from the CE as well as destined to the CE (from the core). - Also interested in work in PWE3 with respect to OAM message mapping. That's one way the PE can know it lost connectivity to the CE and redo path selection to choose a new designated PE. Questions: - Florin: What happens with a multiple single-homed CE's terminated on a single PE? - Kireeti: It will work. Each CE gets its own Site-ID, so they're different prefixes and remote PE's will do path selection for each. - Florin: Each CE has different Label Blocks? - Kireeti: Yes. - Florin: Can you put all these CE's in the same bridge group? - Kireeti: Yes. - Florin: How do you communicate from PE1 or PE2 to CE1 as to which link is active? - Kireeti: PE1 and PE2 never communicate with CE1. - Florin: But, if CE1 has MAC addresses that point down a particular link that isn't used anymore then the PE's need to tell the CE to flush those MAC's so they can be re-learned over an alternate link. - Kireeti: Yes, but this solution doesn't do that. - Florin: Last comment. You have to withdraw these Label Blocks when you switch from PE1 to PE2, right? Which removes data plane forwarding for that path on remote PE's, right? - Kireeti: Correct. - Florin: OK. I think we can do this same scheme with VPLS-LDP and Auto- Discovery without removing the data plane forwarding entries. - Kireeti: Instead of removing the route, we have something in Auto Site ID which is a "Down bit" that says we're removing the route, but don't actually remove anything, instead it says "count me out from path selection", because I'm not connected to the CE. - Florin: So, you're open to including procedures for the other VPLS scheme in here? - Kireeti: Sure. - Eric Gray: You said you can't do ECMP-like things. Are you talking on an Ethernet basis or a VLAN basis? - Kireeti: It doesn't matter. - Eric: It does matter, because if you're doing individual learning on a VLAN basis, then you can have them separated by VLAN. - Kireeti: So, you're talking about qualified learning? - Eric: Yes. - Kireeti: But, I meant for a particular MAC table. If it's qualified learning for a particular VLAN, then I can't share this across PE's; however, if it's unqualified, then I can share it. - Ali: How does this work for H-VPLS? - Kireeti: VPLS-BGP has no hierarchy of data plane, however it does have control plane hierarchy through route-reflectors. VPLS-BGP is a flat network. - Igor Bryskin: If everyone in the VPLS network understands that PE1 is a winner (including PE2), what happens when CE1 decides to send a Ethernet frame to PE2, because CE1 ran Spanning Tree or selected it through its a local policy? - Kireeti: If CE1 runs STP and sends BPDU's to both PE1 and PE2, then PE2 will drop those BPDU's. Therefore, CE1 should only select the path through PE1. This is orthogonal to the CE running STP. SP's don't want to rely on the customer to ensure proper operation of the SP's network. - Eric: So, is it possible that CE1 through local policy could still select PE2 for forwarding? - Kireeti: It is possible and would mean CE1 would be disconnected. Local policy is a problem. - Luca Martini: You acknowledge you could have loops. Don't you need something faster like STP to clear that loop to avoid catastrophic failures? - Kireeti: Spanning Tree is not that fast or robust as I would like it to be. STP also takes control away from provider and into the customer network, depending on what the customer selects for their root bridge. However, you can run both and they work fine together. This mechanism is designed primarily to prevent permanent loops. You could still get transient loops. I recommend to providers that they configure flood filters within each VPLS to prevent a catastrophic problem. - George Swallow: What if you have a misconfiguration or a race conditions in path selection? - Kireeti: If PE1 & PE2 were misconfigured, then you could have a loop right away, which is why I say run STP on CE's and PE's if you want, but don't use that as your first line of your defense. - George: I think you might be mixing BGP and Ethernet control in ways that might be operationally unstable. - Kireeti: No, I think they're solving different problems. If you're misconfigured, you're misconfigured. - George: I was talking about BGP path selection, because consistency across the network isn't required. - Kireeti: The modified path selection algorithm is deterministic. This is meant to prevent permanent loops. - George: I just think that you should analyze what could happen when you have race conditions. - Kireeti: We did, but we'll look at it again. - Wim Hendrix: How do you prevent uni-directional failure? - Kireeti: Unless you're running a good OAM solution between the PE's and CE, then you're not going to detect it and be able to react it. - Wim: Right. It's best to have another layer of protocols to be more resilient with dual-homing. - Ali: Is one of the premises for this that the provider doesn't want to participate in STP with the customer? - Kireeti: The premise is you don't want that to be your first line of defense. - Ali: In IEEE, they worked on a protocol called L3GP. PE's wouldn't need to participate in protocol, only CE's. Upon failure detection, the CE would send an indication to its immediate upstream PE, which it could react to. - Kireeti: That's OK, but SP's don't want to rely on customers to configure their networks properly so the SP's network operate properly. Here's an approach that works today, that's already used for IPVPN's, so let's extend it for VPLS and get some benefits of that. - Shane: Taking WG chair hat off. If the IEEE standardizes L3GP and it's enabled, by default, in shipping equipment in the future and SP's could have a reasonable level of confidence that it's not going to be disabled, because it creates other problems for customers, then we can perhaps look at relying more on customer equipment to avoid Layer-2 loops that may melt an SP's network. If that's not there, then SP's can't rely on customers to protect their network's operation. - Ali: I agree with your first point. However, I'm saying there are other mechansims that are PE-based, not CE-based that can work for not only for VPLS, but also H-VPLS. - Shane: What drafts are there that describe those mechanisms? - Ali: That draft hasn't been published, yet. - Shane: Service convergence, including this draft here, is an important area of work and we should make sure to get that in the new L2VPN charter. *) Meeting Closes