Last Modified: 2004-11-01
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 |
RFC | Status | Title |
---|---|---|
RFC3809 | I | Generic Requirements for Provider Provisioned Virtual Private Networks |
=================== 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 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. 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 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 > ( 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.>(??? (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.
|