Final Minutes of L2VPN WG Meeting @ IETF 63 (Paris)

[Shane Amante <[e-mail]>]

Below are the final L2VPN WG minutes from Paris, which only includes two 
clarifications that Bruce Davie forwarded to the list.  Again, thanks to 
Andrew Dolganow, Jaime Miles and Cary Wright for serving as scribes.

-shane & Vach


IETF 63: Layer 2 Virtual Private Network WG (l2vpn) Meeting Minutes
-----------------------------------------------------------------------

Wednesday, August 3, 1030-1230
==============================

Chairs: Vach Kompella <[e-mail]>
         Shane Amante <[e-mail]>

-----------------------------------------------------------------------
1) Agenda Update
-----------------------------------------------------------------------
   Two presentations cancelled:
     + Florin Balus' presentation cancelled, because discussion on MS-PW
     occurred the day before in PWE3.
     + Greg Weber's presentation on "Using RADIUS for PE-Based VPN
     Discovery" (draft-ietf-l2vpn-radius-pe-discovery-01.txt) cancelled,
     due to WG scheduling conflict.

-----------------------------------------------------------------------
2) WG Document Status (Vach)
-----------------------------------------------------------------------
   - Documents Status
     + draft-ietf-l2vpn-arp-mediation-02 (ARP Mediation): There are a
     few comments that are being addressed.  MPLS WG being asked to
     review code points and changes to LDP.
     + draft-ietf-ipls-02 (IPLS): There are a lot of edits so working
     group last call is being delayed.  Vach asked for more review from
     the working group.
     + draft-ietf-l2vpn-signalling-04 (L2VPN Signaling): Close to WG
     last call, however some issues raised in PWE3 may require some
     changes to the draft so WG will wait to see what happens in PWE3.

   - Charter Status
     + Good progress, or almost done with most items in charter.
     + OAM and MIBs are significant bodies of work that still need work.
     + Volunteers for work on MIB are requested.

   - ITU Liason Statement
     + 36 from ITU-T SG13 Y.ethoam needs to be reviewed.
     + Action is to read, evaluate and respond; asked for volunteers to
     see Vach or Shane afterwards to review and respond.

   - Loa Anderson made comment that VPLS BGP has progressed into the
     IANA for the code point allocation, and that they are ready to
     assign the code point.

-----------------------------------------------------------------------
3) Update: IP-Only LAN Service (IPLS)
    draft-ietf-l2vpn-ipls-02.txt
    Himanshu Shah
-----------------------------------------------------------------------
   - IPLS changes:
     + multicast mp2p PW type changes from IPLayer2Transport to Ethernet
     + All ARP and multicast frames are sent over multicast PW with
       Ethernet headers
     + A copy of ARP and link local multicast packets are sent to
       control plane for local CE discovery
     + addressed other comments from the list
   - IPLS simplified as a result
   - IPLS pending changes reviewed
     + Proposed IANA type and status code points to use.
     + Code points not yet in the draft
     + Will send email to MPLS WG to review code points.
   - Asked for a final call on IPLS draft

   - Show of hands indicated not too many people read a draft, Vach made
   a call for people to read a draft and have a discussion on the
   mailing list.

   Questions raised at the microphone:
   - Bernard Tuy: asked about support of IPv6 in this draft.
   - Himanshu: This was not supported in this version of the draft.
   - Bernard: Why is this not supported now?  It is strange to have this
     work being done without IPv6 supported now.
   - Himanshu: v6 is planned, but wanted to get IPv4 out first.
   - Vach: Asked Mark Townsley if we can wait on IPv6 or if we have to
     address it right away?
   - Mark: We should take it to the list.
   - Himanshu: emphasized again that the goal is to get IPv4 done right
     away, IPv6 later.
   - Janusz: Should not go for a protocol without IPv6 consideration, at
     least a section on v6 is required.
   - Andy Malice: asked for IPv6 supporters to offer text.
   - George Swallow: commented that lacking IPv6 in the document may
     cause the work to be rejected.
   - Mark: agreed that people who want IPv6 need to provide the text.

-----------------------------------------------------------------------
4) Update: ARP Mediation for IP Interworking of Layer 2 VPN
    draft-ietf-l2vpn-arp-mediation-02.txt
    Himanshu Shah
-----------------------------------------------------------------------
   - Final call on -01 version, good support on the list.
   - Major comments on: PPP AC procedures, some ID nits, IP TLV etc.
     Presented response to those comments.
   - Proposed needed IANA code points, (0x096B type, 0x00000029 status)
   - Conclusion:
     + send email to MPLS WG for code points assignment review
     + propose to submit draft for IESG review
     + can do another final call for changes

   Vach: Let's do another final call, comments restricted to what's in
   the draft (specifically changes from last final call).  2 week last
   call will start right after this IETF.

   No Questions/Discussion raised at the microphone.

-----------------------------------------------------------------------
5) Provisioning Models and Endpoint Identifiers in L2VPN Signaling
    draft-ietf-l2vpn-signaling-04.txt
    Bruce Davie
-----------------------------------------------------------------------
   - Presented changes from last version:
     + Fixed distributed VPLS case
     + Addressed comments on the list (editorial, clarifications, bug
       fixes)
     + Clarified use of PE address in VSI identifier
     + Added IANA considerations section
   - All comments since Minneapolis were addressed, propose last call
     for this draft.

   Questions/Discussion raised at the microphone:
   - Mustapha Aissaoui: It will be hard to maintain this one central
     document and maybe it should only be informational.  We have
     separate documents for applications, is this to become guidance RFC?
   - Bruce: Would like this to not just be informational but standards
     track, because it shows how to do interoperability between BGP and
     LDP.

   - Hamid: If intent of the draft is to be more like a solution draft
     with discovery, then the title should be corrected.
   - Bruce: Would be happy to change title.
   - Hamid: Is this consistent with existing documentation?
   - Bruce: This document is consistent with other work.  Context of a
     signalling message (VPLS spec) does not have enough info for BGP
     auto-discovery, this document flushes out the details.

   - Vach: Do we need distributed case described here?
   - Bruce: The distributed case is described in draft-ietf-l2vpn-vpls-
     bgp-05.txt, so it seems prudent to keep it in this draft as well,
     lest anyone claim that the lack of distributed VPLS support is a
     drawback of using LDP.

   - Ted Seely: There is a lot of work going on to go across ASes, but
     there is little work being done to address how service providers
     honor SLAs across these services.  There is nothing on the edge to
     actually say that it is working.  Ted says that maybe the IETF
     should start to think how to address this.
   - Bruce: Not sure which working group is best to address this
     question.  Suggested maybe we need a new Ops specific working group
     area?

   - Bruce: Are we ready to do last call on this document?
   - Vach took a poll of the room of who is ready for last call.  Many
     hands went up.  Room seemed to support the idea to make final
     changes (related to IANA code points) and then go to last call.
   - Mark: Do we need IANA code points to be allocated before the final
     call?
   - Bruce: My intent was not to get the code points, simply to clarify
     in the document that we need to obtain code points for AGI type and
     AII type in the FEC 129 TLV. The actual allocation can be done
     later (by IANA or PWE3, whoever actually has control over those
     fields).

-----------------------------------------------------------------------
6) LDP-based Autodiscovery for L2 Services
    draft-stein-ldp-auto-00.txt
    Yaakov Stein
-----------------------------------------------------------------------
   - Presentation talked about Access Network Architecture and important
     characteristics of that network that need to be taken into account.
   - Scale, simplicity of devices, combined devices (multiservice
     nodes), simple tree, limited BW, limited computational power, 1000s
     of nodes, no BGP may not be IGP, LDP for access LSP setup.
   - Manual configuration to join such a network would be difficult.
   - Basic assumptions in the draft: network element and links are
     relatively static, hence network discovery not a burden, services
     are dynamic, manual provisioning is difficult, want auto-discovery.
     When BGP available in core network it could be used, when LDP is
     only thing available then it should be used for auto-discovery.
   - New LDP message: JOIN Message, like label request, but only sent to
     nodes that are part of the VPLS instance. Vset members nodes after
     receiving the message start PW setup procedures to connect the new
     node.

   Questions/Discussion raised at the microphone:
   - Ali Sajassi: main point appears to be avoiding BGP in DSLAM's.
     BruceD's presentation shows how to do this without BGP, so this
     works.  It's already taken care of by current framework.
   - YaakovS: Not negating other things may work, this draft proposes a
     simple way of doing that.
   - Ali: Specific autodiscovery case, very narrow, already taken care
     by current framework, (general enough).
   - YaakovS: Thinks it doesn't scale.

   - Kireeti: Like to see the work. Questions scalability, if the access
     network is simple, building LDP mesh would be challenging, how
     about reflectors?
   - YaakovS: Referenced how others have said that LDP is not that
     chatty.
   - Kireeti: we may still need something like route reflectors.
   - YaakovS: had not worked on this, but interested to look into idea
     like LDP reflectors.
   - Kireeti: went on to ask about using BGP if it only carries one
     NLRI, for auto-discovery, and how complicated that really is?
   - YaakovS: had not seen studies that really help resolve whether BGP
     or LDP is the best.
   - Kireeti: If all you implement is "light" BGP, the BGP requirements
     may be small, BGP would be fine in this case.

   - Vach: "Managing DSLAMS are configuration nightmare", not a feedback
     he has heard.
   - YaakovS: Depends on DSL architecture.
   - Vach: Still disagrees. Re: "Hierarchical model hides CEs" statement,
     that model not being as scalable as the one shown, is a wrong
     assumption. Thinks that people know how to do redundancy on RADIUS
     servers so a central server approach is not an issue.
   - YaakovS: RADIUS is one idea, but not the only one asked for.

   - Sasha: Who is talking to who over targeted LDP?
   - YaakovS: There are sessions within an access network and then
     between S-PEs.

   - Yakov Rekhter: thinks BGP processor overhead is not an issue and
     that the majority of boxes can run BGP.
   - Yaakov Stein: he would like to see a study to compare BGP to LDP.
   - Pedro: Algorithmically BGP is not as complex as stated.

-----------------------------------------------------------------------
7) Requirements for Multicast Support in Virtual Private LAN Services
    draft-kamite-l2vpn-vpls-mcast-reqts-00.txt
    Yuji Kamite
-----------------------------------------------------------------------
   - Scalability issues for multicast, need requirement documentation as
     a basis, the draft clarifies issues, describes requirements, guides
     multicast VPLS solution design.
   - Illustrates multicast challenges in VPLS. Issue A: Replication to
     non-member sites; Issue B: Replication of PWs on shared physical
     paths.
   - Presented summary of the requirements in the draft from multiple
     angles (General, Customer, Service Provider).
   - Major open questions: requirement levels, which PE-CE protocols are
     consulted, etc.
   - Next steps: enhance document with more feedback, propose as a WG
     document.

   Questions/Discussion raised at the microphone:
   - Rahul: Thinks this is useful work and should move forward.  Also,
     thinks the document needs to require both solutions A and B.
   - Yuji: Does not want to limit scope and thinks, ideally, both
     solutions A and B should be addressed.

   - Bernard Tuy: Need to ensure IPv6 support and multicast
     auto-discovery and reporting of membership.
   - Yuji: Haven't given this any consideration yet. Feedback requested
     from a mailing list

   - Shane: polled room to see who had read the draft?  A significant #
     of hands raised.  Asked room: should this become a WG draft?  Fair
     # of hands raised.  Will take same question to list re: becoming WG
     draft.

-----------------------------------------------------------------------
8) Supporting IP Multicast over VPLS
    draft-serbest-l2vpn-vpls-mcast-03.txt
    Venu Hemige
-----------------------------------------------------------------------
   - Solving issue A from previous presentation, (multicast traffic
     flooded to all sites, with or without receivers).
   - Draft addresses building of replication state in PEs for IGMP and
     PIM only, PEs on cust-facing port must perform IGMP/PIM snooping,
     PE on PW port may learn multicast state using either IGMP/PIM
     snooping (no additional work, good up to medium scale deployments
     but does not scale above well, hence LDP). Why LDP?  Already used
     to setup PW, reliable, will scale well.
   - Overview of LDP mechanism and special considerations as per draft
     were presented.
   - Next steps:
     + Comments please
     + Talk about combining with other draft (Rahul's)

   Questions/Discussion raised at the microphone:
   - Ali: Can you alleviate with PIM refresh-reduction. Have you been
     in touch with the work done there?
   - Rahul: PIM WG is in very early stages, but we have a solution now
     so we should use it.
   - George: This draft needs review by MPLS WG
   - Janusz: Recommend to split doc into 2 parts: IGMP/PIM in one, LDP
     in another
   - Venu: That discussion currently in progress

-----------------------------------------------------------------------
9) Multicast in VPLS
    - draft-raggarwa-l2vpn-vpls-mcast-01.txt
    Propagation of VPLS IP Multicast Group Membership Information
    - draft-raggarwa-l2vpn-vpls-mcast-ctrl-00.txt
    Rahul Aggarwal
    + NOTE: Rahul made one presentation, which covered both drafts.
-----------------------------------------------------------------------
   - Showed multiple VPLS multicast proposals, restated again the VPLS
     multicast limitations focus on optimizing state and not BW.
   - Optimizing BW and state are conflicting goals.
   - Tools to do that:
     + VPLS Auto-Discovery (use existing Auto-Discovery methods)
     + Allow elimination of flooding (PE-CE IGMP/PIM snooping,
       PE-PE reliable exchange of multicast control messages can be
       done with either BGP or LDP).
   - Presented overview of proposed solution in the drafts, overview
     of functional blocks for VPLS multicast, showed how various drafts
     address those functional blocks.
   - Conclusion: lots of interest, let's align drafts to follow
     functional decomposition, move drafts that fit (functional
     decomposition) already into WG docs, move others after restructuring
     to WG drafts.

   Questions/Discussion raised at the microphone:
   - Ali: Breaking down drafts to follow functional decomposition is a
     good idea.  If I have bridges, and I send multicast, how does
     Ethernet OAM get treated?
   - Rahul: Haven't thought of that.
   - Shane (CH): Take it to the list.

   - Ali: Mechanism for shared tree, PE routers need to keep state
     need clarifications.
   - Rahul: There are procedures/clarifications missing in the current
     specs.

   - Ali: How close will we come to LAN Emulation?  We need to be clear
     in the documents what the trade offs are for each document.
   - Rahul: Happy to include clarification, please provide specific
     text.

   - Ben Agrovitz: Glad to see we acknowledge tradoffs of the
     architecture.  Challenge is finding the middle ground for tree
     sharing procedures.
   - Rahul: There is already a mechism in the draft. If anything is
     missing, happy to add it.

   - Shane: who has read the drafts?  Good response.
   - Shane: should these both be WG drafts?  Some responses.  Will take
     same questions to the list.

-----------------------------------------------------------------------
10) L2VPN OAM Requirements and Framework
     draft-ietf-l2vpn-oam-req-frmk-03.txt
     Dinesh Mohan
-----------------------------------------------------------------------
   - Presented update on the draft, (overview of framework and
     requirements)
   - Status:
     + OAM framework adopted for other related work
     + New draft submitted
       - Section 7 added
       - IPLS OAM is FFS - input welcomed
       - VPWS OAM references draft-delord-pwe3-oam-application-01.txt,
         (goal is to avoid duplication).
   - Next steps:
     + Add VPWS OAM Reqs
     + Continue refining requirements on PW OAM
     + Other editorial updates.
     + Still work in progress, no intention for last call at this time.

   No Questions/Discussion raised at the microphone.

-----------------------------------------------------------------------
11) OAM Procedures for VPWS Interworking
     draft-aissaoui-l2vpn-vpws-iw-oam-03.txt
     Mustapha Aissaoui
-----------------------------------------------------------------------
   - No slides, Mustapha gave verbal update.
   - Planning revision by the end of August.
   - BFD for reverse concatenated path
   - Editorial changes
   - Had a good show of hands on this as a WG doc, but no response on
     the list.

   No Questions/Discussion raised at the microphone.

-----------------------------------------------------------------------
12) VPLS Interoperability with CE Bridges
     draft-sajassi-l2vpn-vpls-bridge-interop-01.txt
     Ali Sajassi
-----------------------------------------------------------------------
   - Updates from last draft
     + First presented in IETF61
     + Comments/discussions on a mailing list
     + Almost all discussions on clarification
   - Main objectives:
     + Identity interop issues between VPLS and 802.1D bridges.
   - Presented recap of interop issues:
     + CE Bridge Protocol handling
     + Customer network topology changes
     + PE redundancy
     + MAC address scaling
     + Partial-mesh PWs
     + Muticast
     + Interop with 802.1ad Provider Bridges
   - Next steps:
     + What's the consensus on the draft?
     + What areas need further clarification?

   Questions/Discussion raised at the microphone:
   - Vach: Some issues seem not to be bridge interop issues, (MAC
     address scalability). Should take them out of here. Some may be too
     hard to handle: perfect LAN emulation.  Need more refinement what's
     required & what's nice-to-have, (like protocol handling).
   - Ali: Regarding perfect LAN emulation, some things will just not
     work.
   - Vach: For problems already solved by some other organizations, we
     don't need to solve them here. Would be nice to know those problems
     already solved.
   - Ali: This is not the intent, important to point out the
     functionality required at the PE for interoperability.  Will update
     the draft to address these comments.

   - Himanshu: Draft brings up good points. How will the draft address
     each of these issues?
   - Ali: Agreed. Need to point to solutions that exist, come up with
     solutions for things that are missing.
   - Himanshu: Would you like to address these issues with solutions in
     this draft?
   - Ali: Would like to address some, more extensive things may need a
     separate draft.
   - Dinesh: Suggests we consider an applicability statement to address
     these issues.

Meeting Adjourned @ 1230