VPN Toolkit for
Service Providers
Yakov Rekhter
Distinguished Engineer
Juniper Networks
Juniper Networks, Inc. Copyright © 2002

平成14年10月28日

Juniper Networks, Inc. Copyright © 2002

2

Layer 2 vs Layer 3 VPN Services
Layer 2:

Layer 3:Service Provider participates inLayer 2 routing and addressing
of VPN customersWithin a single Layer 3 segment

Service Provider does NOT
participate in the Layer 3
routing and addressing of VPN
customers
 From the Service Provider pointof view Layer 2 VPN services
are arguably simpler to operate
than Layer 3 VPN servicesService Provider participates inLayer 3 routing and addressingof each VPN customerAs with Layer 3 VPN services theService Provider has to participate
in customers Layer 3 routingService Provider has to maintain
Layer 3 routing information foreach VPN customer

From the VPN customers’ pointof view Layer 3 VPN services
are simpler to use than Layer 2VPN services

As using Layer 3 VPN services
reduces the level of IP
routing/addressing expertise
required by the VPN customers

Layer 3 VPNs scale better thanLayer 2 VPNs
 Etc…
Etc…

平成14年10月28日

Juniper Networks, Inc. Copyright © 20023

On being pragmatic…
Layer 2 vs Layer 3 VPN comparison based ontechnology arguments is of little pragmatic relevance: Layer 3 VPN services address different market
segment than Layer 2 VPN services: Layer 3 VPN services are suitable for the VPN customers

who want to run their businesses not their networks

 outsourcing Layer 3 VPN services minimizes the need for IP

routing/addressing expertise Layer 2 VPN services are suitable for the VPN customers

who want (and capable of) full control of their Layer 3routing There is a market demand for both Layer 2 andLayer 3 VPN services
 For profit-oriented Service Providers profit
considerations dominate over technology
4
Juniper Networks, Inc. Copyright © 2002
arguments
平成14年10月28日

VPN toolkit requirements
 Support both (1) point-to-point Layer 2 VPN, (2)Virtual Private LAN Service (VPLS) and (3) IP VPNservices
 Even if a service provider presently offers only one VPN

service (e.g., Layer 2 VPN), the service provider would
benefit from the toolkit that can support expanding
service offering to other VPN services (e.g., IP VPN orVPLS) with minimum additional effort/cost to the provider

 Have as few tools as possible (but no less thanneeded to support both point-to-point Layer 2,VPLS, and IP VPN services) A single operational infrastructure and a small set of basic

tools mean cost savings in terms of: Educating the NOC staff

 Building tools/expertise to monitor VPNs
 Building tools/expertise to debug and manage the VPNs
平成14年10月28日

Juniper Networks, Inc. Copyright © 2002

5VPN toolkit requirements (cont.)
 Support large scale VPN services
 Large number of VPN customers

 Support multi-AS/multi-provider

operations

 As a particular VPN client may span more thanone AS/provider

平成14年10月28日

Juniper Networks, Inc. Copyright © 2002

6

VPN toolkit requirements – how ?
 By taking advantage of the commonalities

between point-to-point Layer 2 VPN, VPLS, andIP VPN
 e.g., auto-discovery, traffic separation, etc…

 By using tools that are general and easily

extendable

 To support VPN-specific (e.g., IP VPN specific, VPLS-specific) extensions

 By using tools that have good scaling properties
 By using tools that can operate in a distributedfashion

 Including the ability to operate across multiple service

providers

平成14年10月28日

Juniper Networks, Inc. Copyright © 2002

7

平成14年10月28日

Juniper Networks, Inc. Copyright © 2002

8

BGP/MPLS VPN Toolkit - bits of history
 In the beginning…
 IP VPN services (aka RFC2547 VPN)
 RFC2547, draft-ietf-ppvnp-2547bis

 Later (re-using parts of RFC2547)…
 BGP for VPN auto-discovery
 draft-ietf-ppvpn-bgpvpn-auto Layer 2 (point-to-point) VPN services
 draft-kompella-ppvpn-l2vpn

 Most recent…
 Virtual Private LAN Service (VPLS)
 draft-kompella-ppvpn-vpls
平成14年10月28日

Juniper Networks, Inc. Copyright © 2002

9

Terminology
VPN Site

VPN A

Provider Routers

Customer Edge

CEPPE

P

Provider Edge

VPN A

CE

PE

VPN B

CE
CE

VPN B

PE

Customer Edge device: device located on customer premises
 Provider Edge device: maintains VPN-related information,exchanges VPN information with other Provider Edge devices,
encapsulates/decapsulates VPN traffic Provider router: forwards traffic VPN-unaware

平成14年10月28日

Juniper Networks, Inc. Copyright © 2002

10VPN Control Plane functionality
 Constrained distribution of VPN information

Based on a well-established and widely used BGP Communitybased route filtering mechanism

 Exchanging demultiplexor (VPN Label) bypiggybacking it on top of the VPN information
carried by BGP

VPN Label is used for traffic separation in the forwarding
plane:
 VPN Label is attached to data by ingress PE
 Used by egress PE to determine to which VPN does a given packetbelongAlso for Layer 2 (point-to-point) VPNs, which source site does a given
packet belong
Also for VPLS, which source site has a given MAC address (used forMAC address learning) The additional overhead of carrying VPN Labels in

BGP is insignificant, yet the benefits are obvious

平成14年10月28日

Juniper Networks, Inc. Copyright © 2002

11

VPN Control Plane functionality (cont.)
 Takes advantage of all the scalability

enhancements available in BGP: Route Reflectors, Refresh, etc…

 Supports Multi-AS/Multi-provider operations
 As BGP is a protocol designed to support exchange ofinformation across multiple ASs/providers

 Piggybacking VPN Label on top of the VPN

information, and using BGP to carry botheliminates the need for a separate protocol tocarry VPN Labels
 No need to worry about scalability, multi-provider

operations, etc… of the separate protocol
 No need for complex inter-protocol interactions

平成14年10月28日

Juniper Networks, Inc. Copyright © 2002

12

Toolkit: support RFC2547 VPN
 CE-PE IP route exchange using a variety of

protocols – static, RIP, OSPF, BGP
 PE-PE route distribution using Multi-Protocol BGP(RFC 2858)
 Route Distinguisher: “uniquifies” routes
 Route Target: determines VPN topology

 VPN Routing and Forwarding table (VRF) on PE

holds all the routes for a VPN

 Both received from the local CEs and from other PEs
 Each VPN on a PE has its own VRF

 VPN labels carried by Multi-Protocol BGP(RFC3107)

 Either label per VRF, or per route

平成14年10月28日

Juniper Networks, Inc. Copyright © 2002

13

Provisioning RFC2547 VPN on a PE
 Configure RouteDistinguisher for VPN
 Configure CE-PEconnection
 Interface(s) to CE
 Layer 3 Routing Protocol

between CE and PE

RD1234:5.6.7.8

Layer 3 RIPProtocol
Imp RT

1234:8765

Exp RT

1234:8765

 Configure

import/export RouteTargets

平成14年10月28日

Juniper Networks, Inc. Copyright © 2002

14

Toolkit: Layer 2 (point-to-point) VPNs
 CE-PE: VPN Connection Table (VCT) is configured with:
 Customer Port Identifier (aka CE ID) used by the (local) CE-PE
connection
 for each local ports of that VPN

Estimated total number of customer ports within the VPN
 Analogous to CE-PE routes in RFC2547 VPNs
 PE-PE VCT distribution using Multi-Protocol BGP (RFC2858)

Route Distinguisher: “uniquifies” VCT information
 Route Target: determines VPN topology
 VPN Forwarding Table (VFT) on PE holds all the VCTs

information

Both local as well as received from other PEs
 Analogous to rfc2547 VRFs
 VPN labels carried by Multi-Protocol BGP
 Label block instead of a single label
平成14年10月28日

Juniper Networks, Inc. Copyright © 2002

15

Provisioning Layer 2 VPN on a PE
 Configure RouteDistinguisher for VPN
 Configure CE-PEconnection
 Interface to CE Layer 2 encapsulation
 Unique ID for the (local) CE

port (CE ID, aka “SiteIdentifier”)

 Configure total number ofcustomer ports in VPN(estimated)
 Configure import/export
Route Targets
平成14年10月28日

RD

1234:5.6.7.8

Layer 2
ProtocolFrame Relay

CE ID

3

# ports(# sites)

20

Imp RT

1234:8765

Exp RT

1234:8765

Juniper Networks, Inc. Copyright © 2002

16

Toolkit: VPLS CE-PE: VPN Connection Table (VCT) is configuredwith: VPLS Edge Identifier (VE ID)
 One per VPLS per PE (irrespective of how many local ports

belong to that VPLS)
 Degenerate case of Customer Port Identifier (CE ID)

 Estimated total number of PEs that have ports belonging

to that VPLS
 Analogous to CE-PE routes in RFC2547 VPNs PE-PE VCT distribution using Multi-Protocol BGP(RFC 2858)

 Route Distinguisher: “uniquifies” VCT information
 Route Target: determines VPN topology

平成14年10月28日

Juniper Networks, Inc. Copyright © 200217

Toolkit: VPLS (cont.)
 VPN Forwarding Table (VFT) on PE holds all

the VCTs information

 Both local as well as received from other PEs
 Also contains MAC forwarding information
 Created via a combination of MAC address learning andthe VCT information

 Analogous to rfc2547 VRFs

 VPN labels carried by Multi-Protocol BGP
 Label block instead of a single label
 Just like with Layer 2 (point-to-point) VPNs

平成14年10月28日

Juniper Networks, Inc. Copyright © 2002

18

Provisioning VPLS on a PE
 Remarkably similar toprovisioning for Layer
2 VPNs, except:

 Used VPLS Edge ID (VEID) instead of CE ID
 Layer 2 encapsulation isset to VPLS VPN should be a fullmeshRD

1234:5.6.7.8

Layer 2
Protocol

VPLS

VE ID

3# sites

20Imp RT

1234:8765

Exp RT

1234:8765

 Import RT always thesame as Export RT

平成14年10月28日

Juniper Networks, Inc. Copyright © 200219

Configuration Fragment for RFC2547 VPN
routing-instances vpnA { // Configuration for VPN A
instance-type vrf;// RFC 2547 VPN
route-distinguisher 1234:5.6.7.8;
route-target 1234:8765; // set Route Target to 1234:8765
protocols {// PE-CE protocol
rip {version-2;// RIPv2
group to-CE-A3 {export default;
interface so-0/0/0.0; // sub-interface for RIPv2}}}}

平成14年10月28日

Juniper Networks, Inc. Copyright © 200220

Configuration Fragment for L2 VPN
routing-instances vpnA { // Configuration for VPN A
instance-type l2vpn;// L2 VPN
route-distinguisher 1234:5.6.7.8;
route-target 1234:8765; // set Route Target to 1234:8765
protocols {// PE-CE protocol
l2vpn {
encapsulation-type frame-relay;
site CE-A3 {site-identifier 3;interface so-0/0/0.0; // sub-interface to A1
interface so-0/0/0.1; // other sub-interfaces}}}}
平成14年10月28日

Juniper Networks, Inc. Copyright © 200221

Configuration Fragment for VPLS
routing-instances vpnA { // Configuration for VPN A
instance-type l2vpn;// L2 VPN
route-distinguisher 1234:5.6.7.8;
route-target 1234:8765; // set Route Target to 1234:8765
protocols {// PE-CE protocol
l2vpn {
encapsulation-type vpls;
site CE-A3 {site-identifier 3;interface ge-0/0/0.0; // multipoint Ethernet interface}}}}

平成14年10月28日

Juniper Networks, Inc. Copyright © 2002

22

The Rest Is Up to Multi-Protocol BGP
 Allocates a VPN label (for IP VPNs) or label block(for Layer 2 and VPLS) as the demultiplexor
 Distributes BGP VPN advertisements (plus VPNlabels) with Export Route Target to other PEs
 Receives BGP VPN advertisements from all otherPEs
 Decides if received advertisement belongs togiven VPN based on Import Route Target; if so,uses this advertisement to build VRF/VFT for thisVPN

Applies to RFC2547 VPN, L2 VPN, and VPLS !!!
平成14年10月28日

Juniper Networks, Inc. Copyright © 2002

23

Inter-AS/Inter-provider operations
 Exchange VPN information + VPN labels across

AS/provider boundary by using BGP between BGP
Route Reflectors in each AS/provider
 Route Reflectors preserve the next hop information andthe VPN label across the AS/provider

PEs learn routes and label information of the PEs
in the neighboring ASes through ASBRs
 Using labeled IPv4 routes

 No VPN information (e.g., VRF, VFT) on ASBRs

Applies to RFC2547 VPN, L2 VPN, and VPLS !!!
平成14年10月28日

Juniper Networks, Inc. Copyright © 2002

24

Scalability - “divide and conquer”(1) Two levels of labels to keep P routers free of all

the VPN routing information(2) PE router has to maintain VPN information onlyfor VPNs whose sites are directly connected to thePE router(3) Partition BGP Route Reflectors within the VPN
Service Provider among VPNs served by theProvider⇒ No single component within the system isrequired to maintain information for all the VPNs
⇒ Routing capacity of the system isn’t bounded by
the capacity of an individual component

Applies to RFC2547 VPN, L2 VPN, and VPLS !!!

Overloading BGP ?
 Common concern: {public Internet +RFC2547 VPNs + L2 VPNs + VPLS} will
overload BGP, causing it to crash Real question: should a single box provide
all of the above services ?
 If so, doesn’t matter which protocol – either

the box can take it, or not Putting these services in different protocols
doesn’t reduce overall stress on the box!
 Existence proof that some boxes can take it!

平成14年10月28日

Juniper Networks, Inc. Copyright © 200226

Overloading BGP ? (cont.) Other concern: BGP is complex toimplement

 The (perceived) vendor complexity ofimplementing Multi-Protocol BGP is well worth
the greatly simplified operations for theService Providers
 Using Multi-Protocol BGP for both auto-discovery

and distributing VPN labels means fewer protocols tooperate, manage and debug

平成14年10月28日

Juniper Networks, Inc. Copyright © 2002

27

Why not BGP + LDP ?
 BGP vs LDP for signaling (distributing VPN labels) is awrong comparison
ignores the fact that VPLS includes not just signaling, but
autodiscovery – need to look at the whole system Need to compare BGP for both autodiscovery andsignaling vs BGP for autodiscovery + LDP for signaling With BGP + LDP approach signaling of VPN labels
requires a completely separate protocol (LDP) With BGP/MPLS toolkit signaling of VPN labels is a“side effect” of (BGP-based) autodiscovery
 Additional overhead of carrying labels in BGP isnegligible
 The overhead of using BGP for both autodiscovery andsignaling is about the same as using BGP just for
autodiscovery -> certainly less than using BGP forautodiscovery + LDP for signaling

平成14年10月28日

Juniper Networks, Inc. Copyright © 200228Why not BGP + LDP ? (cont.) Because using label blocks (as required for bothLayer 2 VPNs and VPLS) doesn’t introduce any
significant practical drawbacks
 BGP for auto-discovery, LDP for distributing VPNlabels
 Doesn’t work for RFC2547 VPNs – for 2547VPNs BGP

carries both VPN information and labels

 For the same reasons why BGP was extended tocarry labels, instead of using (BGP+LDP)
 Why using two protocols (BGP+LDP) to accomplish
a given task is any better than accomplishing thesame task with just one (BGP) ?

平成14年10月28日

Juniper Networks, Inc. Copyright © 2002

29

Quote From a Convinced ServiceProvider“You roll out a protocol thinking you
understand it. You spend the first year
learning how little you really understood –being paged at 3 a.m. is a wonderfuleducational tool! You then realize thatyou don’t want to do this again (or as littleas you possibly can).”

平成14年10月28日

Juniper Networks, Inc. Copyright © 2002

30

Summary
Customers want:
Point-to-point Layer 2 VPNs
 Virtual Private LAN Service (VPLS)
 IP VPNs (RFC 2547 VPN)
Service Providers can offer all of the above:over a common infrastructure (MPLS)
 with a common framework (Multi-Protocols BGP/MPLS)Taking advantage of BGP scalability and multi-AS/multiprovider support

with common concepts (Route Distinguisher, Route Target,VRF/VFTs, …)

A single operational infrastructure and a small setof basic mechanisms means considerable savings!
平成14年10月28日

Juniper Networks, Inc. Copyright © 200231

References
RFC 2547 “BGP/MPLS VPNs”• draft-ietf-ppvpn-rfc2547bis• draft-ietf-ppvpn-bgpvpn-auto• draft-kompella-ppvpn-l2vpn• draft-kompella-ppvpn-vpls•

平成14年10月28日

Juniper Networks, Inc. Copyright © 2002

32

Thank you!
http://www.juniper.net
http://www.juniper.co.jp

Juniper Networks, Inc. Copyright © 2002