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|
|RFC3809||I||Generic Requirements for Provider Provisioned Virtual Private Networks|
===================Thanks to Mark Duffy for minutes. >
Agenda bashing and scribe discovery.
Working group document status
Multicast Requirements (Thomas Morin / Elodie Hemon)
Multicast Approach (Eric Rosen)
Multicast Approach (Rahul Aggarwal)
Multicast Approach (Seisho Yasukawa)
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
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 iesgTextual 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 iesgbgp/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.>
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 routersNeed:
scalability, tunability, traffic engineering,
versatility (vis-a-vis tunneling modes),
inter-AS, inter-provider support
robustness and infrastructure security >
Fragmentation issues? MTU management.
Need use cases
Integrate received feedback
Want more feedback!
(???): 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-07Mcast 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.
> 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
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.
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.>
One size doesn't fit all.
The most scalable schemes may be too expensive in traffic loading.
Technology to create the MDT?>
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?
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
Comparison of costs of 2547 unicast vs multicast
why multicast doesn't scale as well
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)
Amount of state and processing to maintain it should not exceed those for unicast.
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
Qos, reliable mcast, adequate operation and mgmt
Focus on L3
avoid PIM adjacency maintenance
avoid suboptimal IP packet distribution
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
Use MDT-SAFI to discover PEs of same vpn
PIM-SM, PIM-SSM supported with same model
Multiple topologies of MDT
Applicability of PIM-DM and PIM-BIDIR
Optimize default/data p2mp tree operation
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.