IETF 65: Layer 2 Virtual Private Network WG (l2vpn) Meeting Minutes Thursday, March 23, 2006, 1300-1500 =================================== I) Administrivia - Agenda Review - Minutes - Blue Sheets II) WG Document Status (Shane Amante) + The following 5 I-D's were On-Hold, prior to IETF 65, pending resolution of Security Area concerns. + Cleared DISCUSS: - draft-ietf-l2vpn-vpls-ldp-08 - draft-ietf-l2tpext-l2vpn-07 + draft-ietf-l2vpn-vpls-bgp-06 - Needs paragraph included from RFC 4364, Section 13.1, to clear Security DISCUSS. Intent is to align L2VPN & L3VPN security considerations. + draft-ietf-l2vpn-signaling-07 - Needs a paragraph to say that for manually instantiated tunnels refer to RFC4023; for auto-discovered tunnels over IP, it is desirable to have a more automated method to secure the traffic -- however, that is out-of-scope for this document and will be looked at in the future. + draft-ietf-l2vpn-requirements-06 - Does not adequately address Section 4.5.1, User Data Security, of RFC 3809. l2vpn-reqmt's should address this in the same manner as Section 6.9.1, (Support for Securing Customer Flows [over the Internet]), of RFC 4031 to make L3VPN & L2VPN consistent. - Need to reconcile Section 6.10.4, Security Considerations for Multi-Provider L2VPN's, from RFC4031 with l2vpn-reqmt's. l2vpn-reqmt's has multi-provider requirements, but less specific security language than RFC4031. + In RFC-Editor Queue: - draft-ietf-l2vpn-l2-framework-05 + Passed WG LC, waiting for ARP-MED: - draft-ietf-l2vpn-ipls-05 + Need to issue WG LC, (after IETF 65): - draft-ietf-l2vpn-vpws-iw-oam-00 + Need to make WG doc, (after IETF 65): - draft-sajassi-l2vpn-vpls-bridge-interop-02 + Needs some more (minor) work, before WG LC: - draft-ietf-l2vpn-arp-mediation-04 - Himanshu promised to make minor updates shortly after IETF 65, and perform brief WG LC on changes. + In Progress: - draft-ietf-l2vpn-oam-req-frmk-04 - draft-ietf-l2vpn-vpls-mcast-reqts-00 - draft-ietf-l2vpn-vpls-mcast-00 - draft-qiu-serbest-l2vpn-vpls-mcast-ldp-00 - draft-praba-l2vpn-vpls-mcast-emul-01 - draft-hemige-serbest-l2vpn-vpls-pim-snooping-00 - draft-weillian-l2vpn-mib-00.txt + Unknown or New I-D's: - draft-kompella-l2vpn-l2vpn-01, (well, not so new ...) - draft-ietf-l2vpn-radius-pe-discovery-02 - draft-sajassi-l2vpn-vpls-multicast-congruency-00 III) Brief Update on VPLS/VPWS MIB Work (Shane Amante) + Asked Tom Nadeau to be lead-editor of MIB work + Tom is editing a document with authors from ZTE + Cisco + Alcatel, who have provided contributions to the MIB. + Goal is two-fold: - publish first revision to list in May timeframe for WG review. - Wrap up MIB work by December. IV) Update on Multicast/VPLS work (Shane Amante) + Multicast State Distribution between VPLS PE routers Using LDP - draft-qiu-serbest-l2vpn-vpls-mcast-ldp-01.txt - Changes made in 01: * LDP Multicast Capability TLV - Now have bits for PIM-SM, PIM-DM, and IGMP/MLD * Removed MAC address field from Hello Sub TLV * Wording changes + PIM Snooping over VPLS - draft-hemige-serbest-l2vpn-vpls-pim-snooping-00.txt - Next Steps: * (re-)Add the PIM proxy approach to the next revision of the draft after this IETF meeting * Ask for WG call to move it forward to support the LDP multicast state distribution draft V) Consistent Titles of VPLS-LDP & VPLS-BGP I-D's (Vach Kompella) + Titles for two VPLS drafts were inconsistent. IESG would like them to be the same. + Will change them to say: - Virtual Private LAN Services Using LDP, and - Virtual Private LAN Services Using BGP VI) Update to l2vpn-signaling draft to support Auto-Discovery draft-ietf-l2vpn-signaling-07 Luca Martini + Luca discussed an issue with l2vpn-signaling & Auto-Discovery. Currently, l2vpn-signaling proposes using RD:IP_Addr for NLRI, RD is then put into AGI field of PW LDP signaling. FEC 129 requires AGI to match in both directions of PW to bring up PW. + RD is just an RD, not an Identifier. + Proposed solutions: - Use RD and make it match. - Use RT insead in AGI. - Use BGP opaque Extended Community. * Use BGP Ext Community to signal VPLS-ID == AGI. * Allows the current RD/RT definition to be as defined in l3vpn. Q&A at the Mic: * Ali Sajassi - How to be sure VPLS-ID is same across two AS'es. If AS1 uses number 10, other uses 20, and then if these AS want to connect how will it work? * Luca - Use NAT or translate. * Vach Kompella - We had discussed we were going to use RD as such, RT as such and add third field. * Luca - Yes. [missed the rest of the response] * Ali - In the intra AS RD and RT is the same, does everyone agree? * Luca - No. * Ali - I would like to understand more applications. * Luca - Refer to l3vpn working group. VII) Requirements for Multicast Support in Virtual Private LAN Services draft-ietf-l2vpn-vpls-mcast-reqts-01 Yuji Kamite + Status of draft. + Update on major changes. + Update on changes in flooding technique. + Update on OAM. + Other updates. + Like to ask for WG Last Call. VIII) Congruency for VPLS Multicast and Unicast Paths draft-sajassi-l2vpn-vpls-multicast-congruency-00 Ali Sajassi + Discussed requirements for this feature. + Discussed current multicast proposals. 1. Ingress replication over PW's guarantees congruency between unicast and multicast but is inefficient. 2. Building multicast tree is incongruent. + Discussed Bridging issues when non-congurency occurs. + Discussed Proposal for Congruency - To levereage constructs for mVPN and mcast VPLS. - Leverage mLDP, RSVP-TE, PIM. + Diagram to show building of Unicast tunnel along the Mcast tunnel. + Discussed associated cost. + Conclusion: Limited applications where both congruency and efficiency is required. Only small modifications to mLDP or PIM for passing ECMP identifier. Q&A at the Mic: * Yakov Rekhter - There is no fate sharing, congruency is not the problem. We should step back and ask if fate sharing is requirement. * Ali - We should define fate sharing. If issues listed here are not clear, we can rediscuss. * Yakov - 4 Issues discussed are clear, but are they a requirement? Is in-order delivery a requirement, can you guarantee in-order delivery since one path may be going through diff. queue than another path. * Ali - That's an implementation issue. Link failure is a failure scenario and in-order is not guaranteed, but that is not steady state. * Ali - [ missed this ] * Vach Kompella - You are assuming that a segment of root to leaf is the same cost in unicast as multicast. * Ali - The only way to get that is, if you have asymmetric cost in the network. * Vach - No, it depends on how the tree is created. * Ali - Let's look at that, if you can send that to the mailing list. * Vach - You said "SHALL NOT". We should change it to should not, as shall not sounds like "MUST NOT". * Vach - Why not turn off learning on multicast path, and have them enabled for unicast path only. Use replication of unicast only. Forget optimization for now. * Ali - We can discuss this. * Luca - You have two methods of forwarding traffic. I don't believe you can achieve fate-sharing. I think this is not worse than what you have in the network. * Ali - The idea is to provide multi-point service as good as today, not better. In current bridges, if there is a link failure, and it opens another link, there will be no loop. If unicast and multicast is being sent there is possibility of looping. * Luca - Why wont link down be detected? * Ali - Now we are talking about using OAM etc. etc. * Luca - If link is down, you will get some kind of detection, OSPF or something. * Ali - If you are going to allow a few seconds of transient loop, talk to providers. * Kireet Kompella - No problem with boiler plate; however, have problem with requirements and solutions offered. We have to nail down the problem, which is fate-sharing. The way to get it to work is not the way you are approaching. When multicast tree is built the metrics are different. * Ali - RSVP is fine, how bout mLDP? * Kireeti - The XC for multicast label is not same as for unicast label. What you are trying to do is not going to work. * Ali - Remember same degree as current unicast and multicast bridges. The obligation is to detect link down detection. * Kireeti - What you are saying is that bridges are making an approximation and VPLS makes a weaker approximation, so why not take a step back and look at the requirements? * Ali - We are trying to do this withougt impacting present bridges. * Kireeti - It would be better to break into two docs, one with requirements and one with solutions. * ? - Last IETF, also brought this up. If you can loosen the requirement and take care of only IP, then we might have a better solution. * Ali - We already have a WG document which refers to inclusive tree and selective tree. * Yakov - Concerned that we're not addressing real issue, which is fate- sharing. * Shane Amante - How many think congruity is an issue that we need to work on? Few hands raised; asked by WG audience to ask about fate-sharing. * Shane - How many think fate-sharing is a problem and we need a new document for it. More hands raised than previous question. * Vach - Why don't you cleanup the section of your draft and make sure the problem statement is well documented about interoperability of VPLS with bridges. In that doc we can go over why VPLS is not a perfect solution for a bridge. In VPLS we said that we are not going to have a perfect emulation of a bridge. If there is consensus in the WG that this is an important problem and we can move forward with it. * Ali - I have an issue, that in the past two years this is documented. If WG does not have a bridge background, they have routing background, how do we move it forward? * Vach - Then this is not the right forum if that is the case. Then you can document the problem here and have it fixed somewhere else. * Yakov - Need to document the problem in the VPLS multicast requirements document. IX) L2VPN OAM Requirements and Framework draft-ietf-l2vpn-oam-req-frmk-04 Dinesh Mohan + Draft-05 Updates + Next steps: - All comments addressed. - Request to proceed to last call. - Maybe split the document into two docs, requirement and framework. - Would like to see a decision on that taken. Q&A at the Mic: * Shane - How many believe the OAM reqmt's and framework should be split into separate documents and proceeded separately? Two hands. * Shane - How many believe the OAM reqmt's and framework should not be split into separate documents and continue with LC "as-is"? Many hands. * Shane - OK, will continue with WG Last Call of doc "as-is". X) New Proposed L2VPN Milestones Shane Amante + Existing milestones are woefully out-of-date and multiple people have asked us to update them to reflect something in the future, not 2 years in the past. + Two major items left on the charter: OAM & MIB's. + Tom Nadeau to work on MIB's with help from others, hopefully wrap up by EOY2006. + OAM reqmt's and framework theoretically done, just need solutions; looking to wrap-up OAM solutions by Mar 2006. + Any comments or suggestions on these milestones? (No.) + Will post them to the list for comments, discussion.