Last Modified: 2004-06-15
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.
| 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) | |
| Aug 04 | 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-rosen-vpns-ospf-bgp-mpls-06.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 |
| RFC | Status | Title |
|---|---|---|
| RFC3809 | I | Generic Requirements for Provider Provisioned Virtual Private Networks |
|
l3vpn working group meeting minutes
August 5, 2004 IETF 60, San Diego Agenda: General - Agenda Bashing & Scribe Discovery (chairs) - Charter Update (Chairs) - Review of WG Document Status (chairs) Multicast Approaches - draft-rosen-vpn-multicast-07.txt (Eric Rosen) - draft-raggarwa-l3vpn-2547-mvpn-00.txt (Rahul Aggarwal) - draft-raggarwa-bgp-nexthop-rewrite-00.txt (Rahul Aggarwal) Multicast MIB - draft-svaidya-mcast-vpn-mib-00.txt (Susheela Vaidya) IPv6 - draft-ietf-l3vpn-bgp-ipv6-03.txt (Francois Le Faucher) - draft-defeng-l3vpn-ipv4-ipv6-hybrid-00.txt (Li Defeng) Agenda Bashing & Scribe Discovery (chairs) Thanks to Mark Duffy of Quarry Technologies for taking minutes. The last agenda item has been postponed to a future IETF because Li Defeng was unable to obtain a visa to enter the US. Charter Update (chairs) A new working group charter has been approved. In particular the new charter adds the following items (which are heavily involved in this meetings agenda): l3vpn support for multicast l3vpn support for IPv6 Review of WG Document Status (chairs) - l3 vpn framework - no change, in rfc editor's queue waiting on 2 references (one of which has published) - l3 service reqts - recent updated based on iesg comments and resubmitted to iesg. - security framework - ditto. One issue has come back from iesg again. - generic reqts for ppvpns - this has been published as RFC 3809. - bgp/mpls ip vpns - is being updated based on iesg comments - VR arch and AS - in iesg review. Intended status changing to informational - CE/ipsec arch and AS - ditto - AS Guidelines - less important now that ASs are written. But keep alive till ASs are all done. - Terminology draft - awaiting iesg review - Framework for l3vpn OAM - almost ready for wg last call - Textual conventions - ready for wg last call. Intention is to last call it at the same time as the framework for OAM. - mpls/bgp MIB - passed wg lc and submitted to iesg - vr MIB - needs a few minor edits then ready for wglc - bgp as auto discovery protocol - submitted to iesg - ospf as pe/ce - ditto - bgp/mpls for ipv6 - this is a working group document. We have a presentation on it in todays meeting. - pe-pe ipsec for 2547 - stable - pe-pe GRE or IP for 2547 - stable - ce-to-ce member verification - work is needed to merge approaches. - constrained vpn route distribution - now a wg doc, stable Multicast Approaches Multicast in MPLS/BGP IP VPNs draft-rosen-vpn-multicast-07.txt (Eric Rosen) Multicast has finally been added to wg charter! The document draft-rosen-vpn-multicast is 4 years old, and is the basis for existing deployments and proposals. It is a de facto standard and should be made a wg document. Formerly unsolved problems: - General inter-provider solution One SP might not know address of other SP's PE, or might not have a route to it. In inter-provider, the BGP NH will be a border router not a PE and that is not where the PIM adjacency belongs. Proposed solution: From draft-nalawade-idr-mdt-safi: MVPN PE distributes route for itself in MDT-SAFI family, and connector attribute on vpn-ipv4 routes to associate the MDT-SAFI address with them. - Non-congruent multicast topology From draft-wijnands-pim-proxy: If transmitter addr is not routable in SP network specify its bgp NH address in Join message. - Support pim-ssm PIM-SSM removes need for a rendezvous point, and scopes dest addresses per source. Since there is no RP, we need another way to auto discover MDT tree roots. Solution: MDT per VPN is not optimal (in terms of traffic distribution). Therefore let the service provider select the tradeoff. MDT per user mcast group is effectively unbounded (in terms of state information required). If user multicast groups are aggregated into MDT per VPN, some traffic goes where it is not needed. It's an aggregation vs optimization tradeoff (ie, state versus traffic). - Which pim variants should be required? Using a shared tree requires less state but scales worse as traffic increases. Best method for producing shared tres is PIM-BIDIR. PIM-SM can create shared tress but it needs all packets to be unicasted to the tree root. For source trees: PIM-SM could be used but several difficulties. PIM-SSM avoids these and should be preferred to do source trees. Eric thinks there is actually a lot of agreement (between proposed approaches) and this can be a wg document. Base Spec. for Multicast in BGP/MPLS VPNs draft-raggarwa-l3vpn-2547-mvpn-00.txt (Rahul Aggarwal) Motivation: Document minimal set of procedures for interoperable MVPNs. Document procedures used across multiple vendors. The procedures here are based on ..-rosen-06 (which vary somewhat from the procedures in -07). Replication vs state efficiency tradeoff replic efficiency suggests: no unnecessary replication state efficiency suggests - replicate packets at ingress PE Balance: PIM-SM must be supported in SP core. Use of other mcast routing is optional, hence not part of the mandatory set in this I-D. PIM-SM allows *one* MDT per VPN in SP core, rooted at RP Implementations should provide 2 knobs: ... C-Join/Prune/Assert Nbr address issue - 2 approaches proposed, need to pick one. Inter-AS: 2547 option A is supported. And option C (requires some extensions in bgp-free core) 2547 option B not supported since BGP NH is rewritten Inter-AS same provider: SP can share RPs between ASs, MSDP not required. MD address coordination not required. Inter-AS different providers: ... Differences from rosen-07 This one requires PIM-SM in SP core, Rosen requires PIM-SSM. More detail... This one documents a minimal set of procedures. Inter-AS option B not supported in draft-raggarwa (is covered by next draft) Discovery for PIM-SSM. 2 mechanisms. Why not 1? If PIM-SSM is optional the discovery method should be too. BGP free core - for MVPN, the savings of bgp-free are small and unimportant in the overall picture Some fundamental issues that exist in rosen-7 *and* in draft-raggarwa: PIM nbrs per PE = VPNs per PE * avg sites per VPN = 100K in some typical VPNs Periodic PIM msg exchanges with all PIM nbrs = 3300 PIM Hello/sec State in SP core - proportional to ... = 1,000,000 PIM-SSM trees, or = 10,000 PIM-SM The scaling properties of BGP/MPLS MVPNs are much worse than for unicast. Therefore we should go forward with a minimal set of features today, to meet SP demand, then work on better scaling Rahul proposed that his draft be a wg document. Preserving BGP Next-Hops draft-raggarwa-bgp-nexthop-rewrite-00.txt (Rahul Aggarwal) Rahul's Base MVPN solution doesn't support 2547 inter-AS option B Solution: Original BGP NH is carried as another BGP attribute. This is preferable to connector attribute because ... Discussion of the draft-rosen and draft-raggarwa (John Miley? Cisco): This seems to go against the widespread community goal of moving to SSM (Tom Pusateri?, Juniper): Based on scaling, PIM-SM makes sense here. Yakov Rehkter: Don't assume mcast wg will tell the world what protocol to use everywhere. (???, Cisco): The mcast wg has the expertise. Disagrees that goal should be to find the lowest common denominator between multiple vendors. Rahul: Data MDTs is a fine concept, but the solution requires too much state in SP core, and discovery mechanism. Eric Rosen: There is disagreement on approach. Our job as wg is not just to document how to interop with existing implementations; it is to develop a standard that covers all bases. So which does the wg want to do? Liming Wei (One of the original designers of PIM): Views SSM as subset of SM. Doesn't think that SSM is a good fit for this problem. (???, Cisco): would like to see validation from SPs of what the scaling numbers (goals) really are. Need to look to to solve the whole problem, not dead end by solving only part of it at first. (???, Cisco): Questions the scaling goals presented by Rahul. Yakov: Unicast 2547 has no vpn state in core; routing adjacencies per PE is mainly driven by # of CEs. But for MVPN it is not this way at all! This proposal is perhaps fundamentally broken. (???, Cisco): How about using CE-CE tunnels instead to support mcast VPNs. Agrees with Yakov about fundamentally departing from 2547 unicast model. ... Multicast MIB draft-svaidya-mcast-vpn-mib-00.txt (Susheela Vaidya) Based on the rosen draft but also addresses aggarwal. Configure and monitor Works closely with the unicast 2547 mib. Use with interface mib and existing mcast mibs 4 parts: generic info, config, protocol info, notifications Generic: # of MVRFs, # of itfcs for each, en/disable notifs, last config or oper change. Config: enable mcast in a VRF, MDT default groups, data groups, etc. Dynamic mapping between mcast stream and MDT group. Protocol info: mVRFs to MDT tunnel mapping, Join TLVs sent/received, BGP adverts of MDT groups received by device Notifications: 1 defined so far Ross: does the mib cover rosen or aggarwal draft? Susheela: both. (???, cisco): Wants to hear from wg chairs about the wg direction on multicast. Rahul: How can we progress the MIB before we figure out what to do with the solutions? Susheela: It covers both and anyway is flexible to expand. (???): Should look for the MIB to cover the superset of both implementations Susheela: It already does. Most of the info in the MIB is generic. Rick Wilder: call for show of hands to be wg doc (confirm later on list): many in favor, few or none opposed. IPv6 draft-ietf-l3vpn-bgp-ipv6-03.txt (Francois Le Faucher) (Presented by Jeremy DeClercq) Also a 4 year old doc! In this case this is already a working group document. The approach is based on 2547bis technology, extended to support IPv6. Customer sites and CEs are IPv6; SP bbone is v4 or v6. PEs speak bgp/tcp/ ipv4 or v6 Out of scope: interworking between v4 and v6 sites hybrid v4, v6 bbone BGP NH encoding: changed since -02. For v6 bbone NH is global v6 addr or global v6 addr + v6 link-local addr. It's a WG doc. On hold waiting for 2547bis Time for WG last call? And review by IDR? Pedro Marques: Process question: Format of NH was changed without public discussion. Why (given that this is a working group document, changes should require discussion on the mailing list)? Jeremy: let's discuss on list. Could change back. Changed because there was an issue. Ross: Wary of advancing on this without seeing if Li Defeng draft impacts on this. (particularly since Li was unable to attend only due to US government visa issue). Jeremy: Doesn't think it impacts. But let's confirm on mailing list. Ross: Agreed. Also made appeal for Service Provider comments. BGP-MPLS VPN extension for IPv4/IPv6 Hybrid Network draft-defeng-l3vpn-ipv4-ipv6-hybrid-00.txt (Li Defeng) This was not presented because Li did not get a visa to enter the US. |