Internet Draft
Network Working Group                                         R. Callon
Internet Draft                                         Juniper Networks
Expires: April 2001                                          B. Gleeson
                                                        Nortel Networks
                                                             Eric Rosen
                                                          Cisco Systems
                                                         Chandru Sargor
                                                    Jieyun (Jessica) Yu
                                                  Cosine Communications


   Outline for A Framework for Network Based Virtual Private Networks
                  <draft-callon-nbvpn-outline-00.txt>


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

   The work of the IETF NB-VPN working group will be aided by a working
   group framework document. Input for such a document needs to come
   from multiple sources, including companies involved in the major
   proposals being developed by the working group.

   We are intending to produce a framework document based on this
   outline. The resulting document will discuss technical issues for
   Network Based Virtual Private Networks (NB-VPNs). It is the intent to
   produce a coherent description of the significant technical issues
   which are important in the design of network based VPN solutions.
   Selection of specific approaches, making choices regarding



Callon, et al.     draft-callon-NBVPN-outline-00.txt            [Page 1]





Internet Draft     Outline for A Framework for NBVPN      November, 2000


   engineering tradeoffs, and detailed protocol specification, are
   outside of the scope of a framework document.

1. Introduction

   NOTE: This is a rough draft for an outline for a working group VPN
   framework document. It is expected that this outline will be updated
   during the process of completing the framework document. However, we
   also expect that agreement will be easier if we first agree on the
   general format and most of the content for the outline, and then
   undertake to fill in specific sections.

   The text included in this outline is intended for the purpose of
   giving a general idea regarding what subjects may be discussed in
   each section. It is expected that the text included herein is likely
   to be re-written and/or taken from other documents. Note that in many
   cases the text in this outline will consist of only brief bullet
   items, which will list the general topics which are likely to be
   discussed in each section.

   With the exception of brief introductory material, the scope of this
   outline is limited to Network Based Layer 3 VPNs. This implies VPNs
   for which the provider network participates in layer 3 forwarding,
   and in routing and management of the VPN, as defined below. CPE-based
   VPNs are outside the scope this document. This scope is selected to
   match the anticipated scope of the IETF NB-VPN working group. If the
   scope of the working group is wider than anticipated, then the scope
   of this outline may be extended accordingly.

   This document does not make choices, but rather describes issues,
   technology, and the possible solutions to each problem. We will
   therefore describe multiple possible solutions which may be used.

   This document does not describe any specific complete solution. Note
   that any specific solution will need to make choices, and will need
   to make tradeoffs between flexibility and conciseness. Also note that
   the requirements for VPNs will vary between different applications,
   and therefore there may be a need for multiple different solutions
   for use in different situations.

1.1 Overview of Virtual Private Networks

   The intention of this and the following sections is to introduce the
   main characteristics of VPNs, and to specify what is in/out of scope
   for this document (which is intended to match the scope of the WG).
   The intention is to only briefly discuss each of the items listed
   below, and refer to later sections where appropriate.




Callon, et al.     draft-callon-NBVPN-outline-00.txt            [Page 2]





Internet Draft     Outline for A Framework for NBVPN      November, 2000


   VPNs

   - private networks
   - interconnected over a public infrastructure (note: To some extent
   this is true of frame relay, ATM, and even ADM networks; Thus it is
   not clear how "unique" this definition really is.).
   - show picture. Define "provider edge (PE)" and "customer premise
   edge (CPE)".
   - Private addresses in the private network implies
   encapsulation/tunneling (of some sort, unless there are separate
   physical links)
   - Need for security
   - Need for QoS
   - Isolation between VPNs - separate routing/forwarding tables per vpn
   (at the PE gear, the input port implicitly creates restrictions
   regarding where the packet can be delivered).

1.2 Types of VPNs

   - Many types. It is not up to this document to decide between
   different types of VPNs. There are tradeoffs.

1.2.1 CPE-Based  vs  Network-Based VPNs

   - CPE-Based VPNs characterized by tunnels between CPE gear. Tunnels
   could either be link layer connections (e.g. ATM, FR) or IP in IP (
   IP/IP, GRE, IPSEC). Provider network unaware of the operation of IP
   (or other network layer protocol) in the private network, just sees
   ATM/FR frames or IP packets.

   - Network Based VPNs - provider network participates in reachability
   distribution and tunnel establishment (optionally also other
   functions). Does not preclude CPE to CPE tunnels, but these are set
   up with the involvement of the provider network.

   - Note that these definitions actually could overlap (if the provider
   manages CPE gear). A clearer distinction is whether a VPN is layer 3,
   as discussed in section 1.2.4 below.

1.2.2 Types of Network Based VPNs

   Different types of network based VPNs may be distinguished by the
   service offered.

      - Multi-site Layer 3 service - provider forwards packets based on
      layer 3 information (in scope)
      - Multi-site Layer 2 service - (transparent LAN service) -
      provider forwards packets based on MAC address (out of scope)



Callon, et al.     draft-callon-NBVPN-outline-00.txt            [Page 3]





Internet Draft     Outline for A Framework for NBVPN      November, 2000


      - Link Concatenation (VLL) - provider forwards packets on the
      basis on the incoming link on which the packet was received (out
      of scope)

1.2.3 Network Based Layer 2 VPNs

   - Network is aware of VPN, but does only level 2 forwarding. Options
   include forwarding based on MAC addresses, use of pt-to-pt link layer
   connections, multipoint-to-pt (e.g merged MPLS LSPs), pt-to-
   multipoint (e.g. ATM VCCs) etc.

1.2.4 Network Based Layer 3 VPNs

   - What this is: Network layer forwarding in the carrier (specifically
   in PE gear). Network is aware of the VPN (for example, it forwards L3
   packets for the private network, and may participate in routing,
   configuration / discovery)

   - How this differs from CPE based VPNs and network based layer 2 VPNs

   - Given that PE gear needs to forward packets directly from the
   private network, using the private network's address space, this
   implies that PE gear needs to participate in some manner in routing
   for as many private networks as the PE gear supports (refer to later
   sections). Basically this moves some functions from the private
   network to the public network.

   - "Network Connectivity Service" versus "Full Network Service".
   Former provides constrained connectivity at layer 3. Latter may
   include other network services such as firewalls, user authentication
   and address assignment (e.g. RADIUS, DHCP) etc.

   - Note: As an example, a layer 3 VPN may support constrained
   connectivity, so that a single site may be in multiple VPNs, so that
   to go from site 1 to site 3 you might have to traverse site 2. This
   would for example make sense where the firewall is in site 2. We
   don't intend to talk about how the firewall works, but will talk
   about how a VPN could support constrained connectivity. Similarly
   there could be NAT boxes between overlapping private address spaces
   in different private networks, which would most likely provider
   constraints similar to the firewalls, in that routing between two
   sites may need to traverse a third site.

1.3 Terminology

1.4 Acronyms

   BGP             Border Gateway Protocol



Callon, et al.     draft-callon-NBVPN-outline-00.txt            [Page 4]





Internet Draft     Outline for A Framework for NBVPN      November, 2000


   CE              Customer Edge
   CoS             Class of Service
   CPE             Customer Premise Equipment CR-LDP  ??
   FEC             Forwarding Equivalence Class
   GRE             Generic R?? Encapsulation
   IETF            Internet Engineering Task Force
   IGP             Interior Gateway Protocol (eg, RIP, IS-IS and OSPF
                   are all IGPs)
   IP              Internet Protocol (same as IPv4)
   IPsec           Internet Protocol Security protocol
   IPv4            Internet Protocol version 4 (same as IP)
   IPv6            Internet Protocol version 6
   IS-IS           Intermediate-System to Intermediate System routing
   protocol
   L2TP            Layer 2 Tunneling Protocol
   LAN             Local Area Network
   LDP             Label Distribution Protocol
   LSP             Label Switched Path
   MIB             Management Information Base
   MPLS            Multi-Protocol Label Switching
   NBMA            Non-Broadcast Multi-Access
   NMS             Network Management System
   OSPF            Open Shortest Path First routing protocol
   P               Provider equipment
   PE              Provider-Edge equipment
   PHP             Penultimate-Hop Popping
   PPTP            Point-to-Point Tunneling Protocol
   QoS             Quality of Service
   RFC             Request for Comments
   RIP             Routing Information Protocol
   RSVP            Resource Reservation Protocol
   RSVP-TE         Resource Reservation Protocol with Traffic
                   Engineering extensions
   VLAN            Virtual Local Area Network
   VPN             Virtual Private Network
   VR              Virtual Router
   VRF             Virtual Routing and Forwarding instance

2. A Brief Overview of Requirements

   Note: Generally, we expect that detailed requirements should go into
   a separate document, and our understanding is that there is a
   separate effort in the IETF VPN working group to define requirements.
   This section will therefore be very brief.

   - reference requirements document in progress
   - list requirements quickly, this includes:
      - ease of management (this is somewhat subjective, but is



Callon, et al.     draft-callon-NBVPN-outline-00.txt            [Page 5]





Internet Draft     Outline for A Framework for NBVPN      November, 2000


      important)
      - tunneling (to support private addressing)
      - multiplexing (multiple tunnels; implicit if over IP; explicit if
      over MPLS)
      - security / privacy
      - scaling
         - in size of each VPN, number of VPNs, and in bandwidth; Number
         of VPNs and Size of primary concern
         - of the public network
         - of each private network
           
      - QoS support and SLA support
      - intranets and extranets

   Note: There is an issue regarding how much we want to say in this
   section. There is a lot which could be added. However, it is probably
   more appropriate to keep this very short, on the basis that the more
   complete description of requirements will be in a separate document.

3. Functional Components of a VPN

   Basic functional components:

   1. A mechanism to discover and distribute VPN membership/capability
   information
   2. A mechanism to tunnel traffic among VPN sites
   3. A means to exchange and maintain the private routes pertaining to
   the VPN sites connected to it and reachability information for the
   public backbone to be able to forward data from the VPN sites over
   the backbone.

   - Control plane (for setting up VPNs)
   - Routing plane (for routing within a VPN)
   - Data plane

   Tunnels for data might or might not also be used for routing.

   Note: We are not sure whether or not we will need to add a functional
   decomposition internal to a PE. If this is needed to aid discussion
   in the Routing or other sections to follow, then this can be added
   here.

4.  Customer Interface - Services and Protocols

   This section to discuss the service and protocols required at the
   CE/PE boundary. Includes the protocols used, and what the provider



Callon, et al.     draft-callon-NBVPN-outline-00.txt            [Page 6]





Internet Draft     Outline for A Framework for NBVPN      November, 2000


   part of the network looks like in routing terms to the customer.

4.1 Customer view of Routing in the Private Network

   - Uses normal IP routing. On a basic level, for a classic level 3
   VPN, the customer does not see the VPN at all -- it looks like normal
   network equipment. This implies that the customer sees a bunch of
   routers, which need to be interconnected just like any old routers.
   The customer expects that the quality of service and routing
   capabilities of the VPN will be the same or very similar to other
   network equipment. EXCEPT for the n-squared issue (see below).

   - Virtual Forwarding Instances (brief introduction).

4.1.1 Options for Routing for Intranets

   - Options for routing are therefore the same as is found in any
   private network: One area IGP (RIP, OSPF, IS-IS, or proprietary);
   Hierarchical IGP. IGP within each site, and BGP or static routing
   between sites.

   - Is PE router (or VFI within PE router) a part of the site? If an
   IGP is used within the site, and static route between sites, is the
   static route between CE and PE (probably). If BGP, maybe and maybe
   not.

4.1.2 Options for Routing for Extranets

   .

4.1.3 Customer Edge and Provider Edge equipment

   - Above discussion is from the perspective of how routing is done on
   an overall basis in a private network (eg, between sites).

   - Is the PE box in a site or not?
      - for one-area solution, the point is mute (everything is in the
      same area)
      - for multi-area or multi-domain issue, could be done either way
   - If PE (or VFI) is part of site: More work for provider, less work
   for private network
   - If CE is border router: more control for customer.

4.1.4 Routing Across a Full N-Squared Mesh

   Note: This section looks at routing from the perspective of the
   customer network. If the customer has "n" sites, then from the
   customer's perspective the n sites need to be interconnected and



Callon, et al.     draft-callon-NBVPN-outline-00.txt            [Page 7]





Internet Draft     Outline for A Framework for NBVPN      November, 2000


   routing has to work between the n sites. Solutions which are specific
   to PE to PE operation within an VPN solution will be discussed in
   section 7.

   There are a range of possible customer views of routing in the
   private network. With one approach the customer only sees routing
   within a single site, and a link (or a small number of links) to a
   public network. With this approach there is no issue in the private
   network with a view of "n-squared" links between n sites. Similarly,
   in many cases the connectivity between sites may be limited. For
   example, there may be a small number of core sites (one or more), and
   each other site might be attached only to one or two core sites.
   Finally, in many cases the number n of sites is small enough that n-
   squared is still a moderate number. There are therefore a number of
   cases in which there is no problem with the appearance of n-squared
   links between n sites.

   When n sites are fully connected between a large number of sites,
   then it will look to the customer as if the topology is very richly
   branched across the VPN links. How is this handled? How do you route
   efficiently over the n-squared mesh?

   Note that this same issue comes up in other networks. For example,
   where multiple routers are interconnected over a frame relay or ATM
   subnet. Standard IP routing protocols have therefore developed ways
   to deal with this issue.

   - discuss how this works with BGP, OSPF, and IS-IS.

   - clarity PE versus CE issue (if entire topology is seen in private
   network, all are routers and it doesn't matter. Else there probably
   is no n-squared issue).

   - Scaling may vary with routing approach -- since different private
   networks have different sizes, this is one of many reasons why
   multiple approaches to VPNs are needed.

4.2 Quality of Service

   - QoS / SLAs

4.3 Visibility into the Provider Network

   - The provider hosted part of the network may be opaque or
   transparent. (May appear as a separate domain with no visibility into
   internal structure, or customer may be able to log into all "virtual"
   routers and modify parameters, add routes etc)




Callon, et al.     draft-callon-NBVPN-outline-00.txt            [Page 8]





Internet Draft     Outline for A Framework for NBVPN      November, 2000


4.4 Carrier's Carrier

   We have not yet decided whether a "carrier's Carrier" service should
   be included. If so, then a discussion may go here.

5. VPN Establishment and Maintenance

   VPN establishment and maintenance is a very important part of any
   solution for VPNs, and therefore is suggested as the first section of
   the "how does the carrier actually solve the problem" discussion.

   This section covers the issues and mechanisms used for the
   establishment and maintenance of VPNs. There are two aspects of this
   - the information distributed, and the mechanisms used to distribute
   the information.

5.1 VPN Control Plane

   Describe what the problem is and what we are trying to accomplish.
   Finding other parts of the VPN. Applies to both intranet and extranet
   case.

   Information distributed may include

      - Membership information (which nodes have members in which VPNs -
      used to establish the control plane topology / neighbor discovery)

      - Tunnel end point information (used to establish tunnels for
      control and/or data) (we need to determine what this is other than
      membership info)

      - Topology information (full mesh / hub & spoke)

      - Reachability scheme to use (e.g. per-vpn instance or shared
      instance, and which protocol)

   Mechanisms include

          - Use BGP

          - Use IGP (IS-IS or OSPF)

          - Use IP multicast

          - Use a VPN server / directory where nodes register and query

          - Use network management system / MIB




Callon, et al.     draft-callon-NBVPN-outline-00.txt            [Page 9]





Internet Draft     Outline for A Framework for NBVPN      November, 2000


   Discuss how the mechanisms used for the control, routing and data
   planes may be combined in different ways, and how different schemes
   may carry things out in a different order.  e.g. 2547: combined
   control and routing plane + separate data plane;

   VR: separate control plane and combined routing and data plane; also
   tunnels before routing for VR, tunnels after routing for 2547.

5.2 VPN Membership

   Which devices need information for which VPNs? This information needs
   to be dynamically distributed. Allows for neighbor discovery.
   Different schemes may use this information in different ways.

   Need to deal with

      - Static users / sites - permanently attached to a PE via a
      dedicated connection
      - Dynamic users - may appear at any PE (e.g. dial users) and
      attach to a VPN

   Schemes may include

      - advertising membership/interest in a vpn to peer nodes (e.g.
      piggybacking on a routing protocol)
      - registering and  querying a directory or server with membership
      information

5.3 Controlling VPN Route Distribution

   Common problem that all schemes must address - cannot have all VPN
   routes on all PEs. VPN membership information can be used to control
   which devices have the routes for a particular VPN.

   Mechanisms:
          - route filtering (2547)
          - controlling tunnel establishment (VR)

5.4 Data-Plane Topology

   Each vpn has a data plane topology which consists of a set of nodes
   interconnected via tunnels over which customer data traffic is sent.
   This may range from a full mesh to a hub and spoke topology, or
   anything in between. Different topologies may be needed for policy or
   scaling reasons.

   - Discuss information / mechanisms that can be used to automate
   construction of the desired topology.



Callon, et al.     draft-callon-NBVPN-outline-00.txt           [Page 10]





Internet Draft     Outline for A Framework for NBVPN      November, 2000


   Tunnels across the backbone may be either

          - shared between multiple VPNs
          - dedicated to a specific VPN

   Discuss scaling / QoS issues regarding this.

   

5.5 VPN Capabilities negotiation

   Advertising and selection / negotiation of common routing / tunneling
   mechanisms

5.6 More detailed discussion on specific control plane mechanisms

   - BGP
   - LDAP
   - Network Management Systems

   

6.0 VPN tunneling

6.1 Encapsulation

   - possible formats for encapsulation, IP in IP, GRE, IPsec, MPLS
   (L2TP is not in scope)

   - overhead and control mechanisms may vary.

   - when a packet arrives it needs to be determined which VPN it
   belongs to. In many cases any one tunnel will be associated with a
   single VPN. The method of making this mapping will therefore depend
   upon the method of encapsulation which is used. This could use the
   MPLS label, the IP address (in the case of IP in IP encapsulation),
   IPsec security association, or a VPN ID. If the latter, then
   somewhere in a GRE header, IPsec header, or new form of encapsulation
   a place needs to be found to put a VPN ID.

   - Somewhere here we need to discuss scaling, in terms of the numbers
   of tunnels. We probably mention the issue here, and give more detail
   below.

6.2 Tunnel Establishment

   - Explicit signaling to determine multiplexing value, vs distribution



Callon, et al.     draft-callon-NBVPN-outline-00.txt           [Page 11]





Internet Draft     Outline for A Framework for NBVPN      November, 2000


   of multiplexing value without explicit signaling (e.g. piggybacking
   of MPLS label on some other protocol)

   Different tunneling schemes use different methods:

   - IPSec tunnels - advertise endpoint IP address and use IKE signaling
   to establish the tunnel.

   - MPLS LSP - advertise the MPLS label. Could also advertise endpoint
   IP address and use RSVP-TE / CR-LDP to establish an LSP.

   - IP/IP tunnels - no signaling, no multiplexing field - advertise
   outer IP address

   - GRE tunnels - no signaling, multiplexing field?

6.3 Hierarchical Tunnels

   This section would discuss shared vs dedicated per-VPN tunnels and
   the scaling issues involved.  Some of the text below (6.4) may be
   moved here. Hierarchy applies to both MPLS and non-MPLS tunnels.
   Discussion of multipoint operation might also go here.

   There might also be a new top level section "Hierarchical Tunnels"
   (or perhaps "Tunnel Scaling")  that is independent of tunnel
   maintenance, since scaling and maintenance are separate issues. Use
   of hierarchical tunnels appears to be primarily about scaling, but
   may also have other features.

6.4 Tunnel Maintenance

   - Generally, for each tunnel, we need to set it up, and over time
   make sure it is still up. There may optionally be a way to remove the
   tunnel in the rare chance that we are done.

   - Maintenance also related to routing model used - with VR there's a
   routing instance running over the tunnel so no tunnel specific
   mechanisms are needed, with Aggregated this isn't the case .

   - Tunnel maintenance may be explicit or implicit. For example, for IP
   in IP encapsulation, if you have been told that you can encapsulate
   in address "w.x.y.z" for a particular VPN, you might just send a
   packet there. Similarly in some cases MPLS tunnels can be setup by
   simply advertising the label to use for specific sets of traffic.
   Advantages of implicit (null) maintenance: Don't need n-squared
   protocol exchanges. Disadvantage: Tunnel might not work due to a
   network failure. There might have been some other way around the
   failure. Note that for some approaches n-squared adjacencies might



Callon, et al.     draft-callon-NBVPN-outline-00.txt           [Page 12]





Internet Draft     Outline for A Framework for NBVPN      November, 2000


   need to exist for the routing protocol anyway (see routing section).

   - Method for tunnel maintenance will vary with encapsulation.

6.4.1 Maintaining IP-in-IP and/or GRE Tunnels

   We probably want to mention that tunneling over IP might be
   implicitly multipoint to point. If you have "n" tunnel endpoints,
   then at any one place you need only "n" pieces of information (the IP
   address to tunnel to that point). If we ignore routing issues (see
   section 8 below), then this implies that the scaling is O(n).

6.4.2 Maintaining LSPs as tunnels

   - Label Exchange

   - How do you decide which VPN is mapped to which LSP?

   For this section, I think that piggybacking labels on BGP simply
   makes BGP one possible signaling protocol for LSPs, although perhaps
   one that in some usages becomes useful only in the specific case that
   you know that you have a PE to PE tunnel, and you want to multiplex
   multiple VPN-specific tunnels inside the PE to PE tunnel.

   With point to point tunnels between PEs, or per-VPN between PEs, the
   scaling would be O(n-squared). If a single level of tunnel is used,
   each VPN-specific, and if tunnels are point to point, this could be a
   lot of tunnels. This would be a problem for large networks (hundreds
   of PEs). This problem can be solved through two compatible
   mechanisms:

   - Use hierarchical LSPs: VPN-specific tunnels can be multiplexed
   inside PE-PE tunnels.

   - Multipoint to point tunnels: The PE to PE tunnels can be multipoint
   to point. This implies that if we have "n" PEs, then there are only
   "n" LSPs within the core of the network. While each LSP could be
   relatively complex (in that it has multiple branches), nonetheless on
   each link there are only a maximum of n LSPs, and at each node in the
   network the total amount of information is proportional to n times
   the number of direct neighbors (ie, number of links * n is an upper
   bound on information).

   - VPN-specific tunnels which are multiplexed inside the PE to PE
   tunnels can also either point to point or multipoint to point. If the
   latter, then the amount of information for each ingress PE is
   proportional to the number of VPNs that it supports times the number
   of places that each VPN needs to send traffic. The amount of



Callon, et al.     draft-callon-NBVPN-outline-00.txt           [Page 13]





Internet Draft     Outline for A Framework for NBVPN      November, 2000


   information for each egress PE is proportional to the number of VPNs
   that it supports. This is of course a minimal amount of information
   which is needed by any solution. (note, also see routing scaling,
   below).

6.4.3 Maintaining IPsec Associations as Tunnels

6.5 Multiplexing

   

7. Routing for VPNs Across the Public Network

   - This refers to carrying of Private VPN routing information across
   the public network.

7.1 Virtual Forwarding Instances

   - PE routers may end up supporting a large number of VPNs, and
   therefore a large number of routing instances. This makes scaling
   hard in PE routers. On the other hand, the resource load on a
   particular PE is largely linearly proportional to the number of VPNs
   that the PE router supports, and to the size of the VPNs.

   - Note that with any Network Based VPN, the PE gear is involved in
   routing for the private networks that it supports. This implies that
   scaling of the PE gear will by definition be no better than
   proportional to the number of VPNs which the PE supports times the
   average size of the VPNs.

7.2 Virtual Routers

   - Route across the tunnels, and treat them as normal interfaces.
      - as point to point tunnels
      - as an NBMA network
      - as a broadcast/multicast network
   - Refer to overlay routing
   - Since we are routing across the tunnels, failure of the tunnels is
   detected by the routing protocols.

7.3 Aggregated Routing Model

   Aggregated routing means one routing instance is used to carry routes
   of many or all the VPNs supported by the PEs. This implies that
   routing needs to be separated from data forwarding (the tunnels are
   used for data forwarding). This model routing may be piggybacked on a
   common routing protocol used for multiple VPNs, possibly involving



Callon, et al.     draft-callon-NBVPN-outline-00.txt           [Page 14]





Internet Draft     Outline for A Framework for NBVPN      November, 2000


   BGP.

   The common routing protocol can be either the same protocol and
   instance used for SP network routing, or a different routing
   instance.

   - Could use IGP or a BGP. Problems with IGP (OSPF or IS-IS implies
   flooding all information throughout area). BGP allows separation of
   information.

   - Since we are not routing across the tunnels, other means are needed
   to ensure that if the tunnels fail then either the tunnels are
   rapidly re-constructed, or routing within the private network
   responds.

7.3.1 Aggregated Routing with OSPF or IS-IS

   - Link state protocols broadcast routing info throughout an area

   - This is a problem (wrong way to distribute VPN routing
   information). Scaling implications.

7.3.2 Aggregated Routing with BGP

   - Flexibility regarding where information goes.

7.3.3 Managing PE to PE Backbone Networks

7.3.4 Partitioning of Routing Information with BGP

   - May have separate set of route reflectors for Internet and VPN
   routes

   - May partition VPN routes among route reflectors

7.4 Inter-Domain Routing and Route Aggregation

   This refers to dealing with VPNs which span multiple carrier routing
   domains, and the routing implications thereof.

7.5 Header Lookups in the VFIs

   - VFIs may (under the most straightforward implementation) have to do
   more than one header lookup. Depending upon how the tunneling is
   done, there could be several. Ways to reduce this are in the
   following sections.

7.6 Penultimate Hop Popping for MPLS



Callon, et al.     draft-callon-NBVPN-outline-00.txt           [Page 15]





Internet Draft     Outline for A Framework for NBVPN      November, 2000


   - How PHP reduces header lookups.

   - Situations in which you can or can't use this.

7.7 Demultiplexing to Eliminate the Tunnel Egress VFI Lookup

   - How this might be done
      - Using MPLS
      - FECs for each LSP is mapped to the next hop
      - Requires more LSPs, but less forwarding lookups. this is a
      straightforward engineering tradeoff of resources (which resource
      would be rather use).

   - This can also be done with other encapsulations. This uses more
   instances / values of the 'multiplexing' field, whatever that is.

8. QoS and IP Differentiated Services

8.1 QoS in the Public Network

   - VPNs may use Diff Serve, as one way to obtain the QoS which is
   desired in the VPN.
   - Bandwidth guarantees for LSPs

8.2 Mapping QoS from the Private to Public Network

   - IP Diff Serve, as used in the VPN, may be mapped to IP Diff Serve
   across the carrier network.

9. Security Issues

   Note: We need to think hard about this section: This is an important
   issue for VPNs. Again in a framework document we only discuss
   possible solutions and their tradeoffs, we don't pick any solution.

9.1 Security of User Data

   - Need for authentication and/or encryption.

   - Need to protect against spoofing (sending traffic which is alleged
   to come from inside the private network), and denial of service
   attacks. 

   - CPE to CPE (is this and also host to host outside of the scope of
   the working group? At least it should probably be listed as a



Callon, et al.     draft-callon-NBVPN-outline-00.txt           [Page 16]





Internet Draft     Outline for A Framework for NBVPN      November, 2000


   possibility)

   - PE to PE protection (encryption and/or authentication) does not
   protect CE to PE link, but protects data between PEs.

9.2 Security of Routing Information

   If overlay routing (with VRs and tunnels) then is tied to security of
   the tunnels, which is the same as the security of the user data. With
   aggregated model, is tied to security of a single instance of routing
   information. In both cases we also depend on the security of the PEs
   (assuming that if a PE is compromised then VRs within the PE will
   also be compromised).

   For both models, routing information is exchanged across the CE-PE
   boundary. We need to consider whether this is another possible hole.

   We should also discuss the impact of configuration errors. It is not
   clear a priori whether this is the same or different with the
   different approaches (we will need to work this out in detail).

9.3 Security of Membership Information

10. Interoperability

   - It is likely that interoperability of any one VPN solution is based
   on the completeness of the standard, and as such is outside of the
   scope of the framework document.

   - Interoperability between different VPN solutions might be discussed
   here.

11. Intellectual Property

      TBD.

12. Authors' Addresses

      Ross Callon
      Juniper Networks
      1194 N. Mathilda Avenue,
      Sunnyvale, CA  94089
      +1-978-692-6724
      E-mail: rcallon@juniper.net

      Bryan Gleeson
      Nortel Networks
      2305 Mission College Blvd



Callon, et al.     draft-callon-NBVPN-outline-00.txt           [Page 17]





Internet Draft     Outline for A Framework for NBVPN      November, 2000


      Santa Clara CA 95054
      +1-408-565-2625
      E-mail bgleeson@shastanets.com

      Eric C. Rosen
      Cisco Systems, Inc.
      250 Apollo Drive
      Chelmsford, MA, 01824
      +1-978-244-8918
      E-mail: erosen@cisco.com

      Chandru Sargor
      Cosine Communications
      1200 Bridge Parkway
      Redwood City, CA 94065
      +1-650-637-2416
      Email: Chandramouli.Sargor@cosinecom.com

      Jieyun Jessica Yu
      Cosine Communications
      1200 Bridge Parkway
      Redwood City
      CA 94065
      Tel: (650) 628-4881
      Email:  jyy@cosinecom.com

   13. References

      tbd.






















Callon, et al.     draft-callon-NBVPN-outline-00.txt           [Page 18]