2.4.12 Network-Based VPNs (nbvpn) bof

Current Meeting Report

NBVPN BOF, IETF Pittsburgh, Aug 3, 2000

CHAIRS: Marco Carugi marco.carugi@francetelecom.fr, Rick Wilder rwilder@bbo.com

Mailing List:
To join: nbvpn@bbo.com with "subscribe" (no quotes) as the subject.
To post: nbvpn@bbo.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:

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)

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


The charter will be finalized on the mailing list.
WG Objectives (Marco Carugi, France Telecom)

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.

Traditional VPNs

RFC2547 VPNs

Use of BGP


Recent additions

Future work

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
A: ?

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?
A: Yes

Network based IP VPN Architecture Using Virtual Routers (Hamid Ould-Brahim) - draft-ouldbrahim-vpn-vr-01.txt

NBVPN - what is it?

NBVPN architecture design goals

What is a VR?


Multiprotocol VPNs
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)

VPN scaling:

Customizable solution

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)


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)


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.

Assumed services

Reference Model: contains networks, edge devices, edge device tunnels

Comments already received on this draft from Joel:

PROPOSAL: adopt this draft for the framework document.

BGP/IPSec VPN (Jeremy DeClercq, Alcatel) -

Motivation for this work

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?
A: no


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.




Operation transparency

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
WG Objectives
Network-Based VPNs: Characteristics
RFC2547 VPNs
A Framework for IP Based VPNs RFC2764
Network-Based IP VPNs using Virtual Routers