agenda bashed ARP-MED and IPLS - added IPv6. sent email to IPv6 and v6ops lists asking for comments. please review - especially v6 stuff. want to last call these in next month or so. Andy - can we please discuss being able to share one IP PW for v4 and v6. currently need separate PWs. Himanshu - problem with v4 and v6 is how do you know which you're encapsulating? Need to parse IP header. but if other people want it we can make those changes... Please comment sooner rather than later - last call in next month. Mark Townsley - we should make it as easy as possible to migrate from v4 to v6. There's a perfectly good version field at the start of the IP header! Shane - need to move on draft and progress it. OAM message mapping still out there. VPLS MIB. No objections to it becoming WG draft so will publish. Still need to work out how to support bridge MIB per VPLS. multicast work has stagnated. additional work areas likely to be: 1) VPLS OAM 2) fault detection of partial meshes Shane - speaking as an operator have recently experienced cases where these tools would have been nice... VPLS for PBB - Florin ---------------------- Ali did interop draft, but need solution draft on VPLS. pretty much focussed on VPLS PE structure and using the topology example where we have an MPLS network. Doesn't preclude PBBN? access network into the VPLS PE. 2 more co-authors so added their input. focus is extension to VPLS. Follows RFC4762. Focus on intra-domain and integrated model of PBB VPLS. went through requirements diagram. Worst case is multiple VPLS domains with regular VPLS and Ethernet access network. In this case VPLS is switching customer MACs. Want to include PBB selectively for certain VPNs to improve scale etc. In the edge PE we add PBB VPLS to hide MAC space from PEs in core. Requrement for core PEs not to be aware of PBB. Requirement was to be able to deploy either selectively or generally... may either map 1 I-SID to 1 VPLS, or multiple (depends on the customer's requirements - and enables an extra layer of aggregation). "I-SID bundling into PWEs" overall aim is to use PBB capabilities but to get MPLS benefits in core. edge PEs know mapping from customer MAC to backbone MAC. They also add the service and tunnel labels. Core PEs don't look at the customer MACs at all, just the backbone MAC. At egress the edge PE has to terminate the B-MAC header and then look at C-MAC. So have a virtual port per B-MAC and do C-MAC switching. example on slides is MPLS end to end so no VLAN etc. In Ethernet access cases have an extra VLAN header in the frame. extra layer of backbone MACs introduces potential blackholes. Edge PEs point customer MACs to a remote PE. If the link from the CE to that PE fails then another PE becomes active. Normally we do MAC withdraw to flush the entries. But in this case the C-MACs aren't in the backbone context - so can only flush the B-MAC (which belongs to the edge PE and doesn't have a problem). So need to flush the I-SID table instead, but leave the backbone unaffected. So add I-SID info into the MAC withdraw, so as soon as you reach an edge PE that has PBB knowledge and knows the affected I-SID then it'll flush. As for the "normal" MAC withdraw it is "flush everything in I-SID x, except what you learned from me". discussed M:1 model with many I-SIDs per VPLS. Issue is you want to constrain flooding per I-SID. So create per I-SID flooding trees. Actually done by constraining to the group B-MAC per I-SID. Still working this out and would welcome input. next steps - more details on flood containment and multicast handling Also need to add interworking between PBBN access networks and MPLS cores. This is covered well in Ali's draft but need input as to what models we should use if PBBN access is present. This is both PBBN on its own and PBBN to MPLS access. Also (of course) Want WG feedback. Rashal - you talk about I-SID bundling. Never talk about B-VLAN and B-VID. What is their role in this? Florin - there's documentation in Ali's draft. the PBB B-VID is a tunnel (multipoint) so if you have MPLS access and MPLS tunnels you don't need one. But with PBBN you do. Rashal - are you stripping it out and getting VPLS to do its work? Florin - you don't need it if you start MPLS at the edge. But in the interop draft there may be cases for using it as a service delimiter. Rashal - so you're stripping out the B-VLAN part? Florin - VPLS does the B-vID function. Ali - there is good overlap between this draft and mine, especially in talking about H-VPLS with MPLS access. Florin - the main difference is in the approach. we are approaching this from the VPLS PE. Ali - my draft describes all different scenarios. one is the interop between VPLS and PBB. It also covers H-VPLS with MPLS access. U-PE and N-PE. It explains how to use .1ah at the U-PE for MAC aggregation. That's exactly repeated in this draft. I'd request you remove it. if there's a shortcoming in mine then fix it. Then we can rename this draft as "MAC flushing mechanism for PBB in VPLS" Florin - we had this before with interop draft on QinQ vs VPLS RFC. I'd be glad to rename the draft if it just comes down to MAC withdraw. But we need to know what's needed from a solution perspective. if is just MAC withdraw then that's fine, but there may be more needed. I thought yours was more requirements and interop, and didn't look so much at what we needed from data plane, control plane, resiliency, OAM Ali - it's not just requirements. It also talks about interop scenarios, and what you need for each one (PW types, I-SID translation etc.) It covers all scenarios comprehensively. Florin - that's the problem. We ought to have requirements, framework, interop and solution. Ali - we're not talking about the whole L2VPN space, just specific interop scenarios. My draft talks data plane, if there's control plane interop needed we can put that in another draft. Florin - I came from a different perspective. There's lots of new stuff in this draft. Ali - What's new other than mac withdraw? Florin - The data plane is different. also MAC registration stuff for N:1 I-SID case. Also stuff on resiliency, OAM, multicast handling... Ali - yes, I saw one sentence there! Florin - you should read my draft like I read yours! Ali - sections which overlap should be removed. So when we talk about PWE per I-SID we need to put the new PWE issue to bed. Then no additional description will be needed. Florin - Let's meet and discuss in detail... Hamid - clarification question. 2 issues. First is how do we improve VPLS by using PBB? This draft addresses that. Second is interop. Florin - I tried to focus on what needed adding to VPLS PEs to handle PBB. But I didn't preclude a PBB access network. Part of this should apply with no problems to PBBN access Hamid - we need to keep in mind that these are two problems. Himanshu - have you covered the case with PBBN on one side and not on the other? Florin - I thought that was handled in Ali's draft. I'm focusing on VPLS PE. The next step is to discuss interop. Himanshu - we need to cover interop in all scenarios. .1ad, .1ah, etc. Ali - that's already covered in my draft. I cover all options - VPLS, H-VPLS, PBN, PBBN, etc. I cover cases such as PBN-VPLS interop to PBBN-VPLS. Himanshu - I was talking about case where access is different, but core is VPLS (as Ali has mentioned) Florin - PBBN is covered. I was refering to the case where the metro runs VPLS in the access in one domain and you're doing interop with a metro using PBBN. Ali - VPLS in core and access is H-VPLS. Do you have another name? Florin - it doesn't matter, it's not relevant. Ali - do you have something else in mind other than VPLS? You're not connecting two full meshes together? That scenario has been covered. Florin - need to cover the case where that interops with PBBN in the access. So there are different functionalities implemented in VPLS PE. Not sure if there is any special processing that needs to be done. It's a valid case, and I know of SPs that have that case. Shane - we're trying to see if Ali's draft has covered all cases. Ali - if any scenarios are not in my draft I want to cover them. but don't want to create a new draft for each new issue. Luca - what type of PWE is this using? Florin - we're using existing PW, and I think it works. Not getting problems. Luca - why is there a PBB TLV in this doc? Florin - this is for MAC withdraw. I mentioned I-SID identifier is I-SID context, not B-VID context in specific case where you have a topology change and need to "flush everybody but me". VPLS interop with PBB - Ali --------------------------- going to cover draft quickly, and give deltas with previous version. 1) MPLS access case with or without I-SID translation (I-SID translation is between admin domains). For either case we're using Luca's new PWE type. So doing the .1ah encaps at the U-PE. Gives you MAC scalability through the N-PE. If you aggregate the PWEs for a number of customers then broadcast/multicast domain is across all those customers, but if you don't then you have more PWEs. 2) PBBN access with VPLS core where PBBN and VPLS are the same domain - so PE connects to the BCB. 2 options - B-VID as delimiter or I-SID. Interface to PE will be B tagged, not I tagged. George - to clarify there is no service delimiter, the service delimiter is the I-SID and it is handled at the edge of the SP network. The service provider service is outside the interface from the BCB to the PE. So the interface is B tagged. Ali - you only get B-tag on the interface. if you look at .1ah the inter-core connectivity is B-tag. I-SID is only at the edge. So when it comes to the PE then the PE can use the B-VID as a service delimiter. The frames on that interface will have a B-VID in them. At the PE you can decide whether to do a VPLS full mesh based on the B-VID or on the I-SID. In the first case you have a full mesh of PWEs with B-VID as delimiter. In the second case the good thing is that the I-SID is unique across different interfaces. 3) BEB connected to PE. So interface is I-tagged, not B-tagged. So no B-VID, only an I-SID. In such cases the draft describes the possible services you can offer (port based, I-SID based and I-SID bundling) and what the requirements are for them. for all scenarios in this draft it talks about admin domains etc., whether you need I-SID translation, all the different services you can deliver to the end user (port based, VLAN based, I-SID based, VLAN bundling, I-SID bundling). Florin - in final case no B-VID right? You had I-TAG mode and I-SID bundling mode. I wanted to understand where the B-VID comes from. Does PE generate it? Ali - whenever the I-sID comes the PE adds a B-VID. In this case if you add a B-VID to an I-SID you just bundle the I-SID in the B-VID. B-VID is generated by the PE. if you want to do I-SID bundling then you want to consider the 3 component model in .1ah. I-SID into B-VID and B-VID into VPLS. Florin - did you consider bundling I-SIDs into VPLS without B-VID? Ali - my draft talks about inter-domain scenarios where a given PE gets connected to multiple PBBNs. If you need to do any I-SID translation then you need to do it using the B component functionality at that PE - no other way is possible. that's described in the draft. Florin - I have comments on admin domains. If the core/access are different domains (in this case), you also have a section discussing where they're the same domain. I don't understand how the PE can be outside that domain but in the core domain. Ali - this is the service domain. what it boils down to is whether you provision the I-SID by a single management entity or multiple entities. Florin - will send an email on that. The section can be removed from the topology B, type 3 interface. The delta from this draft to last is clarification, resulting from emails saying where it was unclear. Also defined some terminology. No major additions or deletions. Sections and scenarios are as before. I encourage people to send comments to list so we can all see it. if there are any comments or issues regarding it let's discuss it. it covers all scenarios comprehensively, and after another rev or two can decide WG status. Shane (chair hat off) - seems that you consider each access network as an island in and of itself (.1ah island, .1Q island etc.) have you considered cases where providers are migrating from e.g. QinQ to MACinMAc and/or MPLS? And in those cases you have multiple functions inside of e.g. the U-PE or multiple U-PEs attaching to an N-PE and demux becomes non-trivial. Ali - that was a requirement from one of the providers. So case is QinQ with VPLS and migrating to PBBN. So not going to change to PBBN overnight. will have a mix. so how does it work with a mix. covered that scenario. But the case with VPLS core, MPLS access, QinQ and PBBN has not been covered because am assuming it can be inferred from scenarios which have been covered. I can go through an exercise of ensuring it is covered from the other two scenarios. Shane - not concerned as much with mixing together where each island runs one set of protocols, but where those are co-located on the same U-PE or N-PE. It's like you're describing, but co-located e.g. on one N-PE. Ali - what's the requirement for having all on the same U-PE unless you want to interop at the far end? That can be covered. Will look at it to see if existing scenarios cover it. I think the functionality for each scenario covers the aggregate case. if not will add it. Florin - my understanding is that -01 says if I-SID is delimiter then use .ah PWE, but if B-VID is delimiter then use regular PWE. is that right? Ali - yes Florin - between the PEs you use a regular PWE for option 1? Now this would correspond to a single admin domain for one provider. In type 3 case what happens if on the PE for one VPLS you add an I-SID interface to another provider and all of a sudden for that VPLS you need to go to a specific I-SID to the third-party? So now I-SID is service delimiter. my question is when you start with B-VID then add I-SID do you stick with VLAN PWE or do you go to a .1ah PWE? Ali - type 1 has PWE on B-VID basis. Type 2 is I-SID. Type 2 can interop with type 3 as both I-SID. Type 1 can't. you can't aggregate and not aggregate at once. you have to decide. Florin - so if you start with B-TAG interface you can't add I-SID? Ali - on B-TAG interface you can do B-TAG or I-SID delimiter. SP decides upfront and sticks with it. otherwise change PWE. George - to do the transition you could have two VLANs - one I-TAG and one B-TAG and have a point where you bridge them to span the whole thing. But not a good state to run in for too long! Ali - transition would have service interruption. Florin - so we need to talk about it. Ali - rather than talking about all possible imaginary scenarios would rather hear from SPs that they have such reqs. if SPs have that need (to migrate from B-VID to I-SID) then need to hear if they can tolerate interruption, and if so then how much. George - not thought through, but think can do without disruption. Himanshu - just to clarify. for a given VPLS instance the PWE type is regular or .1ah? Ali - correct. Ali - whenever you use I-SID and want to have one service instance per I-SID you use a new PWE. Ali - I invite people to comment on the list, and depending on those we'll decide on next meet for WG draft. Himanshu - one more Q. You could multiplex I-SID on I-TAG PWE? or is it 1:1? Ali - if you want to multiplex then easiest way is to use a B-VID. B-VID then maps to a PWE. that's what a PBB B-component does. B-VID is basically an I-SID bundle. Himanshu - so you'd have B-MAC and B-VID in payload? Ali - yes. Wrapped up...