IETF 70: Layer-2 Virtual Private Network WG (l2vpn) Minutes TUESDAY, December 4, 2007, 1740-1840 ==================================== Chairs: Vach Kompella Shane Amante 1) Administrivia 2) WG Status and Update http://tools.ietf.org/wg/slides/l2vpn-0.ppt 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 comments: - draft-ietf-l2vpn-vpls-bridge-interop-02 - draft-ietf-l2vpn-oam-req-frmk-09 + Need to address Sec-DIR comments: - draft-ietf-l2vpn-vpls-mcast-reqts-05 - Submitted to Int-Area IPv6 Directorate for Review, due to no comments on v6ops or ipv6 mailing lists: + draft-ietf-l2vpn-arp-mediation-08 + draft-ietf-l2vpn-ipls-07.txt - No progress on MIB's, but have accepted the following as WG draft since last IETF: draft-ietf-l2vpn-vpls-mib-00 - Other drafts in progress: + draft-ietf-l2vpn-mcast-03: to be discussed today + draft-ietf-l2vpn-vpls-pim-snooping-01 + draft-qiu-serbest-l2vpn-vpls-mcast-ldp-01: Expired + draft-ietf-l2vpn-vpws-iw-oam-01 - Other submissions: + draft-stokes-l2vpn-cfm-vccv-oam-00 + draft-mohan-l2vpn-vpls-oam-00 + draft-stokes-vkompella-l2vpn-vpls-oam-01 + draft-raggarwa-l2vpn-p2mp-pw-00 + draft-kothari-l2vpn-auto-site-id-00 + draft-kompella-l2vpn-vpls-multihoming-00 + draft-balus-l2vpn-vpls-802.1ah-01 + draft-sajassi-l2vpn-vpls-pbb-interop-02 - WG Charter Update + Charter is out-of-date + Need to update completed items + New dates for items that remain to be completed, specifically OAM & MIB's + Discuss new work items and, if WG agrees, put them on the charter: - Multicast: have already undertaken this work, but need to put deliverables & dates against those items. - Scalability: preliminary discussions around scalability (& interop) of the data plane, (e.g.: PBB). Need to agree to what are the problem(s) being solved and potential solutions. - Other items are: Multi-homing/Service-Convergence and Inter-AS - If there are other items, please bring them up to the WG chairs or on the mailing list. + Have a draft version of the charter. MTownsley to review, provide comments and then we'll forward to the WG for modifications, comments and acceptance. 3) OAM for L2 VPN Networks Using CFM and VCCV Olen Stokes (ostokes@extremenetworks.com) http://tools.ietf.org/html/draft-stokes-cfm-vccv-oam-00 - Look at applying 802.1ag and VCCV to L2VPN networks - Look to see if SP's require additional OAM capabilities - Want to make sure to cover both full-mesh VPLS and H-VPLS networks, including access networks. - This draft doesn't define new protocols, instead it examines: + How to diagnose problems within/by VPLS forwarders? + Is a control channel needed, perhaps in Control Plane, to reply to a source in the case of failures? - Discussed RFC 4664 Reference Model as it relates to H-VPLS and placement of MP's (Maintenance Points) within that model - One key point is how to interface the point-to-point PW's in a H-VPLS network into the reference model? Authors gave interpretation of it and would like to ensure WG agrees with it. Questions: Ali Sajassi: Reference Model suggested here is model I suggested, and is same model referenced in CE bridge-interop draft. Model was presented in Nov 2004. It describes model to be used for spoke PW. Some of the assumptions made in this draft are wrong and need to be corrected. Olen: If we missed a place where it was documented, we'll go back and take a look at it. I expect that we'll sit down together and figure out the correct model. Ali: It took 3 years to get OAM requirements & framework draft out the door, now it's time to work on the solution. Don't want to go back and re-hash previous discussions, instead focus on OAM solutions now. Shane: One question on your statement. Are you referring to Section 3 of bridge-interop draft? Ali: Yes, as well as presentation that accompanied that draft in Nov 2004 on web site. In both cases of H-VPLS, spoke PW and Q-in-Q access networks, bridge module is used in forwarding the packet. Dinesh Mohan: In draft certain assertions were made with respect to CFM that were incorrect, for example, it's not possible to use CFM to check the MTU size, which is not correct, because there is a Data TLV allowed for that. Olen: Well, CFM is a very complicated protocol and we did our best to interpret it as correctly as possible. If there are corrections, we'll be happy to address them. Shane: Dinesh, could you send those points to the list so everyone could see what they are and the authors could respond to those? Dinesh: Sure. Some of them are in my solutions draft, which will be discussed next. Shane: OK, if you want to refer to them on the list, that would be helpful. Jeremy Brayley: Supportive of the idea of a bridge module in PW forwarder. Would like to see new reference model -- makes sense to have a MEP or MIP at the PW forwarder. Seems to me, based on RFC 4664, that it wouldn't be allowed. If it is allowed, reference model doesn't really matter, but the important thing that does matter is there is a use case for a MEP/MIP between PW's. 4) VPLS OAM - (slides - .pdf) Dinesh Mohan (mohand@nortel.com) http://tools.ietf.org/html/draft-mohan-l2vpn-vpls-oam-00 - Diagram of VPLS PE - VPLS OAM Scope: + Monitor end-2-end VPLS service across (Ethernet) UNI's + Monitor VPLS Emulated LAN, depends on position of Up/Down MEP's - H-VPLS OAM Overview - U-PE implements MEP - N-PE implements MIP and MEP - VPLS OAM Reqmt's & Conformance + Discovery: Multicast LBM used for on-demand; CCM's used for proactive discovery + Fault Detection: CCM's are used + Fault Verification: Unicast LBM's supported by Ethernet OAM; VPLS Fwd'er insertion point is at the emulated LAN, so VPLS doesn't see OAM frames any different than regular data traffic. + MTU Verification: unicast LBM's using Data or Test TLV's. Can also be used to specify different bit patterns as well. + Fault Localization: Ethernet OAM can be used to localize problem to a specific segement, depending on positioning of MEP's/MIP's + Perf. Monitoring, e.g.: Frame Loss Ratio, statistical sampling & other methods specified in Y.1731. Multi-point perf. monitoring is also being looked at in MEF. - Operational Steps + Monitor VPLS Service & LAN Emulation via Ethernet OAM + Does not impose n-squared issues unlike monitoring full-mesh PW's + When fault detected, use native OAM capabilities within segment, (e.g.: VCCV for MPLS/IP PW's) Questions: Jeremy Brayley: Can you clarify your reference to multicast Loopback from 802.1ag, since I am not aware of such a capability? Dinesh: Address validation is not done to verify it's a unicast message, therefore to permit backward compatibility between Y.1731 & .1ag, the .1ag-compliant node, today, will not issue a multicast Loopback, but if it does receive a multicast Loopback then it will respond back. Jeremy: It would be useful to clarify that. 5) OAM (Operation, Administration and Maintenance) for Virtual Private LAN Service (VPLS) Vach Kompella (vach.kompella@alcatel-lucent.com) http://tools.ietf.org/html/draft-stokes-vkompella-l2vpn-vpls-oam-01 - Vach presenting on behalf of Pranjal, who couldn't make it - Bringing back old draft from a while ago. New draft is more focused, given work that's taken place in VCCV and 802.1ag. - Looked to Olen's draft to identify what's missing and then use this draft to fill in a solution for those missing pieces. - Along with .1ag and VCCV, we have complete coverage of OAM for VPLS. - Pretty much in agreement with Ali & Dinesh on what reference model is; although some mistakes might have been made in the current draft, we'll fix those with comments from the list. - This draft trying to solve for: service discovery, verification, figuring out where faults are and detecting partial mesh failures. Hopefully, one of the results of this draft will also be recovering from partial mesh failures. Partial mesh is a case where a VPLS was supposed to be a full mesh, but a PW is down and it's no longer a full mesh. - VPLS OAM packet should be formulated just like Ethernet packet. - In previous draft, used Router Alert label, but there was a lot of comments that Router Alert wouldn't follow same data path as VPLS Ethernet frames, so this draft addresses that. - Need to ensure Control & Data Planes are consistent. - Important to send success/failure both via data plane and, when it fails, via control plane. - Two diagnostics: VPLS ping and VPLS traceroute. Both are on-demand. - A couple of issues we identified while writing this draft: + First issue: Need to encapsulate VPLS OAM packet as regular Ethernet packet, but: - PW-Associated Channel expects that VCCV packet has Label Stack, followed by Control Word and immediately followed by IPv4 or v6. However, in this case, PW-ACH would have Label Stack, CW, then Ethernet header and then IPv4/v6. Existing channel type for VCCV doesn't account for this. - Two solutions: 1) Define a new Ethernet Channel Type in PW-ACH and use existing VCCV Control Word for transporting VPLS OAM packets; 2) Consider a non-VCCV Control Channel, i.e.: first nibble of Control Word would be different. In speaking with George & others, this second option sounds like a bad idea, so we'll dump that if people agree the first is a good solution. + Second issue didn't show up in the past, because we didn't have MS-PW's - If we come up with new PW-ACH with new Channel Type, how does S-PE handle it? - S-PE sees VPLS OAM packet, it sees TTL expire, so it forwards it to the Control Plane, but knows it's not a VPLS PE so it throws the OAM packet away. In that case, ping won't work and traceroute will probably just show stars, similar to existing results in IP traceroute. Then, TTL is incremented at head-end and next node responds and things will look good, but you'll get strange behavior in the middle. - Proposed that S-PE will decrement TTL, but let OAM packet through even though it's not a VPLS PE. Ping will work and traceroute will work if it's going through, but traceroute will be a problem. Could just drop the packet or enhance the OAM message so the downstream node is aware of it. Questions: Kireeti Kompella: Why wouldn't ping work? Vach: Because have to look at TTL, decrement it and then forward ... Kireeti: ? Vach: It was an issue of what do you do when you encounter any OAM packet that you don't understand? Rahul Aggarwal: Are you incorporating TTL expiration approach for how you're doing OAM? Rahul: LSP-Ping identifies packets in the data path by TTL expiration. VCCV identifies packets in data path via: 1) TTL expiration; 2) Router Alert; and, 3) Assoc. Channel. Is your draft including TTL expiration for ping? Vach: No it's not. With SS-PW, that might work. VPLS in general case can be a H-VPLS, so TTL = 1 doesn't work, because you're trying to go from MTU-s on one side to MTU-s on another side. Rahul: Your spec should include TTL expiration approach and should mention drawbacks of that. One way to get around issues you mentioned is to know what is the cost of the segments you have beforehand, (if you have multiple segments). VCCV documents other drawbacks as well. One of benefits of that is you don't need PW-ACH approach. Ali: Think we may be trying to solve a problem that may not exist. We all agree that, for VPLS, we're going to be using 802.1ag and VCCV for PW's. And, next question is between combination of these two if there are any holes what is the solution to solve that? Vach: You should read Olen's draft, because that's what it discusses. Ali: Premise of this draft is based on wrong model, and if model is corrected then all these problems go away and 802.1ag has the coverage that can be used to pinpoint exactly what Ethernet component has failed and then VCCV can be used to further troubleshoot problem of PW's or LSP-ping for PSN problems. If you're talking about Inter-AS Option B for MS-PW, then that's MS-PW and should be taken care of by VCCV. Vach: Depends on whether you want to do piece-wise OAM or end-to-end OAM. Ali: It is a very nice, hierarchical approach that can be done end-to-end (AC-to-AC) and can be used to pinpoint problem on any node in between. Question is: with these tools, what are the holes that your draft is trying to fix? Vach: I believe that VPLS Forwarders are part of the service, so .1ag will not actually tell me whether I'm using the right labels, whether a particular PW is associated with a MAC address and things like that. Ali: .1ag tells you exactly what PE the forwarder is on that has a fault and then you can use fault verification and fault isolation mechanisms, depending on the fault. Vach: That is one way to do it, but I would prefer to sit at one end-point and get a response back. Ali: That's why we have ping and we have trace. Don't do it with a single tool. Need to re-visit what are the holes and bring those to the table. Vach: We did re-visit that when we went through the whole draft. Ali: Used wrong assumption when re-visiting the draft; need to use right assumptions. Dinesh: Agree with Ali, between .1ag and VCCV that this proposal does not bring in much value. In OAM reqmt's and framework, it established reqm't for fault detection. My read of draft is it's used after a fault has been detected, rather than used to detect a fault itself. Also, seems to rely on CFM for fault detection capabilities. Vach: Correct. Just as your draft says it uses .1ag and VCCV, because one tool is not good enough to address everything. Dinesh: Yes. But, already standards available like 802.1ag and MPLS OAM. If those are already sufficient, then why do we need to define new mechanisms? Ali: If there are holes, we would be happy to look at it. We are saying that if you use 802.1ag with VCCV, then that is sufficient. Vach: It may be sufficient for one set of providers, but not those we've talked with. Ali: Did you describe the right model to them? Vach: Absolutely. Dan O'Connor: I don't think we should have multiple solution drafts. Are you proposing an alternative solutions draft? Vach: We looked at using CFM and VCCV and we discovered some things that are not covered by the two of them. Dan: I wouldn't support any alternatives, because its Ethernet, so you have to start with that as a benchmark. Vach: Agree, but that's not the only part of this service, there are MPLS components and Ethernet components. 6) Multicast in VPLS Rahul Aggarwal (rahul@juniper.net) http://tools.ietf.org/html/draft-ietf-l2vpn-vpls-mcast-03 - Draft is mostly finished. Hope is to fix nits and take it to Last Call soon. - Main changes since last version are: + Spelling out Inter-AS procedures for Option A, B and C. + Spelling out segmented tree procedures for Option B. - Spells out some of the encoding details that were not precise enough for Tunnel ID's - Also, details procedures for Selective Trees. - Editorial Updates. No questions. 7) Point-to-Multipoint Pseudowire Signaling and Auto-Discovery in Layer 2 Virtual Private Networks Rahul Aggarwal (rahul@juniper.net) http://tools.ietf.org/html/draft-raggarwa-l2vpn-p2mp-pw-00 - Background: need for P2MP PW's presented in PWE3 WG yesterday with draft representing reqmt's by a number of SP's. This draft presents a solution for that problem. - P2MP PW is a unidirectional P2MP emulated service over a PSN. - Motivations: 1) deliver a Layer-2 multicast service, encoded as Layer-2 or IP, from one source to multiple receivers; 2) enable a VPWS to provide a Virtual Private P2MP unidirectional Service, (VPMS), which is not the same as VPLS that is multipoint-to-multipoint. - Layer-2 Multicast VPN identified by Sender-Sites, (send mcast traffic), and Receivers-Sites, (recv mcast traffic). Receiver Sites cannot send mcast traffic and Sender Sites cannot receive mcast traffic. Policies to enable this can be defined by BGP. - Auto-Discovery is used for receiver sites to discover sending sites; re-uses mechanisms already defined in draft-ietf-l2vpn-vpls-mcast and draft-ietf-l2vpn-signaling. - Signaling: root PE tells leaf PE's what is demultiplexor to be used. Allows same P2MP PSN tunnel to be used for multiple P2MP PW's. Demultiplexor is an Upstream Assigned Label. - Inter-AS & Multi-Segment P2MP's pretty much work the same way as segmented trees already defined in draft-ietf-l2vpn-vpls-mcast, so we can recycle stuff already defined in that existing draft. - Important thing to sort out is whether PWE3 or L2PVN should take this draft. No questions, due to lack of time. 8) Automatic Generation of Site IDs for Virtual Private LAN Service Bhupesh Kothari (bhupesh@juniper.net) http://tools.ietf.org/html/draft-kothari-l2vpn-auto-site-id-00 - Reqmt's on Site ID's in VPLS-BGP: + Site ID's in VPLS-BGP must be unique per VPLS domain, except for multi-homing. + Site ID's are used to index into Label Blocks, so must be in dense clusters. + Responsibility to keep Site ID's unique & in dense clusters is up to SP's. - Goal of draft is to eliminate need to provision Site ID's, each PE should generate its own Site ID's. Method needs to be backwards compatible and work Inter-AS. - Each PE keeps track of Site ID's already in use and claims unused ID when it needs one. Claim advertisement doesn't carry Label Block, so can't be used to set-up PW's. If there are collisions, then PE's run resolution algorithm and algorithm guarantees one PE will win. - With multi-homing, Site ID's still need to be assigned manually. No questions, due to lack of time. 9) TRILL Update Erik Nordmark (erik.nordmark@sun.com) http://tools.ietf.org/wg/trill/ - When TRILL was chartered, there was belief there may be overlap between VPLS and TRILL. AD's asked TRILL to check with L2VPN to see if there was any overlap, particularly in the area of when there are multiple attachment circuits to the LAN that are active at the same time. That's something TRILL has specified. - Text in TRILL drafts about interacting with Spanning Tree Protocol to make sure that we can forward frames over the network. - Would like L2VPN WG members to take a look at TRILL specs to make sure TRILL didn't miss anything. - Looking at going to WG Last Call on TRILL docs in about 1 month or so. No questions, due to lack of time. 10) Meeting Closes