L2VPN Meeting Minutes - IETF 81 (Quebec City) Document Status: [Nabil] Request for WG last call on: draft-ietf-l2vpn-ldp-vpls-broadcast-extn-02. Draft relies on protocol in PWE3, but that draft is still undergoing changes. Once the p2mp pseudo-wire drafts go to WGLC in PWE3, we'll issue the call here. [Giles] We're behind on last calls. We'll start issuing them after IETF 81. [Giles] Yuji has updated draft-ietf-l2vpn-vpms-frmwk-requirements-04. Added multi-source but not multi-coverage. [Glles] One of the question with the drafts is do people think they are sufficiently notable to be progressed. Quick survey of room - only 3 non-authors who have read the vpls-macflush-Id draft, so we'd like to see other people read it. [Nabil] We'll talk with the authors, but we may pick an expert review to look at macflush. For these documents that may go to RFC and even standards-draft, we really need to take ownership and do good reviews and comments. [Giles] During WG last call for multihoming draft, it would be good to see "I read it and it's ok" or "I read it and..." so we know there's enough interest to proceed. [Giles] New charter is done and published to the list. Stewart is about to take it to the IESG - but... should we remove reference to "provider-provisioned" VPNs? The OTV draft presented in RTG Area did bring up a couple of questions. We also somehow managed to remove references to IP PSNs. Do we want to keep them in scope? [Florin Balus] We have a lot of expertise here on virtualisation, multi-tenancy, VPNs etc. So we should look to address anything related to virtualising various instances here. Definitely in the datacenter environment, won't be MPLS all the time - more IP and Ethernet. So I think we should keep IP if we want to get into that space, and we should probably remove provider because everyone assumes it means telcos. [Giles] Charter says provider-provisioned due to history of L2VPN and L3VPN coming from PPVPN WG. [Himanshu Shah] Yes, we should keep the IP PSN part of it in the charter. We also had some comments on the charter for the verbiage. Have you cleaned it up? [Giles] The key issue was around control-plane learning of IP/MAC information. We took the verbiage out because it was straying into mechanisms rather than requirements. [Himanshu Shah] Unrelated question, what about IPLS? It is a working group doc... [Giles] It clearly has some relevance to the debate on EVPN. A matter for the WG to discuss as to whether to bring into discussion on EVPN or publish it as historical. Maybe idea before its time, but never implemented. Would like to hear group figure it out. [Himanshu] In data-center, IPLS is an applicable solution. Either informational or standards track is fine. [Nabil] Don't want to spend our time on something no one is interested in, not implemented at all. If this is data-center focus, should we wait - or we could poll the WG. [Stewart Bryant] If you have an old doc, there are many ways it can be published without taking it through the WG. If the doc has essentially died and no one has implemented, there are ways of doing it through the WG or publishing otherwise (e.g. AD-sponsored). Need to decide if this is an appropriate use of your WG time other than to archive it. [Himanshu] For what it was originally intended, not implemented. For data-center interconnect, yes. [Nabil] So, what do you think about waiting for the real application of data-center to happen? [Himanshu] I'm fine with Informational. Let industry decide. [Wim] We should not remove IP PSN. I know folks who use the current solutions over IP networks. We should remove provider-provisioned, because everyone can have their own ideas on what is a provider. [Stewart] Deciding to remove a significant restriction on applicability will require discussion. That scope restriction has been there since the beginning. [Giles] Provider Provisioned was probably driven by the L3 case where PPVPN didn't want to start standardizing IPSEC VPNs. [Stewart] It's about whether the background service provider is instrumental in providing the service & we should think about it before declaring these are the same. [Nabil] IP PSN has always been in the charter. [Stewart] It was, but it got taken out because no work had been done on it. The provider-provisioned has been there since day 1. [Giles] Let's discuss these on the list. From what Stewart's saying, it sounds like the IP PSN will come back in. For provider provisioned it'll be more effort. [Stewart] You have to go through the same process. I can discuss with my IESG colleagues. Apart from TRILL this is where VPN things happen. The difference between this and TRILL is that here it is over IP and MPLS and TRILL does over its own thing. [Giles] Ok - will take to the list. Sorry the charter is dragging on. We can proceed assuming E-Tree and E-VPN are in charter. But also there's a lot of existing stuff to last call. ----------------------------------------------------------------------- [Florin] presented draft-ietf-l2vpn-vpls-ldp-mac-opt-04 [Giles] Have a lot of people read this? (many hands). And how many like it? (many hands). So, let's get the new spin of it done and take it to last call. ----------------------------------------------------------------------- [Daniel Cohn] presented draft-ram-l2vpn-ldp-vpls-etree-2pw-02 [Yuanlong Jiang] The VSI model in your draft must forward frames based on the port attributes. This will dramatically change the VSI and will be prohibitively expensive to implement. Also, only covers use case where the AC is directly connected to the UNI. Have the authors considered H-VPLS (RFC4762) basic VPLS models (RFC4664) and advanced VPLS (RFC6246). [Daniel] good point - from what I've seen in the charter, E-Tree reqs come from MEF so only need to support leaf and root UNIs - not mixed, and I haven't seen it as a requirement in practice. so we need to align on the requirements and see if each proposal meets them. [Yuanlong] But there are deployments in the field. [Daniel] Everyone can say what is deployed in the field. First we need to agree on the requirements. [Nabil] If there is something missing in the requirements, we need to agree on that. Requirements drive solutions. [Yuanlong] Also all the RFCs and WG drafts in this WG depend on there being only one pseudo-wire between one pair of PEs, so if we accept this draft all these docs need to be updated. [Daniel] Some of the pseudo-wire redundancy drafts have two PWs between two PEs. [Yuanlong] RFC4761 and RFC4762 etc. would need to be updated. [Giles] Also I don't think that's the case. For example in the PE-r case in H-VPLS, you need multiple PWEs between the two PEs because of lack of MAC learning. [Daniel] The pseudo-wire redundancy drafts describe the model of two PEs connected by two PWs. [Yuanlong] all the signalling only deals with one PWE. If you have two PWEs you will need to update it. [Daniel] I don't think anything precludes having two PWEs. Again in the PWE redundancy draft that's exactly what it defines. [Giles] Please point us to documents that we would need to change as a result. [Wim] If we have more than 2 roots in the E-Tree what are you going to do? [Daniel] One pseudo-wire forwards traffic for all the roots between two PEs. [Wim] So a full mesh between all the roots with additional PWEs? [Daniel] No, I assume there's a full mesh in the core? [Wim] So if you have more than 2 roots, then you need a full-mesh and know where the packet came from? [Daniel] No, within the Ethernet frame you have the information. All you need to know is whether it came from a root or a leaf. [Wim] So your proposal is you have a pseudowire indicating whether it comes from a root or a leaf, right? So if you have multiple roots you need a full mesh between all the roots to indicate where the packet originated from. [Daniel] You need twice as many pseudo-wires as in the core. Only in the core. [Wim] Other solutions are more elegant as don't change the number of pseudowires required. [Daniel] Yes, but they require an additional level of VLAN tagging which isn't supported by the deployed silicon, and have requirements in terms of VLAN co-ordination which makes it difficult to deploy. [Wim] Do we have evidence that silicon doesn't support it? [Daniel] Yes. But I don't want to finger-point here. [Wim] also this won't support Ethernet pseudowire interworking, because the root won't be directly connected to the AC. [Daniel] That's back to the MEF requirements with Root and Leaf UNIs. [Florin] What was said about VPLS PE architecture needs to be double- checked. We put in place mechanism to prevent two PWEs between two VPLS instances because you get a loop. I understand your draft will work because you have the TLV telling the PE to forward in a certain way. But if some PE doesn't understand the TLV you can get loops. A bigger issue is networks with a mix of native Ethernet and MPLS. I would prefer to have one mechanism (VLANs). Easy to implement and works across native Ethernet and Ethernet VLAN pseudo-wires. Remove the VLAN tag from the UNI, put the pseudo-wire and keep the customer tag. You replace the SP tag with the PWE label and leave customer tag transparent. [Daniel] What if you're carrying traffic from different service providers? [Florin] Everyone can check 2 tags. Some of the stuff you've put here like the VSI type is good and I think the two drafts should be merged, but we should also try to drill it down to one solution. [Giles] Let's get the requirements right and then we can merge the solutions. ----------------------------------------------------------------------- [Yuanlong Jiang] presented draft-jiang-l2vpn-vpls-pe-etree-04 [Giles] On the WG draft question, as we've already said - we need to get the requirements right. It would be premature to accept either this draft or Daniels as a WG draft until we do that. [Wim] I agree that we should merge the drafts and then get a WG draft. [Sami Boutros] I guess you'd be adding a private VLAN on top of whatever VLAN already exists to specify the policy (root or leaf). [Yuanlong] You can apply an extra VLAN, or translate. [Wim] You can do translation or strip one, add one, but it depends on deployment. [Sami] But if you add a VLAN, it wouldn't be regular IEEE Q-in-Q.. [Yuanlong] Actually, it is standardised in the Broadband Forum. [Sami] Did you consider PWE as well for the policy? [Yuanlong] Yes, you can translate VLAN into PWE, but signaling would be changed also. [Daniel] if you have a framework that requires you to transmit the S-VLAN or P-VLAN, then I know that there is hardware that doesn't support 3 VLAN tags. [Yuanlong] I think the 3 VLAN tags is out of scope of MEF itself. MEF defines C-VLAN and untagged access. It's not a requirement of the MEF itself. [Daniel] But your solution requires a third tag. [Yuanlong] Not my intention. You can use S-VLAN or S-VLAN plus C-VLAN. [Daniel] But if you have a requirement to carry the S-VLAN transparently, don't you have a requirement to add a third VLAN to represent root or leaf. [Yuanlong] You can transport S-VLAN transparently as it's a trunk service not E-Tree access. [Daniel] but there are scenarios where you have to transport S-VLAN between PEs. [Yuanlong] I think you mean MEF ENNI. Maybe we can wait for the standard to be published, but I think it is ok and out of scope of the requirement. [Daniel] I don't think that's the only requirement, but let's discuss on the list. [Nabil] The requirements are where we need to make sure they are very clear, synchronise with the MEF work, and therefore the solutions will follow (there seems to still be some gaps). [Florin] It's not important how many VLANs are in the frame until you run out of bytes. What is important is how many VLAN tags you have to look up. This is just between the devices that have root and leaf. The rest of the network doesn't need to receive the leaf or root VLAN tags... Let's take what IEEE developed and port it as much as possible - we did that with PBB. So if that works, then we should do this way. [Yuanlong] PBB can also be incorporated in this solution. [Maciek] (side comment) I don't believe that a frame format with more than 2 tags is standardized by anyone, certainly not by IEEE. I also understand that more than 2 tags are supported by deployed gear as long as no more than 2 tags are manipulated. If we need to use more than 2 tags, then we need to decide if that could be a standard. Would have to be in IEEE. ----------------------------------------------------------------------- [Ning So] presented draft-so-vdcs-00 [Ning So] Anyone interested in this type of work? (some hands) [Giles] Maybe the interested peopled can decide where to take it. We've seen this presentation a few times. It's clearly massively out of scope for L2VPN, but maybe some parts would come back here. [Ning] What does our AD think? [Stewart] I can't immediately think of another working group and you know the process if you can't, which is attempt to form one. [Ning] Big task [Stewart] Not the end of the world [Himanshu] Is it the dynamic aspects of the creations of the l2vpns? I don't know at the networking level what you see. [Ning] For instance, if you have a l3vpn and assume in the data-center you have an SPC running 802.11aq, you need to produce a description of how the mapping is going to happen. How do you assign the resources to the l3vpn and that's a hard problem? New protocol interworking needs to be worked out - and quite a lot of things need to be considered. [Giles] This is where I'd normally say take it to the list. but in this case create your own list and take it there. [Stewart] Ning - Why don't you and I talk about this afterwards? ----------------------------------------------------------------------- [Lizhong Jin] presented draft-liu-l2vpn-vpls-inter-domain-redundancy-00 [Florin] What are you trying to do in this draft? There are lot of different options other than STP already. some want to do LDP & some BGP. Some are using option B & some C. What are you trying to do with the draft? [Lizhong] This requirement is from China Telecom. We can add more context to this. [Florin] If there is nothing to standardize, it's not appropriate to bring it to l2vpn. [Giles] There is scope, sometimes, for BCP, but then we'd have to agree that this applies here. Given the range being done, we'd either have to doc everything or agree this is a good approach with pitfalls to avoid. But we don't want to tie up IETF publishing resources either. [Florin] This isn't option A, it's a mix. It's option A with pseudo-wires. But if you go for inter-providers, then it could be option B. We kind of touched on these in the solution draft. If someone wants to do a BCP, then we need more a comprehensive draft. [Nabil] We'll take this to the list. There could be value in a more comprehensive BCP. ----------------------------------------------------------------------- [Sami Boutros] presented draft-sajassi-l2vpn-pbb-evpn-02 [Anoop Ghanwani] Where do you see the PBB initiating? From TOR? Or the aggregation switch? [Sami] From the PE connected to the access network. Assuming 802.1aq or TRILL in the access and so the packet you receive is already tunnelled. [Anoop] You mention TRILL on your slides, but then you also mention BMAC all over. [Sami] Details on how we're going to be doing the interworking with TRILL or 802.1aq and E-VPN isn't flushed out in the draft yet. [Florin] It's probably simpler if you start from TOR. ISIS and BGP is perfect to scale a big deployment. It's the same type of integration that you need for EVPN as we did for PBB VPLS. Ideally, we take the TRILL encap and parse it the same way we did with PBB. [Nabil] there are issues with TRILL that need to be addressed. [Wim] the scope is focused outside of the data-center & goal is to try to be agnostic of what is happening in the data-center. [Anoop] It's just a little like TRILL, but the scope is a bit different and if you have global scope you might run out of rbridge IDs. [Sami] Like I said, this has not yet been fleshed out yet. ----------------------------------------------------------------------- [Sami Boutros] presented draft-sajassi-l2vpn-evpn-segment-route-00 No questions / comments... ----------------------------------------------------------------------- [Nabil] Meeting closed.