2.3.12 Layer 3 Virtual Private Networks (l3vpn)

NOTE: This charter is a snapshot of the 61st IETF Meeting in Washington, DC USA. It may now be out-of-date.

Last Modified: 2004-11-01

Chair(s):

Rick Wilder <rick@rhwilder.net>
Ross Callon <rcallon@juniper.net>
Ronald Bonica <rbonica@juniper.net>

Internet Area Director(s):

Thomas Narten <narten@us.ibm.com>
Margaret Wasserman <margaret@thingmagic.com>

Internet Area Advisor:

Thomas Narten <narten@us.ibm.com>

Technical Advisor(s):

Alex Zinin <zinin@psg.com>

Mailing Lists:

General Discussion: l3vpn@ietf.org
To Subscribe: https://www1.ietf.org/mailman/listinfo/l3vpn
Archive: http://www.ietf.org/mail-archive/web/l3vpn/index.html

Description of Working Group:

Alex Zinin is the routing advisor.

This working group is responsible for defining and specifying a
limited number of solutions for supporting provider-provisioned
Layer-3 (routed) Virtual Private Networks (L3VPNs).

The WG is responsible for standardization of the following solutions:
    1. BGP/MPLS IP VPNs (based on RFC 2547)
    2. IP VPNs using Virtual Routers
    3. CE-based VPNs using IPsec

The following VPN deployment scenarios will be considered by the WG:

    1. Internet-wide: VPN sites attached to arbitrary points in
      the Internet

    2. Single service provider (SP)/single AS: VPN sites attached to
      the network of a single provider within the scope of a single
      AS

    3. Single SP/multiple AS'es: VPN sites attached to the network
      of a single provider consisting of multiple AS'es

    4. Cooperating SPs: VPN sites attached to networks of different
      providers that cooperate with each other to provide VPN service

The WG will address deployment of the following features in a VPN
environment:

    1. IP Multicast
    2. IPv6

As part of this effort the WG will work on the following tasks
(additional work items will require rechartering):

    1. Requirements and framework for Layer 3 VPNs
    2. Solution documents for each approach listed above (including
      applicability statements)
    3. MIB definitions for each approach
    4. Security mechanisms for each approach

As a general rule, the WG will not create new protocols, but will
provide functional requirements for extensions of the existing
protocols that will be discussed in the protocol-specific WGs. L3VPN
WG will review proposed protocol extensions for L3VPNs before they are
recommended to appropriate protocol-specific WGs.

As stated above, the WG will define an IPv6 over BGP / MPLS VPN
solution.  This will include a forwarding plane component and a
control plane component.  In the forwarding plane, IPv6 datagrams will
be encapsulated within an MPLS header.  If any aspect of IPv6
forwarding over MPLS is as yet undefined, the L3VPN WG will defer to
the MPLS and appropriate IPv6 WGs.  On the control plane, BGP
extensions may also need to be defined. In this respect, the L3VPN WG
will defer to the IDR and appropriate IPv6 WGs.

QoS support is excluded from the charter at this time.  It may be
considered for inclusion in an updated charter at a later time. Future
work items may also include OAM support.

Goals and Milestones:

Done  Submit L3 VPN Requirements Document to IESG for publication as Info
Done  Submit Generic Requirements Document to IESG for publication as Info
Done  Submit L3 VPN Framework Document to IESG for publication as Info
Done  Submit VPN Security Analysis to IESG for publication as Info (draft-fang-ppvpn-security-framework-00)
Done  Submit BGP/MPLS VPNs specification and AS to IESG for publication as PS (draft-ietf-ppvpn-rfc2547bis-03, draft-ietf-ppvpn-as2547-01)
Done  Submit CE-based specification and AS to IESG for publication as PS (draft-ietf-ppvpn-ce-based-03, draft-declercq-ppvpn-ce-based-sol-00, draft-declercq-ppvpn-ce-based-as-01)
Done  Submit Virtual Router specification and AS to IESG for publication as PS (draft-ietf-ppvpn-vpn-vr-03, draft-ietf-ppvpn-as-vr-01)
Done  Submit BGP as an Auto-Discovery Mechanism for publication as PS (draft-ietf-ppvpn-bgpvpn-auto-05.txt)
Done  Submit specification of using GRE for PE-PE encapsulation in BGP/MPLS VPNs to IESG for publication as PS (draft-ietf-ppvpn-gre-ip-2547-02)
Aug 04  Submit VPN MIB Textual Conventions to IESG for publication as PS (draft-ietf-ppvpn-tc-mib-02)
Done  Submit MPLS/BGP VPN MIB to IESG for publication as PS (draft-ietf-ppvpn-mpls-vpn-mib-05)
Aug 04  Submit VR MIB to IESG for publication as PS (draft-ietf-ppvpn-vr-mib-04)
Aug 04  Submit specification of using IPSEC for PE-PE encapsulation in BGP/MPLS VPNs to IESG for publication as PS (draft-ietf-ppvpn-ipsec-2547-03)
Aug 04  Submit specification of OSPF as the PE/CE Protocol in BGP/MPLS VPNs for publication (draft-ietf-l3vpn-ospf-2547-xx.txt)
Dec 04  Submit specification of CE Route Authentication to IESG for publication as PS (draft-ietf-ppvpn-l3vpn-auth-03)
Dec 04  Submit specification of IPv6 over BGP/MPLS VPNs for publication
Dec 04  Submit specification of IPv4 multicast over BGP/MPLS VPNs for publication

Internet-Drafts:

  • draft-ietf-l3vpn-requirements-02.txt
  • draft-ietf-l3vpn-framework-00.txt
  • draft-ietf-l3vpn-ce-based-02.txt
  • draft-ietf-l3vpn-bgp-ipv6-03.txt
  • draft-ietf-l3vpn-mpls-vpn-mib-05.txt
  • draft-ietf-l3vpn-rfc2547bis-03.txt
  • draft-ietf-l3vpn-ipsec-2547-03.txt
  • draft-ietf-l3vpn-ospf-2547-02.txt
  • draft-ietf-l3vpn-gre-ip-2547-03.txt
  • draft-ietf-l3vpn-bgpvpn-auto-04.txt
  • draft-ietf-l3vpn-vpn-vr-02.txt
  • draft-ietf-l3vpn-vr-mib-02.txt
  • draft-ietf-l3vpn-tc-mib-04.txt
  • draft-ietf-l3vpn-as2547-07.txt
  • draft-ietf-l3vpn-as-vr-01.txt
  • draft-ietf-l3vpn-mgt-fwk-03.txt
  • draft-ietf-l3vpn-security-framework-02.txt
  • draft-declercq-l3vpn-ce-based-as-00.txt
  • draft-ietf-l3vpn-ppvpn-terminology-04.txt
  • draft-ietf-l3vpn-rt-constrain-01.txt

    Request For Comments:

    RFCStatusTitle
    RFC3809 I Generic Requirements for Provider Provisioned Virtual Private Networks

    Current Meeting Report

    L3VPN meeting minutes IETF-61 L3VPN meeting minutes IETF-61
    Mon 8 Nov 2004

    ===================

    Thanks to Mark Duffy for minutes.

    Agenda

          Agenda bashing and scribe discovery.
          Working group document status
          Multicast Requirements (Thomas Morin / Elodie Hemon)
                <draft-morin-l3vpn-ppvpn-mcast-reqts-00.txt>
          Multicast Approach (Eric Rosen)
                <draft-rosen-vpn-mcast-07.txt>
          Multicast Approach (Rahul Aggarwal)
                <draft-raggarwa-l3vpn-mvpn-vpls-mcast-01.txt>
          Multicast Approach (Seisho Yasukawa)
                <draft-yasukawa-l3vpn-p2mp-mcast-00.txt> 

    Working Group Document Status (Ross Callon)

    Ross went through the status of various working group documents. Note that we have had several approved by the IESG since the last IETF, and have multiple additional documents that have passed working group last call and are currently being reviewed by the IESG and/or being updated in response to IESG comments.

    Generic requirements - has been published as rfc3808 

    L3 Framework - in rfc editors queue for 18 mos, waiting normative ref on service reqts (wrt which we have good news) 

    L3 Service requirements - has been approved by the IESG and is now in rfc editor queue. This is good both in its own right, and also because it frees up the L3 Framework to be published.

    Security framework - almost done.  1 or 2 issues remain.

    BGP/MPLS VPN Spec and Applicability Statement - these have been approved by iesg, and are therefore now in the rfc editor's queue.

    Virtual Router Architecture and associated Applicability Statement - these are still under IESG review.

    CE / IPsec Architecture and associated Applicability Statement - these are still under IESG review.

    Terminology draft - Has been approved by iesg, in rfc editor's queue 

    Thomas Narten:  Texts need to make it more clear that some of these docs are frameworks etc. not standards.

    Framework for l3vpn oam - This has just passed working group last call and been sent to iesg

    Textual conventions - Ditto (has just been sent to iesg) 

    MPLS / BGP MIB - This has passed wg last call and been submitted to the IESG.

    Virtual Router MIB - This is waiting for an update by the document authors.

    BGP auto discovery - Has passed working group call and been submitted to iesg.

    ospf as pe/ce protocol - Has passed working group last call in both L3VPN and OSPF working groups, and been sent to iesg

    bgp/mpls for IPv6 vpn - The co-authors will issue an updated version which will contain one clarification note about the fact that this document does not cover interworking between IPv4 sites and IPv6 sites (+ editorial clean-up). It will then be ready for working group last call.  

    PE-PE IPsec for 2547 - in working group last call, an update is needed to respond to comments received. 

    PE-PE GRE/IP for 2547 - Has been submitted to iesg. 

    CE-CE Member Verification - draft has timed out; the chairs have prodded authors. 

    Constrained VPN Route Distribution - Has passed working group last call and been submitted to iesg.  

    Eric Rosen:  2547bis is waiting in the RFC editor queue for BGP Extended Communities to be published, which in turn is waiting for the base BGP spec.  

    Question from the working group chairs:  Who here is interested in IS-IS as CE-PE protocol for 2547?  There was no response.  

    --------------- 

    Requirements for multicast in Provider Provisioned IP VPNs

    (Elodie Hemon, France Telecom)  draft-morin-l3vpn-ppvpn-mcast-reqts-00

    Many solutions have been proposed for multicast over L3VPNs. No multicast requirements document has been written yet.  Operator feedback may help in developing and chosing between multicast solutions. 

    The requirements are intended to be solution-agnostic, and will serve as a guideline for solution drafts.

    There is a tradeoff between use of Bandwidth vs state in routers

    Need:
      scalability, tunability, traffic engineering,
      versatility (vis-a-vis tunneling modes),
      inter-AS, inter-provider support
      monitor/troubleshoot capabilities
      robustness and infrastructure security 

    Open questions:
      Extranet support?
      Fragmentation issues?  MTU management.
      Control mechanisms
      Need use cases
      Carrier's carrier 

    Next steps:
      Integrate received feedback
      Want more feedback! 

    Questions: 

    (???): Tunnel mode agnostic:  is it v4/v6 agnostic? 

    (Chen Yin Lee): Is it layer agnostic too :-) ?  Some of this may apply to L2 also. 

    (John Ryan?, Cisco): this is useful work.  Solutions should say which requirements are met. 

    (???) - What are the important applications?  A: We don't care what the content is.  Q: But from providers' POV, what is the application, what are the bandwidth reqts?

    (Jamie Miles, L3 Communications): Multicast is very important!  We *Need* inter-provider; including all 3 2547 inter-provider approaches.

    (???, Cisco): Requirements should be application-agnostic.

    (???, Cisco): Should Internet multicast as a transit service be included?  Fragmentation should be avoided completely.  In IPv6 mcast should default to 1280 MTU; this is a good practice for v4 too.

    (Luyuan Fang): This is good, should continue this effort.  This effort should focus on VPN, not Internet multicast.  Doesn't see many customers for Internet multicast.

    (Alex Zinin):  The security requirements section is empty!  <Something> about long list of tunnelling protocols.

    Ross: show of hands to interested to make wg doc: many in favor, none/few opposed.

    ------------------

    Multicast in MPLS/BGP IP VPNs

    (Eric Rosen, Cisco)  draft-rosen-vpn-mcast-07

     Mcast for 2547:
     New to wg charter, but the work has been ongoing since 1998
     Many proposals now, all based on same basic architecture
     There is significant (but not massive) deployment
     There are multiple vendors with deployed multicast over L3VPNs
     (but "less than 3"  :-)

    The new proposals extend, generalize, improve scalability.

    How to proceed:
      Break arch into a few pieces and look at them separately
      Focus on  producing standard, not battle between exisiting implementations. 

    Contentious issues: 
     Mcast distribution trees in SP backbone
        Not much Internet mcast but fair amount of enterprise mcast
     Scaling issues. There is a tradeoff between:
        state in P routers
        packets carried more than once over the same link
        packets sent to PEs that have no receivers
     Single vs multi provider
     Traffic engineering
     PE-PE PIM adjacencies in PE's PIM C-Instance
       "Just as bad as the Virtual Router approach!"
       PIM hellos overhead
       PIM join/prune messages overhead
       Transparency to existing enterprise multicast structure. 

    MDT in SP: P-State Scaling

    Base proposal uses hierarchical aggregation
      All groups from one VPN share a tree
      Requires state in P routers
      ... 

    Further scaling needs further aggregation
      by hierarchy?  seems elegant but no proposal.
      by some sort of TE?  figure out how some VPNs can share a tree.
      other ways?

    Traffic load scaling
      Unaggregated MDTs are better at scaling traffic load (reduce multiple transmissions per link, packets sent to uninterested PEs)

    What's with all the aggregation, de-agregation, reaggregation?
      Are we thrashing?  Reaching the limits of the technology?  ...

    Proposal for demux using mpls encap
      Requires enhancement to mpls arch: context label, upstream label distribution
      Need to worry about IP-based encaps as well. 

    Do default MDTs provide enough aggregation?  Not enough to support unlimited growth. Need more aggregation. 

    Scaling conclusion:
      One size doesn't fit all.
      The most scalable schemes may be too expensive in traffic loading. 

    Technology to create the MDT? 

    PIM-based solutions:
      PIM-SM - extremely complicated.  Source trees.
      PIM-SSM - much simpler.  Needs bgp-based source discovery
      BIDIR - best P-state scaling for intra-AS. 

    Explicitly routed MDTs (p2mp rsvp-te)
      Might be useful in some environments

     Unicast tunnels with replication at ingress
      Optimizes P-state, poor for traffic load 

    Doesn't think we can throw any of these approaches out! 

    Scaling PE-PE interaction in PIM C-instance
      Some optimizations that can be made ...
      Should bgp be used to distribute mcast routes across the backbone?
        tempting but... 

    -----------------
    Multicast in BGP/MPLS VPNs and VPLS
    (Rahul Aggarwal, Juniper)  draft-raggarwa-l3vpn-mvpn-vpls-mcast-01

    Components of 2547 mcast:
      control plane.  PE-CE; PE-PE
      data plane forwarding

    Issues raised at last ietf:
      PE control plane state
      PE control plane processing load
      P state

    Comparison of costs of 2547 unicast vs multicast
      why multicast doesn't scale as well
      ...
     
    Design objective
      Optimize bandwidth
        Packet traverses a given link only once
        Deliver mcast packets only to interested PEs
        Deliver customer mcast traffic along optimal paths (support different algorithms to compute the trees)
      Optimize state:
        Amount of state and processing to maintain it should not exceed those for unicast.

    Solution
      Existing solutions are insufficient
      This is a work in progress
      This solution tries to be reusable across L3 and L2 (VPLS) VPN
        But this presentation is only re l3vpn.

      Use BGP to do PIM neighbor maintenance
        Discover MVPN membership via BGP
        Reliable delivery of C-Join/Prune 

      Allow multiple VPNs to share a single SP MDT ("Aggregate Data Trees")
         Set up via PIM or P2MP MPLS TE LSPs, or etc.
         Requires an inner label to demux a particular vpn
         State in SP network does not grow proportionate to # of vpns.
      Ingress Replication - has its place.

    Aims to meet the requirements and have scaling properties similar to 2547 unicast.

    ------------------- 

    BGP/MPLS IP Multicast VPNs
    (Seisho Yasukawa, NTT)  draft-yasukawa-l3vpn-p2mp-mcast-00

    Motivations:
     Qos, reliable mcast, adequate operation and mgmt
     Focus on L3
     Scalable arch
       avoid PIM adjacency maintenance
       avoid suboptimal IP packet distribution
     Flexible operation

    Basic model:
     Adopt BGP/MPLS network model (CE peers with PE, use BGP for membership discovery)
     Extend bgp for exchange of mcast routing information
     Proxy-Source/RP model:  all PEs act as proxy-source/RP
     P2MP TE based MDT interconnects PEs

    BGP
     Use MDT-SAFI to discover PEs of same vpn
     ...

    Characteristics
      PIM-SM, PIM-SSM supported with same model
      Multiple topologies of MDT
      Multi-AS operation
      ...

    Open issues
      Applicability of PIM-DM and PIM-BIDIR
      Optimize default/data p2mp tree operation
      ...
     
    Next steps
      Resolve open issue
      Need wg input
        Is p2mp te mpls applicable to MVPN?
      Cooperate with other solution teams to develop a SINGLE solution. 

    -------------------

    Questions on all 3 approach presentations:

    (???, Cisco): Q for Rahul: We should try to make PIM more efficient. ...  Source replication seems to just be moving complexity from core to PEs.  PIM join suppression improves scalability.

    (??? Japan Telecom): ...(minute taker didn't record comment)

    (Ali Sajassi, Cisco): re data tree and aggregating it.  As # of sites goes up, chances of PE receiving packets not interested in goes up.  Would like to see a description of this congruency mapping in the draft.  Will customer's tree be moved from one aggregate to another?  Also, issue re VPLS - treatment of customer data vs customer bridge protocol.

    (Phil Zeckert???):  Need metrics to compare the different costs we are trading off.  Suggestion: average bandwidth per tree: if over a particular level, then perhaps give it its own tree.  Are we over-engineering now, especially given the rollout rate?

    (Yakov Rehkter): Re the last comment: It served us well in 2547 to engineer for a large scale!  And anyway it will take years to roll out whatever we do now. We should worry only about L3 traffic here. Aggregation: avoid artificial boundaries about what can be aggregated. 

    (Eric Rosen): Yes, keep L2 and L3 separate.
      Re aggregation toolkit:  Easier for equipment vendor, but just passes the buck to the SP to decide what to do.
      Re Yasukawa proposal:  is this just PIM refresh reduction?  Making PE a RP brings a lot of complications with it.  Also a problem if enterprise has its own PIM infrastructure.  <one more point>

    (Yakov): The Yasukawa approach is not just PIM refresh reduction; each PE is a separate PIM domain which is very different than the Aggarwal and Rosen approaches.  Could extend this scheme to not create MDT until there is data traffic.

    (???, cisco):  For Yasukawa-san:  question about putting Joins into bgp?  Since Join/Prune are modeled as SAFIs, how will route reflectors handle them?  Wants to see more in the draft on this.

    (??? cisco): Question for Rahul ...(minute taker did not record question)

    (???):  Communications between multicast people and mpls people has not been that great.  Will talk mode at mboned BOF this afternoon.

    The authors of the three proposals agreed to try to work together offline. The meeting was ajourned.

     

    Slides

    Agenda
    Status of L3 PPVPN Working Group Documents
    BGP/MPLS IP Multicast VPNs
    Requirements for multicast in PP L3 VPNs