NOTE: This charter is a snapshot of the 51st IETF Meeting in London, England. It may now be out-of-date. Last Modified: 31-Jul-01
Rick Wilder <email@example.com>
Marco Carugi <firstname.lastname@example.org>
Scott Bradner <email@example.com>
Bert Wijnen <firstname.lastname@example.org>
Scott Bradner <email@example.com>
Rob Coltun <firstname.lastname@example.org>
To Subscribe: email@example.com
In Body: (un)subscribe in message body
This working group is responsible for defining and specifying a limited number of sets of solutions for supporting provider-provisioned virtual private networks (PPVPNs). The work effort will include the development of a framework document, a service requirements document and several individual technical approach documents that group technologies together to specify specific VPN service offerings. The framework will define the common components and pieces that are needed to build and deploy a PPVPN. Deployment scenarios will include provider-managed VPN components located on customer premises.
The service requirement document will detail the requirements individual PPVPN approaches must satisfy from a Service Provider (SP) perspective. Particular attention will be placed on SP requirements for security, privacy, scalability and manageability considering such factors as Service Provider's projections for number, complexity, and rate of change of customer VPNs over the next several years. The working group will make specific efforts to solicit this information from SPs. The service requirements document is not intended to define the requirements that all approaches must satisfy. Rather, it is intended to become a "checklist" of requirements, not all of which will necessarily be required in all deployment scenarios. A goal of the requirements document is to provide a consistent way to evaluate and document how well each individual approach satisfies the individual requirements.
The effort will produce a small number of approaches that are based on collections of individual technologies that already exist (see below for specifics). The goal is to foster interoperability among implementations of a specific approach. Standardization of specific approaches will be gauged on (I)SP support. Note that it is not a goal of this WG to develop new protocols or extend existing ones. Rather, the purpose is to document and identify gaps and shortcomings in individual approaches with regards to the requirements. In the case that specific work items are identified, such work will be done in an appropriate WG. Taking on specific protocol work items in this WG will require rechartering.
The working group is expected to consider at least three specific approaches including BGP-VPNs (e.g. RFC 2547), virtual routers and port-based VPNs (i.e., where the SP provides a Layer 2 interface, such as Frame Relay or ATM, to the VPN customer, while using IP-based mechanisms in the provider infrastructure to improve scalability and configurability over traditional L2 networks). Multiple approaches are being developed as each approach has particular characteristics and differing scope of applicability.
The working group will consider inter-AS (SP) VPN interconnects so that VPNs are able to span multiple ASs (SPs).
Each technical approach document will include an evaluation of how well it meets the requirements defined in the requirements document. In addition, technical approach documents will address scalability and manageability issues as well as their operational aspects. Individual approach documents will also analyze the threat and security aspects of PPVPNs and include appropriate mandatory-to-implement technologies and management mechanisms to ensure adequate security and privacy of user data in a VPN environment. This analysis will include cryptographic security from customer site to customer site using IPSEC.
An applicability statement will be developed for each approach that describes the environments in which the approaches are suitable for deployment, including analysis of scaling impact of the approach on SPs and threat analysis.
Coordination with the IETF PWE3 and ITU-T efforts will be ensured.
Formulate a plan and begin approaching SPs for input on scaling and other requirements
Begin discussion (based on submitted IDs) on candidate approaches against the different service requirements.
Begin discussion of the framework and the service requirement documents. Identify a limited set of candidate approaches. Build appropriate design teams.
Begin discussion of applicability statements.
Submit the framework and the service requirement documents to the IESG for consideration as Informational RFCs.
Submit the candidate approaches and applicability statements to IESG for publication.
Charter update or WG disband
51st IETF Meeting - PPVPN WG minutes
1. Agenda bashing - chairs
Slightly delayed start. Marco asked the presenters to respect time in order to accommodate the tight schedule. Marco went through the agenda items
2. PPVPN work status (mailing list, goals/milestones, WG IDs, L2 space work, design teams, candidate solutions, missing work, related ITU-T progress)
- 10 min - Marco Carugi
The following work items have been completed:
- begin discussion on framework and requirements
- identified first set of candidate approaches.
- Begin discussion on approaches with respect to requirements
- applicability statements
- framework and requirements drafts to be submitted to IESG by December 2001
- candidate approaches and apps statements to be submitted to IESG by March 2002
- revise charter in March 02.
Marco went through the list of WG documents.
Updated WG documents
New WG documents:
- CE-based VPNs using IPSec
- Architecture for l2vpns (controversial)
Candidate solutions space:
- bgp-based drafts (2547bis, IPSec, GRE, Ipv6, mib).
- VR-based (ouldbrahim, bgp autodiscovery, muthukrishnan, link broadcast and vr discovery, hierarchical vr, mib)
Marco described the Design teams
Requirements team - 7 Service Provider authors
Framework - 8 authors
Recently formed team - Transparent LAN services (TLS) team (l2 metro vpns):
7 main authors: Heron, Senevirathne, Ouldbrahim, Augustyn, Vach Kompella, Lasserre, Menezes
Objectives of TLS: detailed requirements, solutions, convergences, coordination with PWE3 ethernet design team.
In parallel, provide input for basic framework document.
Other teams possible in future.
Candidate solutions at this stage:
- BGP based
- VR based
Other possible solutions (next stages):
- CE based ipsec
- Port based (l2vpn,ovpn)
According to the Charter a limited set of standard solutions will be produced. Standards track solutions will be gauged by SP support
Other important pieces of work:
- Inter AS VPNs
- Applicability statements
- All that is needed to facilitate interaction with protocol specific WGs (PPVPN is not mandated to enhance protocols)
- Task sharing and cooperation with PWE3 has been lauched, some elements of discussion still to be done
- encapsulation, signaling, tunnel setup and maintenance (PPVPN TLS team to collaborate with PWE3 ethernet PW team) ITU-T progress since IETF Minneapolis meeting:
- obtained consent on Y.1311.1 in May 01
- Y.1311 needs enhancements (planning for consent in January 02)
- Interim Question 11 meeting in Geneva on Nov 5 will be held to work on VPN TE and progress Y.1311
- An ITU-T VPN workshop was held in Geneva in April 01.
There is a good synergy between IETF and ITU-T.
Question - Kireeti: clarification on L2vpn WG document: Marco said it may die or progress as architecture document. Right now it has architecture, requirements, approach etc. If it lives are we going to clarify if it will be an architecture document?
Marco: There will be no separate architecture document. This will be integrated with overall arch doc (convergence hoped for). Will die in terms of being a standalone document, but contents will be added to architecture document.
3. PPVPN Service requirements update - 5 min - Dave McDysan
Dave discussed the changes from 00, open issues, future usage
Changes from version 00:
- Augmented definitions
- aligned some definitions with framework (more work to do in future revisions)
- spelt out network management requirements as separate section
- removed solution specific text
- filled in gaps and addressed open issues
- resolved internal inconsistencies
- reorganized outline and some sections
- added some additional requirements (from referenced I-Ds from Minneapolis, and from SP comments)
Open issues: need compete alignment with framework (terminology, minimize duplication, decide on whether ce-based l2vpn makes sense, since it refers more to LAN-based services)
Need more feedback on mailing list
If agreed to by WG, need details on ethernet l2 vpn requirements, ovpn requirements.(some volunteers have been obtained)
- As per WG charter, each solution approach should address applicable requirements (some of these candidate approach authors seem to have not read requirements document)
- Applicability statements will use requirements as a checklist for each WG approach
- coordinate requirements document content with PWE3 WG (Multipoint and ethernet pseudowire)
- depending upon scope decision by WG, this could be used as input to some PWE3 doc.
4. PPVPN Framework update - 5 min - Ross Callon/Muneyoshi Suzuki
Changes from 00, open issues, future usage
Muneyoshi presented the draft.
Differences from 00:
- Reference models and terminology updated with requirements document
- L2nbvpns added
- Provider provisioned CE based VPNs added
- Interworking, internet access added.
- Security considerations updated.
Charter related issues for L2nbvpns:
Scope of SP network technology (ip/mpls only OR ip/mpls and L2 (ATM/FR, MAC)). Since the latter (L2) are not IP protocols, this should be discussed in the charter.
Scope of supported service properties on customer Interface (PE-CE IF)
Service properties (representative) on customer Interface of L2nbvpns
- FR UNI service (traffic control based on CIR, FECN/BECN and DE, LMI support)
- ATM UNI service (CBR, VBR, GFR, OAM, point-to-multipoint VC support)
- MAC service (broadcast , private address)
- PDH/SDH UNI service - reference clock support plus service accuracy.
Charter issues for provider provisioned ce-based vpns:
- scope of services provided from CE to customer (IP or IP and L2) - no contributions received on latter, how many are interested?
- scope of CE-CE network technology (IP/MPLS or IP/MPLS and L2) - again, what to do about L2 technologies if they are non IP protocols?
- similar issues for tunneling technology as for L2nbvpns
- Enhance l2nbvpns reference model and so forth to coordinate draft-ietf-ppvpn-l2vpn-00.txt
- enhance provider provisioned ce-based vpns reference model to coordinate draft-ietf-ppvpn-ce-based-00.txt
- extend interworking discussion to l2 and ce-based vpns
- QoS discussion on customer and network interfaces
- constraining vpn connectivity
- management, protection/recovery
Marco - comments on these issues on the list.
5. PPVPN CE-based Framework using IPsec - 10 min - Jeremy De Clercq
draft-declercq-ppvpn-ce-based-00.txt (renamed as draft-ietf-ppvpn-ce-based-00.txt)
Just ID overview, future steps, open issues
Jeremy presented the draft.
- intend to synchronize with ppvpn framework draft.
- CE device (assumed reachability - IP connectivity with provider network via PE device, VPN functions to be managed by SP)
- PE device ( no vpn specific functions on data plane, only needs to forward IP packets)
- SP management device has "control channel" for CE device.
Configuration of CE based VPN:
- configuration of SP vpns database
- configuration of CE device (control channel, peer CE devices, security)
- updating of configuration info (use of dynamic management protocol, pushes vpn info from SP to CE or triggers to pull info out via COPS, LDAP, SNMP etc)
- setting up the vpn tunnels
- IKE or alternative to be used for dynamic setup of SA
- IPSec tunnels (Traffic drivien or permanent ipsec tunnels)
- Number of ipsec tunnels is dependent on role of VPN site.
Exchanging and maintaining vpn routes:
Proposed mechanism 1 - tunnel through ipsec tunnels (may be an issue for routing protocol messages with traffic driven tunnels setup)
Proposed mechanism 2 : reachability via SP's management system (cecommunicates updates to SP managements)
Tunneling IP traffic through vpn sites:
Can use IPSec in tunnel mode (ipsec does SA selection, encapsulation and authentication/encryption) or transport mode (draft-touch-ipsec-..).
- the draft as it is now is neither a complete framework nor a detailed solution (it is very ipsec specific, could use other protocols). Not a detailed solution since we assume secured "control channel" in SP management system.
Mechanisms may need ipsec extensions(as per draft-gleeson-ipsec-vpn-..), routing through tunnels, permanent tunnels
- PPVPN charter requires a set of ppvpn solutions (This is the first document for CE based approach)
- Synchronize and add parts with to ppvpn fw draft?
- Evolve to solution proposal for CE based ipsec vpns (details needed on secure control channel, security information, etc)
- Need to line it up with IPSP, IPSec et al.
Q: Juha Heinanen - It will be useful to describe mgmt system for PE based vpns too (cops, snmp etc). Management system makes life much easier compared with bgp-autodiscovery mefchanism. So will be very useful to add this to PE-PE charter.
A: Jeremy - most Pe-based solutions use bgp autodiscovery versus mgmt.
Juha - I don't like that. Therefore add a requirement to SP requirements document to support management-based provisioning.
Marco - Framework document includes different possibilities for provisioning. Do not understand if this is a specific requirement to be added in requirements document, as it may impact scalability. Will evaluate each candidate approach with respect to ease of configuration. Will revisit in applicability statement and evaluate scalability of scheme.
Juha - There is no scalability issue in management scheme. You have to do it anyway. Now you are doing it via telnet to the box.
6. L2 point-to-point VPN space (requirements, solutions):
Discussion on open issues, solution convergence, WG IDs - 10 min - related ID authors/all
Related IDs :
- draft-rosen-ppvpn-l2vpn-00.txt (renamed as draft-ietf-ppvpn-l2vpn-00.txt)
Kireeti: draft-kompella, draft-shah (2 drafts) - Have absorbed most things into latest version of draft-kompella, will discuss with Himanshu Shah for further work. As far as Rosen draft is concerned, it has requirements, framework and architecture. As far as solution is considered, I disagree with some things - will take to list. Rosen is well known for L3 (but is not the most unbiased person for L2 work). Requirements are needed from SPs.
As far as the Martini draft is concerned, we will take the encaps work (this wg doesn't need to do this), signaling. As far as provisioning is concerned, we can use autodiscovery. Overall, there are some drafts that we want to merge (kompella, shah) . separate other drafts.
Marco: what do you propose for SP requirements? (l2vpn specific)
Kireeti - either add to current draft, or separate. Might make more sense to have separate draft to keep it independent of the main requirements draft. At some stage, we will need some form of applicability statement to compare different solutions - L2, L3, OVPN etc.
Marco: since we have not standardized anything, our primary intention is not to have multiple solutions, but converge all. Hope to see on list different technical divergences to converge later.
Kireeti - Shah drafts are extensions to ours. So they are easy to merge with ours. We may remove LDP for discovery (use BGP in future version), so we will further converge with Martini. Will have discussion with others.
Luca Martini - agree with Kireeti about his BGP design. LDP is not suitable. However, we don't have standardizaton on LDP extensions. Martini-encaps will go to PWE3 wg. Haven't figured out yet where to send martini-trans draft. May send to PWE3. Over 5 implementations on this technology, 3 have been interoperable. Have been in deployment.
Therefore need to go for informational RFC for current design (will continue to progress drafts, but since current design is frozen, martini-encaps should be informational RFC). Kireeti's draft references martini-encaps which is not standard. If martini-encaps becomes an informational RFC, Kireeti can reference that.
Marco: It is a common problem to advance one WG draft with other WG's references.
Clarence Filsfils - coauthor of rosen draft. Looking forward to work with other L2VPN authors to achieve a single architecture and solution.
Juha- I favor the LDP approach. It has lesser management problems. Else vendors will force everybody to start BGP on all networks that deploy PE-based VPNs. BGP is good, but its extensions are complex. The two should be decoupled. I advocate LDP for discovery. (rather than BGP turning on the VPN).
Scott Bradner - I second Kireeti on applicability statement thought
(how to use different approaches l2 versus l3 etc). This is particularly important between technologies, not in the same space.
Reluctant to progress martini-encaps to Informational RFC as this confuses people.
Dave Meyer - agrees with Juha on LDP point.
Not much need to say anything about the scalability of L3 vpns
(Pe-based versus ce-based) in the applicability statement, as it is well understood.
Not sure where provider based L3 VPNs is going. This group should clarify that.
Scott - note that applicability statement can say "it hurts to go there". It gives rationale, take a look at the RSVP applicability statement for example.
Kireeti - Dave is now a service provider, so listen carefully. Second, we will make a change in next version on the multiple tunnel types (not MPLS specific)
Mark Townsley - seconds kireeti.
Marco - may choose most appropriate solution via Kireeti's applicability statement proposal.
7. L2 VPN space(requirements, solutions):
BGP-MP for layer 2 VPN membership discovery
draft-tsenevir-bgp-l2vpn-01.txt - 5 min - Tissa Senevirathne
Just ID overview, open issues and future work, how to deal with
Tissa: We use the 2547bis approach.
Key points - distribute VLAN span (scope), so it has differences with respect to L3 VPNs.
Transit AS is required to pass MP-BGP extensions (current method works for point-to-point, point-to-multipoint, shared tunnels)
Marco- this document uses BGP autodiscovery. So discuss with authors of BGP autodiscovery to see how this can be applied here. Try to figure out generic discovery mechanism (BGP, others etc).
Dave - This doesn't meet tunnel endpoints goal. Am not going to run
MPLS VPNs to the discovery endpoints.
Tissa - can be used for non mpls tunnels.
Dave - can talk offline
Dave McDysan - have seen a lot of work on this area. BGP extensions can cause problems (punched holes in AS, endpoints etc). A separate draft on the impact of BGP extensions is needed. BGP is becoming overloaded
Tissa - need something like local policies for inter AS.
- problem with presentation. Later.
8. Report on VPN MIB progress, issues, future steps - 5 min - Thomas Nadeau, Elwin Eliazer
Related IDs :
- Models MPLS-BGP VPN instances on PE and CE based on 2547 bis. The collective group of instances form the vpn.
VRF (VPN-enabled interfaces, configuration, provision, RD, Route target, statistics, notifications)
Changes: draft name change since it is now a WG document
Minor changes, largely related to compilation errors in previous versions.
More performance counters?
Currently lots of SP input from real deployments (need more input, especially notification and performance)
Will issue new version shortly
Elwin Eliazer draft-elwin-ppvpn-vr-mib-00.txt
Single SNMP agent to manage multiple VRs in a PE.
SNMP contexts to identify different VRs (can reuse existing standard MIBs, no need for additional index)
VRId to index VRs
VR MIB tables:
Objects were defined.
Details on tables discussed.
Future updates: more default values to be added, remove some elements, means to associate multiple VRs with tunnels, need more comments from SPs.
Scott - first slide said "manage multiple instances of VR". What kind of access would customer have to VR? SNMP?
Elwin: No. Customer will not have SNMP view of VR.
Scott - need to think about that.
9. Applicability Statement guidelines - 5 min - Junichi Sumimoto
Just overview of main concepts, open issues, possible future steps
draft-sumimoto-ppvpn-applicability-guidelines-00.txt : not submitted
(just sent to the list), available at http://ppvpn.francetelecom.com ->Related Internet drafts-> London (post-meeting note: ID submitted on August 30th)
Junichi presented the draft.
Why do we need App. Statement guidelines?
- assist development of App. Statements for each specific ppvpn approach (outlines main requirements, common frame, shows applicability and limitations, pointers, engineering tradeoffs).
- guidelines will lead to smooth development of App Statements
Outline presented (intro, overview, outline of reqts - general, l3 and l2-, applicability, limitations, security considerations).
Status: sent to list (not officially submitted as ID), introduction and technical overview mostly filled out with initial text referring to framework document, outline of general and L3 specific requirements from requirements document.
- Extract outline of l2vpn requirements from various I-Ds.
Clarify what are common applicability and limitation to some identified types of PPVPNs
Basis of development, tradeoffs.
- more work to complete I-D
- Reflect comments from list
- Official submission as ID
- rough consensus to make this a WG doc
- approach specific App Statement work should start without waiting for completion of guidelines document completion.
Marco: requirement design team (with additional SPs) should develop this. For each specific approach, work should start soon for identified approaches.
Rick Wilder - probably makes more sense to have a common document with common team of authors.
10. draft-heron-ppvpn-vpsn-requirements-00.txt Giles Heron presentation:
VPLS - name stolen from rfc 2764.
Functionality - multipoint Ethernet over X
Targeted at metro applications. (ATM TLS replacement, alternative to l2 VLANs)
Work in progress (3 requirements drafts, 2 solutions drafts, 1 architecture draft before cutoff). WG has set up a team to merge these drafts together (are requirements and solutions sufficient?).
Other issues: coordination with PWE3 (encaps, signaling, potential overlap to be resolved). Need to synchronize with PPVPN requirements and framework documents. I am a member of pwe3 and ppvpn design teams, so will make sure of synchronization.
Marco - There could be a standalone L2 requirements document.
11. Waldemar Augustyn presentation (draft-augustyn-vmi-m2m-arch)
Written for organizing effort for distribution functionality between nodes, distinguish functional components within each node.
Outline - architecture - service point of view (sp and customer perspective), VPN fundamentals, multipath, multihoming, bandwidth mgmt, interdomain traffic, orderly access to value added services, infrastructure security.
May do these things in other working groups (will get a common view on L2 metro network from this group, but will utilize work on other WGs).
Marco - this will not be the focus of the design team. Suggestion to check with framework team which content from this draft may be valuable input for the basic framework draft.
12. Solutions drafts:
VPLS overview - draft-lasserre-tls-mpls
Scope: - PE-PE (no bearings on PE-CE communication).
Question: Juha - why do you show an mpls cloud?
A : This is an MPLS specific draft. (vpls over mpls specific).
Juha - Then, how interesting is this? Any solution that this group comes up with should support hybrid solutions (PE should be IP reachable, not MPLS reachable).
A: I agree, but this is an MPLS-specific draft.
Marco - we are not restraining the scope to MPLS. This draft is specific to MPLS
Dave - It should meet requirements
Yakov - once MPLS-over-GRE and MPLS-over-IP drafts are finalized, Juha's points will not be valid
Luca - Was going to repeat yakov's point.
Juha- Don't object to that, but object to the use of "mpls cloud"
Yakov - ok.
Vpls design, provisioning (uses vpn id).
Future work: Combine lasserre and vkompella drafts (minor differences, MAC withdrawal) Autodiscovery, other topologies.
Scott - Yakov is accurate about mpls over ip. But the charter assumes non-mpls too. So this is not good.
Giles - PWE3 defines encaps. So it is not correct to assume encaps here.
Juha - Need to put something more than just ethernet frame in mpls frame.
Marco - encaps should be done somewhere else. This is a point to be addressed.
13. Draft-vkompella-ppvpn-vpsn-mpls-00.txt (Vach Kompella)
Using the term "vpls" as good faith.
Broadcast at PE (destination PE not learned), wrong PE dumps packet. Difference with lasserre draft (MAC address movement. Addresses CE multihoming problems). Old bindings won't work in multihomed CE. Therefore add extension (TLV) to force unbinding and relearn.
Regarding what juha mentioned - Vpls signaling using MP-BGP (using BGP to signal multiple VC labels on per PE basis is bad, alternative - from any PE signal a single VC label for all VCs inbound for a particular VPLS). Use 2547 approach. L2 MAC learning is difficult (therefore redefine ethernet control word, demultiplex incoming packets based on sending LSR for l2 learning). Objection to Tissa's proposal , will talk about it offline
Mark Townsley: With respect to PWE3, tunnel setup and maintenance is more than just label exchange. Other end to end signaling is required to keep l2 signaling happy.
Vach - sure, doesn't mean that we need to use only LDP for signaling.
There are other mechanisms for things like maintenance of tunnels. Not within scope of this work.
Mark - need to draw line on scope of different WGs work
Vach - This is putting a requirement on PWE3.
Martini - You only need to know source info of packet and need to reply to that MAC address. This is just a duplication of MPLS label. Would like to figure out a way to use another MPLS label (instead of creating a costly new encaps parameter).
Vach - if we use mpls, we will have a problem with other protocols.
Touch - This recaps the difficulty to providing point-to-point LANs with ATM. Have you considered if this considers multicast support?
Vach - This will be done in the applicability stmt. Lan emulation with certain context. SPs need to decide the application - e.g. multicast includes Data backup or videoconferencing.
Touch- most lans don't do all this (for lot of reasons including Denial of Service).
Vach - A lot of SPs ask for what we are proposing (w/o multicast).
Touch- I know of a lot of kids asking sugar for breakfast too :-)
14. Service provide experiences with candidate approaches
Equant implementation of 2547bis - Laurent Perrin.
The offering includes Managed CE router, PE with mpls. Access includes FR, fiber, xDSL. Ipsec also provided
Comment: Scott - don't show vendor bias.
Laurent - ok.
Cisco BGP/MPLS VPN.
- simple, scalable, easy to integrate new customer requirements (new access methods, access to shared resources, CUGs and extranet capabilites).
100 PE's, 10000 CE routers connected, FR extended coverage to 220 countries.
Overall - valid approach, all new services will be developed around this platform.
New features required include l2 vpn.
Equant always manages CE routers, legacy FR customers in some ASes manage their own CE, we see layer 2 vpn as opportunity to support on same SP network a fully managed L3 ip vpn service (including CE) and an l2vpn service for sites with customer managed routers, legacy services.
New requirements - encryption
Sohel Khan - objection since Equant seems to be selling their solution.
Marco - no, this is just an indication of SP deployment of candidate solution.
Ananth Nagarajan - numbers are important as they give scalability guidelines for requirements document.
Martini - encryption for CE-CE not required unless customer manages own encryption. Second question - Do you see a backup private line requirement?
Laurent - There have been a lot of requirements regarding backup. Will discuss off line.
Yakov - CE-CE encryption question - Is there any legal obligation to reveal keys to authorities?
Ans - If private keys are used, no obligation to do so.
Scott - This is not a point to discuss here, let us go on to "why are we presenting this here?"
15. SAVVIS - VR-based vpn
Offering: ATM, FR, IP and network-based VPNs using VRs.
Scott - I will admit that you better guaged the audience since you are not wearing a tie. We don't want to know what the company wants to do, but rather how good a technology is.
Geoff: Ok :-)
- ospf stability and performance, manageable, scalable, secure, resiliency (dual circuit delivery, OSPF to the edge enabled management of client).
- ATM backbone, direct ethernet connectivity
vr/vpn offering satisfies both intranet and extranet requirements.
- internet resilience via VR solution.
Scalability - 200+ customer VPNs, largest VPN has 2000+ sites.
uses 50+ core Nortel Shasta boxes.
Performance - no performance degradation for 100+ vpns.
Security - ipsec tunnels, recovery - ospf to edge, dual circuit delivery, hsrp/vrrp.
Easy integration - carrier class, need cost effective products needed.
Bruce Davie: where do ipsec tunnels start and end
Ans: Ipsec tunnels are PE-PE
Bruce - Savvis manages the keys? Customer thinks this is good?
Ans : yes
Bruce - I guess perception is everything.
Sohel Khan - need to draw line between presentation for technical info, versus marketing.
Scott - sympathize with Sohel's concerns, need to discuss this with chairs offline.
Scott: Based on another side discussion with Yakov - the fact that keys are surrenderable to legal authorities should be noted and brought out as a factor in architecture.
Juha - Agree partly. But this is more relevant with global networks here. It is better if provider has keys at end point countries so that countries in between don't see it.
Touch - one of issues with provider owned keys, customer wants provider to protect and encrypt.
Behringer - There are three types of customers - PE-PE, customers that trust SP, customers that use customer based keying. Have to cater to all three.
16. Optical VPN requirements - 5 min - Hamid Ould-Brahim draft-ouldbrahim-ovpn-requirements-00.txt
Just ID overview, why to be considered in PPVPN, future possible steps in OVPNs
Hamid: In the last meeting we were asked to get requirements when solution was presented. Reference model is not different from L2 and L3 (most requirements common to all types).
Reference model, example. (port-based vpn). Basic unit - optical or TDM connection between a pair of CEs.
OVPN customer's view - different types of ports within VPN.
Requirements classified as General, SP, customer requirements.
Scott - charter doesn't have this. Need to hear from ADs. Final decision from IESG and IAB. This WG has to do a lot work, so more work makes me nervous. On the other hand, this work also overlaps with other work in sub-ip. So we need to work on this.
Yangguang - This appears as a reverse engineering from a solution
i.e., PE port provisioning to providers. To be impartial, we should have only SPs on the document.
Hamid - Sure.
Marco - Will take care of recommendation by Scott.
Marco - We are out of time for other talks. Anyway, new protocols are discussed in two of them and they are out of scope at this time.
Please use the list for discussion on all remaining stuff.
Architecture and Model for L2 many-to-many Networks
A framework for Provider Provisioned CE-based VPNs using IPsec
Equant IP VPN
Service Requirements for PPVPN
MPLS/BGP VPN MIB
"Service Requirements for Optical VPNs"
SAVVIS Layer-3 VPN Deployment Experience using Virtual Routers Approach
Use of BGM-MP for Layer 2 VPN
Guidelines of Applicability Statements for PPVPNs
Framework document update 'draft-ietf-ppvpn-framework-01'
Virtual Private LAN Segments