NBVPN BOF, IETF Pittsburgh, Aug 3, 2000
CHAIRS: Marco Carugi firstname.lastname@example.org, Rick Wilder email@example.com
To join: firstname.lastname@example.org with "subscribe" (no quotes) as the subject.
To post: email@example.com
Archive: Available in 2 weeks
Conclusion from the BOF:
The charter will be updated over the next 2 weeks on the mailing list. The charter needs a more explicit definition of nbvpns, i.e., that they are based on layer 3 functionality, and the scope of the charter needs to be clearer.
Design teams will be set up for:
- the framework document [NOTE:Needs to include terminology and requirements - the requirements will likely be spun off into another document]
- Model 1 - VRFs
- Model 2 - VRs
- Possibly a design team for inter-domain issues
Watch the mailing list for details.
The WG also needs to work out details for cooperation with the ITU. WG chairs will talk to Scott Bradner for any current working proposals in this domain. In particular, need to clarify if ITU documents need to be submitted as Internet-Drafts to be considered.
Comment (Eric Rosen): We need to have definitions of terminology, and we need to define requirements. We also have two VPN models gaining in deployment. We need to standardized them as quickly as we can, or defacto standards will take over. It is clear that there are two models. We need separate design teams and we do not need to waste time debating the models. We also need a framework document that is neutral towards the two models.
Network-based VPNs: characteristics (Rick Wilder)
- need for isolated routing - for closed user groups, confidentiality, all non-globally unique VPN addressing
- support for outsourced configuration & management - need to keep it simple for customers
- support for site-to-site performance assurances
- facilitate VPNs which span multiple carrier networks
1) standard framework - multi-vendor
2) optimal scaling for carrier backbones
3) independence of VPN functions from underlying transport
Output from the proposed WG:
1) framework document
2) further specification of existing solutions: RFC2547 model and the VR model
3) inter-domain issues
4) requirements document - both provider and VPN user requirements
- new routing protocols, new tunneling schemes, new security mechanisms
The charter will be finalized on the mailing list.
WG Objectives (Marco Carugi, France Telecom)
- to standardize one or more sets of mechanisms for supporting network-based VPNs
- to engage Service Providers to further refine service requirements
- to develop a framework for nbvpns (and NOT to compare existing protocols)
- applicability of different methods for tunneling associations
- coordinate with other organizations (e.g., the ITU)
Proposed Goals and Milestones were presented.
Q1 (Eric Rosen): what does coordinate with the ITU mean?
A: give feedback on this BOF to the ITU; make sure we have the ITU documents as input to this group, where we will validate them on their merits, and also make sure the ITU has copies of our documents.
Q2: what is the goal of this proposed WG? Overlap with the IPSec Policy WG, which is also dealing with inter-domain relationships?
A: We will start from existing specifications, and will not reinvent anything
Q3: GRE is one of the tunneling mechanisms, but don't we need encryption?
A: Not all VPNs support encryption right now. Some networks are private and don't need encryption.
Q4 (Jessica Yu): We have two mechanisms and we agree to develop them both. What about new mechanisms?
A: No other mechanisms are identified yet. But if other mechanisms come along, they are not precluded from being considered.
Q5: The two mechanisms are NOT orthogonal. You can be compliant to RFC2547 and still use VRs
A: The challenge for the framework document is to have clearer terminology. The framework document will identify the commonality between the two models and the design teams for the models will concentrate on the differences. Goal is to maximize the commonality between the two models.
Q6: The drafts talk about link. There are many different kinds of VPNs addressed. It would be better for this WG to focus.
A: We have decided to focus on VPNs with layer 3 functionality, i.e. nbvpns. You are right, this needs to be more clearly defined in the charter.
Q7 (Tom): Scope and terminology are important. It is misleading to separate the two models. However, the models will become clear in the framework document. The charter is clear and is enough to proceed from.
A: Yes, we don't want to write the framework document in the charter!
Q8: We need to propose solutions that are standards-based.
A: The issue is that there are VPN products today, and there is no specification that allows vendors to achieve interoperability.
Q9: VPNs do interoperate. Look at IPSec.
A: But there is no layer 3 based solution. That is the focus of this WG. As for IPSec, people want different tunneling mechanisms other than IPSec, for example, GRE and MPLS.
Q10: The key thing that operators want is to be able to mix and match at the edge of their domain
Q11: nbvpn is not a good name - how about circuit switch over IP?
A: We are not building point to point circuit based VPNs. We are sharing routing between the customer and the ISP.
Q12: The WG is biting off a lot. The problem needs to be pared down.
A: This WG is one small piece of what was proposed a couple of years ago in the last VPN BOF.
Conclusion: Do some rewording of the charter to address these concerns.
ITU work (Marco Carugi, France Telecom)
Marco gave an overview of the current work in the ITU Q13/20 - IP services using MPLS. There is a draft recommendation: "Network based IPVPN using MPLS Architectures". Marco expected the ITU to make this recommendation available soon to this group.
Proposed ITU focus: service requirements, architecture (broad scope), and leave solutions to the IETF
Proposed IETF focus: framework, solutions and technical specifications, take into account the ITU's service requirements
Q13: what is the main focus of this WG?
A: The main goal is multivendor interoperability in one service provider, and to maximize the commonality between the two models. After that comes the goal of interoperability between service providers (i.e. the interdomain problem).
Q14: Does the IETF have to comply to the ITU architecture? Also, the ITU documentation needs to be made available as internet-drafts
A: We are working on this. It will be discussed at the next ITU meeting in September. Scott Bradner has experience on this because of the Megaco/H.248 joint work with the ITU.
BGP/MPLS VPNs (Eric Rosen) - draft-rosen-rfc2547bis-02.txt
Eric discussed how RFC2547 VPNs differ from "Traditional VPNs", gave a brief technical summary of them, and an overview of recent work.
- overlay model - mesh of VCs, end points at customer sites, over controlled carrier network, packet ingress determines egress, VC mesh is visible to routing, labour intensive
- optimal routing - full mesh
- modern variation - replace VCs with tunnels
- no routing-visible overlay
- optimal routing through the carrier network - packet egress is determined by ingress, routing information and policy
- management is O(n) instead of O(n**2)
Use of BGP
- adds 64-bit Route Distinguisher (RD) to the IP prefix, making BGP routes unique even if the customer addresses aren't. Still need the RD even if using Ipv6 because you need to be able to distinguish VPN routes from public internet routes
- BGP semantics preserved
- flexible route distribution policies, can use this to force "extranet" packets through firewalls, allows hub&spoke connectivity, etc.
- Carrier's carrier, multiprovider VPNs, Service Provider management of CEs, Internet access via VPN interface
- Work done on using OSPF as the PE-CE protocol
- multicast for VPNs
Q15: CE and PE are logical functions and don't need to be in separate boxes. But a VR could have both CE and PE
Q16: If there is a routing change in the customer network, it must be piggybacked on BGP. Thus an unstable customer could generate many BGP messages that end up in the backbone. Thus we have BGP message processing overhead.
A: BGP is designed for inter-admin routing, so it can deal with this.
Q17:Do route reflectors filter off routes the PE device does not need?
A: The PE tells the ORF (On Route Filter) what it wants to receive. You can divide VPNs among router collectors.
Q18: Is multi-provider VPN possible of the providers do not have an existing peering relationship? (With IPSec you do NOT need an existing peering relationship)
A: No, you must have a business/peering relationship in place.
Q19: Are BGP extensions needed for each kind of protocol, i.e., for BGP, OSPF, IP/IP, multicast?
Network based IP VPN Architecture Using Virtual Routers (Hamid Ould-Brahim) - draft-ouldbrahim-vpn-vr-01.txt
NBVPN - what is it?
- not all VPNs are created equal. Some want strong security, some availability, some a "network feeling".
- the architecture must be resilient to PE and network failures
NBVPN architecture design goals
- flexibility (e.g., different tunneling mechanisms), scalability, resiliency, reusability, security
What is a VR?
- it is an emulation of a physical router
- only PEs handle VPN information, internal backbone is not VPN aware, ...
VR VPNs can mix VPN IPv6, and VPN IPv4 with an IPv4/IPv6 backbone without any change.
Q20: do you need to change the routing protocols with VR VPNs?
A: No, each VR can run any protocol, and no new procedures need to be added to them
Q21: Has there been any performance analysis of the two models?
A: Maybe, but instead of concentrating on this, we will pull out the common mechanisms in the two approaches and document the differences
Q22: the presentation did not have enough detail
A: please look at the internet-draft for more detail
VR VPN solution ( Karthik Muthukrishnan, Lucent)
- multiple IP domains on one backbone
- main point is that there is one IP stack per customer - whatever is on it, the customer gets, so you want to let the customer decide what features he wants to use
- with the VR, you don't have to replicate everything, just replicate what the customer needs
- the Service Provider does the management
- outbound route filtering is critical, configuration should scale, there should be minimal use of service provider resources, etc.
- can customize whether to use static routes vs BGP, small vs large VPNs, simple vs complex VPNs, different QoS.
Two main Architectures/Models
1) piggyback model (RFC2547) - vendor specific choice of protocol
2) VR clones - protocol agnostic
Scalability - instantiate VRs as you need them
Conclusion: VR VPNs are scaleable, secure, and flexible
Q23: Is multicast used for users?
A: multicast features can be extended to VPNs
Q24: can you configure a hub&spoke?
A: VRs are just like physical routers, so the answer is yes.
RFC2764 - A Framework for VPNs (Bryan Gleeson, Nortel Networks)
- discussed at the last BOF
- scope of this BOF is much smaller
- VPN types: layer 3 (which is the scope of this BOF/WG), layer 2, leased line
- NBVPN definition: tunnels terminated on PE routers instead of on the customers' routers.
- overlapping address space
- range of security capabilities
- range of QoS capabilities
- Internet access and VPN access
- Extranet connectivity
Generic Steps to set up VPNs
1) assign interface to VPN (static, dynamic)
2) Membership/neighbour discovery
3) Learn customer site reachability
4) Distribute reachability across VPN
Tunnelling protocols: IPSec, MPLS, LSP, GRE, IP/IP
Comparison of Existing Schemes (see slide 11 - slides to be posted on nbvpn web page)
PROPOSAL: that this group adopt RFC2764 as the basis for the framework document
Extensions to LDP (Tom Wister, Innovate)
- Tom is working on reachability and autodiscovery as extensions to LDP. He is planning to submit this work to the WG if it gets chartered.
- If anyone is interested in working on this with him, please contact Tom.
A Framework for Network-based VPNs (Muneyoshi Suzuki, NTT) -
NBVPN definition: NBVPNs are Virtual Private Routed Networks (VPRN).
CPE-based VPNs are out of scope.
- closed user group (extranet, QoS SLAs, dynamic routing, multiprotocol transport, security, nbvpn over multiple SPs, multicast
Reference Model: contains networks, edge devices, edge device tunnels
Comments already received on this draft from Joel:
- protocol architecture needs to be clarified, ex. User plane, control plane, management plane
- must be applicable to both VRF and VR models
- add: IF and MIB specs, criteria for achieving interoperability, security considerations
PROPOSAL: adopt this draft for the framework document.
BGP/IPSec VPN (Jeremy DeClercq, Alcatel) -
Motivation for this work
- RFC2547 relies on MPLS networks, but they are not widely deployed, other tunneling mechanisms exist, and security is required
The proposal is to replace MPLS by IPSec. To do this, 2 labels are needed. SPI identifies a tunnel. Use the SPI prefix for the security association, and the SPI label as the second MPLS label in RFC2547. Either a new BGP attribute is needed (SPI-label attribute), or the MPLS label can be used as the SPI-label, as in RFC2547. There are two choices for building the tunnels: either 2 unidirectional tunnels between PEs (not between VRFs), or a full mesh of IPSec tunnels in a non-MPLS network.
PROPOSAL: that this work be considered relevant to the charter
Q25: One of the goals of VPN solutions is scalability. Is there any way to use this solution without having to build a full mesh?
Criteria for Evaluating VPN Implementation Mechanisms (Jessica Yu, CoSine Communciations) - draft-yu-vpn-criteria-00.txt
Motivation: many VPN mechanisms have been proposed. A set of criteria to evaluate them will be useful.
- flexible topology, hierarchy (for scalability, manageability), independence (between VPN and backbone technology, IP addressing, routing)
- membership management, access management, key management, management boundaries
- architecture, management and routing - must be linear in relation to number of nodes.
PROPOSAL: that this work becomes part of the framework and requirements document
MPLS extensions for VPN (Zhang, Unisphere) -
The proposal is to add a VPN-ID to the signalling protocol so that per VPN PE-PE MPLS tunnels can be set up and treated as layer 2 interfaces. No change to existing routing protocols would be needed. The change to MPLS signalling protocol would be to the CR-LDPLabelRequest message.
PROPOSAL: that this BOF/WG endorse this work so that the MPLS WG will accept these proposed extensions
COMMENT (Eric Rosen): We are at the BOF to WG stage. The WG cannot accept specific proposals yet. Standard practice is to encourage everyone with a vendor specific solution to write it up and submit it. After the framework and requirements documents are done, the WG would look at solutions.
COMMENT2: This proposal provides one way to map VPNs to LSPs. There are other possible mechanisms (for example, one possible mechanism is contained as a small part of 2547). It is premature to decide which mechanism to use.
- end - see above for conclusions -
A Virtual Router Approach to Building Network Based VPNs
Criteria for Evaluating VPN Implementation Mechanisms
Extensions to CR-LDP for VPNs
A Framework for Network-Based VPNs
Recent work in ITU on MPLS-based VPNs
Network-Based VPNs: Characteristics
A Framework for IP Based VPNs RFC2764
Network-Based IP VPNs using Virtual Routers