Last Modified: 2005-02-24
| 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) | |
| Done | 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) | |
| Done | 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 |
|
IETF 62 - L3 VPN March 7 at 13:00 CST Chairs Ron Bonica <rbonica@juniper.net> Ross Callon <rcallon@juniper.net> Rick Wilder <rick@rhwilder.net> Ross Callon - Document Status Review Generic Requirements have been published as RFC 3809. L3 framework is waiting on a normative references on and therefore should be published soon. L3 Requirements is about to be published as RFC. L3 VPN requirements draft is going to be published soon as RFC4031. It's currently in the RFC Editor's 48 hours authors stage. Security Framework has been approved and is in the RFC editor's queue. BGP-MPLS L3 VPN's is in the RFC editor's queue. IANA considerations related to this draft are currently being worked out. VR and CE/IPSec architecture documents are all under IESG consideration. Draft-ietf-l3vpn-bgp-ipv6-05.txt has been forwarded to IESG with request for publication. AS Guidelines are "done" Terminology is also about to be published as an RFC. The MIBs need a little more work. -The Framework for L3VPN O&M is being updated based on comments received during the IESG review. -Textual Conventions is done -MPLS / BGP MIB is being updated based on comments received during IESG and MIB Doctor review. Virtual Router MIB timed out but has been recently updated. There is an intellectual property issue. This needs guidance from the working group. Multicast is one of the things where we are doing current work. The Requirements Draft has just been accepted as a WG document. There are also other individual drafts. (see discussions later in this same working group meeting). Other WG documents OSPF needs to be updated to respond to IESG comments. PE-PE IPSec for 2547 needs updates based on last call comments. PE-PE GRE is under discussion with the IESG. BGP Autodiscovery has been sent to the IESG --- Thomas Morin - Multicast Requirements draft ietf-l3vpn-ppvpn-mcast Context : First draft was presented in Washington, now a L3 VPN WG document. Integration of comments from new contributors. This added 6 pages. Many areas of the document are now quite stable. Noteworthy changes are Security, QOS, Internet Multicast, RP engineering. Internet Multicast is currently only mentioned as a possible requirement, so if the group has strong feelings about this, the group should speak up. Fragmentation issues - special care is needed here for multicast. Recently, added text about supporting multicast in a "Carrier's Carrier". The service providers side requirements have evolved. - control mechanisms - security - tunneling requirements - need to cleanly separate the control plane and the forwarding plane - TE & OAM A terminology session has also been added. A new term, Multicast Distribution Tunnels, or MD tunnels, has been added. What's next ? There is a need for data about the types of applications, orders of magnitude However, need to consider not just current deployments but also future deployments. Also, support for the Carrier's Carrier model needs to be added. Open questions include the scope of the document. Should the scope be reduced ? Should IPv6 be added ? He requests review and comments from the WG. He also wants to do an ISP survey. -- Multicast VPN Architecture Eric Rosen (erosen@cisco.com) and Rahul Aggarwal (rahul@juniper.net) Multicast Support for RFC 2547 VPNs has 2 components control plane - exchange vpn multicast routing information data plane This is very similar to the separation for 2547 unicast. Design Objectives include Optimize Bandwidth & Optimize State - A given multicast packet should traverse a given link at most once - Deliver multicast traffic only to those PE's that have receiver that want the traffic. Optimizing State and Bandwidth are conflicting goals. MVPN AutoDiscovery uses BGP - this eliminates PIM Hello's Control traffic does not have to use the tunnels used by the multicast data. In the data plane - ingress replication to egress - a separate tree for every C-(S,G) going one way increases state and decreases bandwidth, going the other way does the reverse. Can do aggregate state, with a separate state for "Inclusive mapping" or "Selective Mapping" - a separate tree per set of C-(S,G) The tree is built using PIM-SM BiDir, SSM, whatever. The spec does not limit to a specific tree building protocol. <audience member> - ask questions now, or at the end ? Ross - at the end Eric Rosen In order to converge the document, tried to see how the proposals differ. - What sort of multicast service can be provided - methods of implementing multicast service - multicast routing information propagation One size does not fit all, so tried to clarify multicast service and routing information exchange. Provider-Network Multicast Service Interface - PMSI - service is scoped to one MVPN - three types MI-PMSI - multipoint inclusive, all to all YU-PMSI - unidirectional S-PMSI - selective PMSI's are instantiated by tunnels. Types of these PIM-created trees Point to MultiPoint LSP's Unicast tunnels PMMSI may require sets of tunnels (e.g., SSM) Single tunnel may instantiate more than one PMSI - the encapsulation is a function of the tunnel, not the service Old terminology - Default MDT -> MI-PMSI, instantiated by PIM shared tree or a set of PIM Source Trees Data MDT = S-PMSI New terminology helps to separate out the service and data issues. What sort of tunnels ? MPLS vs GRE vs MPLS in GRE vs ... Source initiated or receiver initiated creation of tunnels TE : Source Multicast : Receiver Options for creating and destroying the tunnels As part of discovery As a separate phase after discovery As needed (this complicates the protocol options) How do we ensure interoperability - force a common tunnel choice ? The discovery phase - make sure that everyone gets all of the multicast information that they require. What PMSI's are going to be used ? Will MVPN routing be propagated by unicast or multicast What sort of tunnels ? What information is needed to create and destroy them. What encapsulation is to be used ? What amount of aggregation. For routing information, they considered only PIM and BGP. For PIM, C-Join / Prune messages are sent by either multicast or unicast (PE to PE). Note : Unicast is different from MI-PMSI over unicast tunnels. With PIM, you can minimize overhead by eliminating periodic messages - refresh reduction (being worked on in PIM group) - hello suppression (provided by BGP in L3VPN) This creates a lightweight adjacency which is, however, not interoperable with full adjacencies. Can always find the RPF, even if there isn't always a route back to the source. Control Messages : Multicast or Unicast Allows asserts, join suppression, standard "PIM on a LAN" Unicast : No join suppression, no asserts OR, you can do it with BGP BGP MVPN Routing information update (new SAFI) <RD, C-S, C-G, ORIGINATOR PE, Upstream PE - PE2, RT> I-PMSI Instantiation - Can be uni or multi directional Current spec limits trees to PIM-SM, SSM, BiDir, RSVP-TE P2MP LSP's Trees can be source based or shared trees. Source tree's are set up by the PE Shared trees are set up by a RP **** except that they say with **** SSM Each PE uses BGP to advertise whether or not it is capable of MPLS ingress replication, and also downstream MPLS Label Joins are sent upstream using BGP or Unicast PIM [as there is no full mesh tunnel. Wonder if they have thought about MSDP ?] Aggregation allows one P-Multicast Tree to be shared across _multiple_VPNs'. Requires a MPLS label to demultiplex a particular VPN - BGP to the RR. A PE decides to set up an aggregated tree : S-PMSI instantiation Set up a separate tree for a set of <C-S, C-G>s that may belong to different VPN's This also allows a datagram (UDP) based protocol that may already be deployed. For inter-AS - two models Tunnel Span's multiple AS's OR Each AS can have its own tunneling mechanism The draft talks about deployment models. - Anycast RP based on (*,G) advertisements When you unicast PIM messages, how do you know which VPN they belong to ? Authors request to make it a wg doc. Also, they invite the authors of draft-yasukawa to join for the next draft --------- Seisho Yasukawa (NTT) BGP/MPLS IP Multicast Basic ideas 1. Extend BGP to exchange multicast routing information 2. Adopt a proxy RP 3. Use P2MP TE LSP to forward multicast traffic over provider core There mechanism is applicable to PIM SM and SSM They want to merge the drafts into a single MVPN solution Question : Marshall Eubanks : How do you plan to do anycast RP ? Currently it is done with MSPD A : Using a new SAFI in BGP Question : Yiqun Cai : How do does the customer do BiDir ? A. BiDir is not supported. Ross : It is my impression that in both authors have expressed a desire to merge the two documents. What is the consensus of the working group ? Should these be merged ? Rahul Aggarwal : Just to make it clear, our draft tried to incorporate as much as possible of the other draft already. Yakov Rekhter : So we don't have to wait for the next IETF. Ross: we have limited time here for discussion. Shall we ask the authors to merge proposals? Shall we accept it now as wg doc once it is merged? Or wait until we see it? Many more hands for accepting it now. A: Let's get the merged doc on the mailing list and proceed from there. ------ Michael Behringer draft-behringer-mpls-vpn-auth-05.txt RFC2547 environment If a PE misconfiguration a CE onto a tunnel, this could be a security problem, and there is no easy way to detect it. There is routing authentication Proposal - Do away with PE to PE authentication, do authentication across the entire tunnel. There is another draft, the Bonica draft. There was a push to merge them, but he thinks now that this does not make too much sense. Draft: Beh Bon CE Does not need to participate No Yes Allows route verification by site No Yes Work with route reflectors YES YES Requires routing PE-CE YES (Yes, or a new functionality to do this) Q (McDysan): as an SP, he likes this. Doesn't want to rely on customers to detect problems. Q (..., cisco): What prevents using same md5 key for more than 1 CE? A: nothing; that's tough luck --- Ron Bonica CE Based Membership verification We are worried about honest mistakes from the Service provider Status Quo : L3 VPN relies on the proper configuration of the Service provider network. Breaches are generally silent. The proposed mechanism alerts the customer when the VPN has been breached. A VPN site sends a token to the PE, which sends it to every other site. This does not protect against malicious behavior on the part of the SSP, intended to protect against accidental exposure. This draft and the Behringer draft actually solve rather different problems. One partially prevents configuration errors, the other alerts the customer when it happens. [could you concatenate your token with a MPLS label or some other unique ID] Ross : Who thinks that these are a bad idea ? Rick Wilder : I think that each author should make it clearer what authentication problem it is solving, and also have pointers to the other draft. [Audience member] Each one solves a piece of the problem. Putting them together implies that we solve the entire problem, which we probably do not have the bandwidth for. So, keep them separate, but keep them bound together, though. Q (Rosen): is this really solving a different problem A: yes, because ... Ross: who has read both drafts? only 9 hands most of those 9 think both should be progressed Ross: anyone who thinks either idea is a bad thing to progress? None. Rick Wilder: we need to make it more clear in draft each how they relate to each other. Townsley: Keeping them separate allows more flexibility to advance them (or not). ---- draft-defeng-l3vpn-ipv4-ipv6-hybrid-01 www.huawei.com Two cases Both backbone and sites are v4 and v6 hybrids Case 2 : IPv4 backbone with IPv4 / v6 Method 1 Case 1 : Carry IPv4 and IPv6 map v4 address to 96+MASK if necessary. Packet forwarding between PE-sites Method 2 for Case 1 multi-hop MP-EBGP set up based on IPv4 Case 2 PE assigns private IPv4 addresses for IPv6 site, and supports a NAT-PT for these sites Add an extra attribute for these sites, IF-V6-Site, Wants this to become a WG draft. Since the draft is not currently available on the IETF server, it was agreed that the author would get the draft re-issued, and we would then discuss it on the mailing list. ------ draft-kulmal-l3vpn-aggregation-pe-00.txt Uses a mechanism that is a hybrid of 2547 chapter 10 option a and b Advantages : Routes are associated to VPNs and IP packets are accessible. Very granular TE is possible. One "Con" is that it needs to keep VPN routers in ASBR routers, which may lead to state issues if it is widely used. Q (Rahul): Isn't it just an implementation difference from option B? A: no because ... |