idnits 2.17.1 draft-callon-nbvpn-outline-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 17 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 18 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 117 has weird spacing: '...E-Based vs N...' == Line 456 has weird spacing: '...ing and query...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group R. Callon 2 Internet Draft Juniper Networks 3 Expires: April 2001 B. Gleeson 4 Nortel Networks 5 Eric Rosen 6 Cisco Systems 7 Chandru Sargor 8 Jieyun (Jessica) Yu 9 Cosine Communications 11 Outline for A Framework for Network Based Virtual Private Networks 12 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 The work of the IETF NB-VPN working group will be aided by a working 37 group framework document. Input for such a document needs to come 38 from multiple sources, including companies involved in the major 39 proposals being developed by the working group. 41 We are intending to produce a framework document based on this 42 outline. The resulting document will discuss technical issues for 43 Network Based Virtual Private Networks (NB-VPNs). It is the intent to 44 produce a coherent description of the significant technical issues 45 which are important in the design of network based VPN solutions. 46 Selection of specific approaches, making choices regarding 47 engineering tradeoffs, and detailed protocol specification, are 48 outside of the scope of a framework document. 50 1. Introduction 52 NOTE: This is a rough draft for an outline for a working group VPN 53 framework document. It is expected that this outline will be updated 54 during the process of completing the framework document. However, we 55 also expect that agreement will be easier if we first agree on the 56 general format and most of the content for the outline, and then 57 undertake to fill in specific sections. 59 The text included in this outline is intended for the purpose of 60 giving a general idea regarding what subjects may be discussed in 61 each section. It is expected that the text included herein is likely 62 to be re-written and/or taken from other documents. Note that in many 63 cases the text in this outline will consist of only brief bullet 64 items, which will list the general topics which are likely to be 65 discussed in each section. 67 With the exception of brief introductory material, the scope of this 68 outline is limited to Network Based Layer 3 VPNs. This implies VPNs 69 for which the provider network participates in layer 3 forwarding, 70 and in routing and management of the VPN, as defined below. CPE-based 71 VPNs are outside the scope this document. This scope is selected to 72 match the anticipated scope of the IETF NB-VPN working group. If the 73 scope of the working group is wider than anticipated, then the scope 74 of this outline may be extended accordingly. 76 This document does not make choices, but rather describes issues, 77 technology, and the possible solutions to each problem. We will 78 therefore describe multiple possible solutions which may be used. 80 This document does not describe any specific complete solution. Note 81 that any specific solution will need to make choices, and will need 82 to make tradeoffs between flexibility and conciseness. Also note that 83 the requirements for VPNs will vary between different applications, 84 and therefore there may be a need for multiple different solutions 85 for use in different situations. 87 1.1 Overview of Virtual Private Networks 89 The intention of this and the following sections is to introduce the 90 main characteristics of VPNs, and to specify what is in/out of scope 91 for this document (which is intended to match the scope of the WG). 92 The intention is to only briefly discuss each of the items listed 93 below, and refer to later sections where appropriate. 95 VPNs 97 - private networks 98 - interconnected over a public infrastructure (note: To some extent 99 this is true of frame relay, ATM, and even ADM networks; Thus it is 100 not clear how "unique" this definition really is.). 101 - show picture. Define "provider edge (PE)" and "customer premise 102 edge (CPE)". 103 - Private addresses in the private network implies 104 encapsulation/tunneling (of some sort, unless there are separate 105 physical links) 106 - Need for security 107 - Need for QoS 108 - Isolation between VPNs - separate routing/forwarding tables per vpn 109 (at the PE gear, the input port implicitly creates restrictions 110 regarding where the packet can be delivered). 112 1.2 Types of VPNs 114 - Many types. It is not up to this document to decide between 115 different types of VPNs. There are tradeoffs. 117 1.2.1 CPE-Based vs Network-Based VPNs 119 - CPE-Based VPNs characterized by tunnels between CPE gear. Tunnels 120 could either be link layer connections (e.g. ATM, FR) or IP in IP ( 121 IP/IP, GRE, IPSEC). Provider network unaware of the operation of IP 122 (or other network layer protocol) in the private network, just sees 123 ATM/FR frames or IP packets. 125 - Network Based VPNs - provider network participates in reachability 126 distribution and tunnel establishment (optionally also other 127 functions). Does not preclude CPE to CPE tunnels, but these are set 128 up with the involvement of the provider network. 130 - Note that these definitions actually could overlap (if the provider 131 manages CPE gear). A clearer distinction is whether a VPN is layer 3, 132 as discussed in section 1.2.4 below. 134 1.2.2 Types of Network Based VPNs 136 Different types of network based VPNs may be distinguished by the 137 service offered. 139 - Multi-site Layer 3 service - provider forwards packets based on 140 layer 3 information (in scope) 141 - Multi-site Layer 2 service - (transparent LAN service) - 142 provider forwards packets based on MAC address (out of scope) 143 - Link Concatenation (VLL) - provider forwards packets on the 144 basis on the incoming link on which the packet was received (out 145 of scope) 147 1.2.3 Network Based Layer 2 VPNs 149 - Network is aware of VPN, but does only level 2 forwarding. Options 150 include forwarding based on MAC addresses, use of pt-to-pt link layer 151 connections, multipoint-to-pt (e.g merged MPLS LSPs), pt-to- 152 multipoint (e.g. ATM VCCs) etc. 154 1.2.4 Network Based Layer 3 VPNs 156 - What this is: Network layer forwarding in the carrier (specifically 157 in PE gear). Network is aware of the VPN (for example, it forwards L3 158 packets for the private network, and may participate in routing, 159 configuration / discovery) 161 - How this differs from CPE based VPNs and network based layer 2 VPNs 163 - Given that PE gear needs to forward packets directly from the 164 private network, using the private network's address space, this 165 implies that PE gear needs to participate in some manner in routing 166 for as many private networks as the PE gear supports (refer to later 167 sections). Basically this moves some functions from the private 168 network to the public network. 170 - "Network Connectivity Service" versus "Full Network Service". 171 Former provides constrained connectivity at layer 3. Latter may 172 include other network services such as firewalls, user authentication 173 and address assignment (e.g. RADIUS, DHCP) etc. 175 - Note: As an example, a layer 3 VPN may support constrained 176 connectivity, so that a single site may be in multiple VPNs, so that 177 to go from site 1 to site 3 you might have to traverse site 2. This 178 would for example make sense where the firewall is in site 2. We 179 don't intend to talk about how the firewall works, but will talk 180 about how a VPN could support constrained connectivity. Similarly 181 there could be NAT boxes between overlapping private address spaces 182 in different private networks, which would most likely provider 183 constraints similar to the firewalls, in that routing between two 184 sites may need to traverse a third site. 186 1.3 Terminology 188 1.4 Acronyms 190 BGP Border Gateway Protocol 191 CE Customer Edge 192 CoS Class of Service 193 CPE Customer Premise Equipment CR-LDP ?? 194 FEC Forwarding Equivalence Class 195 GRE Generic R?? Encapsulation 196 IETF Internet Engineering Task Force 197 IGP Interior Gateway Protocol (eg, RIP, IS-IS and OSPF 198 are all IGPs) 199 IP Internet Protocol (same as IPv4) 200 IPsec Internet Protocol Security protocol 201 IPv4 Internet Protocol version 4 (same as IP) 202 IPv6 Internet Protocol version 6 203 IS-IS Intermediate-System to Intermediate System routing 204 protocol 205 L2TP Layer 2 Tunneling Protocol 206 LAN Local Area Network 207 LDP Label Distribution Protocol 208 LSP Label Switched Path 209 MIB Management Information Base 210 MPLS Multi-Protocol Label Switching 211 NBMA Non-Broadcast Multi-Access 212 NMS Network Management System 213 OSPF Open Shortest Path First routing protocol 214 P Provider equipment 215 PE Provider-Edge equipment 216 PHP Penultimate-Hop Popping 217 PPTP Point-to-Point Tunneling Protocol 218 QoS Quality of Service 219 RFC Request for Comments 220 RIP Routing Information Protocol 221 RSVP Resource Reservation Protocol 222 RSVP-TE Resource Reservation Protocol with Traffic 223 Engineering extensions 224 VLAN Virtual Local Area Network 225 VPN Virtual Private Network 226 VR Virtual Router 227 VRF Virtual Routing and Forwarding instance 229 2. A Brief Overview of Requirements 231 Note: Generally, we expect that detailed requirements should go into 232 a separate document, and our understanding is that there is a 233 separate effort in the IETF VPN working group to define requirements. 234 This section will therefore be very brief. 236 - reference requirements document in progress 237 - list requirements quickly, this includes: 238 - ease of management (this is somewhat subjective, but is 239 important) 240 - tunneling (to support private addressing) 241 - multiplexing (multiple tunnels; implicit if over IP; explicit if 242 over MPLS) 243 - security / privacy 244 - scaling 245 - in size of each VPN, number of VPNs, and in bandwidth; Number 246 of VPNs and Size of primary concern 247 - of the public network 248 - of each private network 249 252 - QoS support and SLA support 253 - intranets and extranets 255 Note: There is an issue regarding how much we want to say in this 256 section. There is a lot which could be added. However, it is probably 257 more appropriate to keep this very short, on the basis that the more 258 complete description of requirements will be in a separate document. 260 3. Functional Components of a VPN 262 Basic functional components: 264 1. A mechanism to discover and distribute VPN membership/capability 265 information 266 2. A mechanism to tunnel traffic among VPN sites 267 3. A means to exchange and maintain the private routes pertaining to 268 the VPN sites connected to it and reachability information for the 269 public backbone to be able to forward data from the VPN sites over 270 the backbone. 272 - Control plane (for setting up VPNs) 273 - Routing plane (for routing within a VPN) 274 - Data plane 276 Tunnels for data might or might not also be used for routing. 278 Note: We are not sure whether or not we will need to add a functional 279 decomposition internal to a PE. If this is needed to aid discussion 280 in the Routing or other sections to follow, then this can be added 281 here. 283 4. Customer Interface - Services and Protocols 285 This section to discuss the service and protocols required at the 286 CE/PE boundary. Includes the protocols used, and what the provider 287 part of the network looks like in routing terms to the customer. 289 4.1 Customer view of Routing in the Private Network 291 - Uses normal IP routing. On a basic level, for a classic level 3 292 VPN, the customer does not see the VPN at all -- it looks like normal 293 network equipment. This implies that the customer sees a bunch of 294 routers, which need to be interconnected just like any old routers. 295 The customer expects that the quality of service and routing 296 capabilities of the VPN will be the same or very similar to other 297 network equipment. EXCEPT for the n-squared issue (see below). 299 - Virtual Forwarding Instances (brief introduction). 301 4.1.1 Options for Routing for Intranets 303 - Options for routing are therefore the same as is found in any 304 private network: One area IGP (RIP, OSPF, IS-IS, or proprietary); 305 Hierarchical IGP. IGP within each site, and BGP or static routing 306 between sites. 308 - Is PE router (or VFI within PE router) a part of the site? If an 309 IGP is used within the site, and static route between sites, is the 310 static route between CE and PE (probably). If BGP, maybe and maybe 311 not. 313 4.1.2 Options for Routing for Extranets 315 . 317 4.1.3 Customer Edge and Provider Edge equipment 319 - Above discussion is from the perspective of how routing is done on 320 an overall basis in a private network (eg, between sites). 322 - Is the PE box in a site or not? 323 - for one-area solution, the point is mute (everything is in the 324 same area) 325 - for multi-area or multi-domain issue, could be done either way 326 - If PE (or VFI) is part of site: More work for provider, less work 327 for private network 328 - If CE is border router: more control for customer. 330 4.1.4 Routing Across a Full N-Squared Mesh 332 Note: This section looks at routing from the perspective of the 333 customer network. If the customer has "n" sites, then from the 334 customer's perspective the n sites need to be interconnected and 335 routing has to work between the n sites. Solutions which are specific 336 to PE to PE operation within an VPN solution will be discussed in 337 section 7. 339 There are a range of possible customer views of routing in the 340 private network. With one approach the customer only sees routing 341 within a single site, and a link (or a small number of links) to a 342 public network. With this approach there is no issue in the private 343 network with a view of "n-squared" links between n sites. Similarly, 344 in many cases the connectivity between sites may be limited. For 345 example, there may be a small number of core sites (one or more), and 346 each other site might be attached only to one or two core sites. 347 Finally, in many cases the number n of sites is small enough that n- 348 squared is still a moderate number. There are therefore a number of 349 cases in which there is no problem with the appearance of n-squared 350 links between n sites. 352 When n sites are fully connected between a large number of sites, 353 then it will look to the customer as if the topology is very richly 354 branched across the VPN links. How is this handled? How do you route 355 efficiently over the n-squared mesh? 357 Note that this same issue comes up in other networks. For example, 358 where multiple routers are interconnected over a frame relay or ATM 359 subnet. Standard IP routing protocols have therefore developed ways 360 to deal with this issue. 362 - discuss how this works with BGP, OSPF, and IS-IS. 364 - clarity PE versus CE issue (if entire topology is seen in private 365 network, all are routers and it doesn't matter. Else there probably 366 is no n-squared issue). 368 - Scaling may vary with routing approach -- since different private 369 networks have different sizes, this is one of many reasons why 370 multiple approaches to VPNs are needed. 372 4.2 Quality of Service 374 - QoS / SLAs 376 4.3 Visibility into the Provider Network 378 - The provider hosted part of the network may be opaque or 379 transparent. (May appear as a separate domain with no visibility into 380 internal structure, or customer may be able to log into all "virtual" 381 routers and modify parameters, add routes etc) 383 4.4 Carrier's Carrier 385 We have not yet decided whether a "carrier's Carrier" service should 386 be included. If so, then a discussion may go here. 388 5. VPN Establishment and Maintenance 390 VPN establishment and maintenance is a very important part of any 391 solution for VPNs, and therefore is suggested as the first section of 392 the "how does the carrier actually solve the problem" discussion. 394 This section covers the issues and mechanisms used for the 395 establishment and maintenance of VPNs. There are two aspects of this 396 - the information distributed, and the mechanisms used to distribute 397 the information. 399 5.1 VPN Control Plane 401 Describe what the problem is and what we are trying to accomplish. 402 Finding other parts of the VPN. Applies to both intranet and extranet 403 case. 405 Information distributed may include 407 - Membership information (which nodes have members in which VPNs - 408 used to establish the control plane topology / neighbor discovery) 410 - Tunnel end point information (used to establish tunnels for 411 control and/or data) (we need to determine what this is other than 412 membership info) 414 - Topology information (full mesh / hub & spoke) 416 - Reachability scheme to use (e.g. per-vpn instance or shared 417 instance, and which protocol) 419 Mechanisms include 421 - Use BGP 423 - Use IGP (IS-IS or OSPF) 425 - Use IP multicast 427 - Use a VPN server / directory where nodes register and query 429 - Use network management system / MIB 431 Discuss how the mechanisms used for the control, routing and data 432 planes may be combined in different ways, and how different schemes 433 may carry things out in a different order. e.g. 2547: combined 434 control and routing plane + separate data plane; 436 VR: separate control plane and combined routing and data plane; also 437 tunnels before routing for VR, tunnels after routing for 2547. 439 5.2 VPN Membership 441 Which devices need information for which VPNs? This information needs 442 to be dynamically distributed. Allows for neighbor discovery. 443 Different schemes may use this information in different ways. 445 Need to deal with 447 - Static users / sites - permanently attached to a PE via a 448 dedicated connection 449 - Dynamic users - may appear at any PE (e.g. dial users) and 450 attach to a VPN 452 Schemes may include 454 - advertising membership/interest in a vpn to peer nodes (e.g. 455 piggybacking on a routing protocol) 456 - registering and querying a directory or server with membership 457 information 459 5.3 Controlling VPN Route Distribution 461 Common problem that all schemes must address - cannot have all VPN 462 routes on all PEs. VPN membership information can be used to control 463 which devices have the routes for a particular VPN. 465 Mechanisms: 466 - route filtering (2547) 467 - controlling tunnel establishment (VR) 469 5.4 Data-Plane Topology 471 Each vpn has a data plane topology which consists of a set of nodes 472 interconnected via tunnels over which customer data traffic is sent. 473 This may range from a full mesh to a hub and spoke topology, or 474 anything in between. Different topologies may be needed for policy or 475 scaling reasons. 477 - Discuss information / mechanisms that can be used to automate 478 construction of the desired topology. 480 Tunnels across the backbone may be either 482 - shared between multiple VPNs 483 - dedicated to a specific VPN 485 Discuss scaling / QoS issues regarding this. 487 489 5.5 VPN Capabilities negotiation 491 Advertising and selection / negotiation of common routing / tunneling 492 mechanisms 494 5.6 More detailed discussion on specific control plane mechanisms 496 - BGP 497 - LDAP 498 - Network Management Systems 500 503 6.0 VPN tunneling 505 6.1 Encapsulation 507 - possible formats for encapsulation, IP in IP, GRE, IPsec, MPLS 508 (L2TP is not in scope) 510 - overhead and control mechanisms may vary. 512 - when a packet arrives it needs to be determined which VPN it 513 belongs to. In many cases any one tunnel will be associated with a 514 single VPN. The method of making this mapping will therefore depend 515 upon the method of encapsulation which is used. This could use the 516 MPLS label, the IP address (in the case of IP in IP encapsulation), 517 IPsec security association, or a VPN ID. If the latter, then 518 somewhere in a GRE header, IPsec header, or new form of encapsulation 519 a place needs to be found to put a VPN ID. 521 - Somewhere here we need to discuss scaling, in terms of the numbers 522 of tunnels. We probably mention the issue here, and give more detail 523 below. 525 6.2 Tunnel Establishment 527 - Explicit signaling to determine multiplexing value, vs distribution 528 of multiplexing value without explicit signaling (e.g. piggybacking 529 of MPLS label on some other protocol) 531 Different tunneling schemes use different methods: 533 - IPSec tunnels - advertise endpoint IP address and use IKE signaling 534 to establish the tunnel. 536 - MPLS LSP - advertise the MPLS label. Could also advertise endpoint 537 IP address and use RSVP-TE / CR-LDP to establish an LSP. 539 - IP/IP tunnels - no signaling, no multiplexing field - advertise 540 outer IP address 542 - GRE tunnels - no signaling, multiplexing field? 544 6.3 Hierarchical Tunnels 546 This section would discuss shared vs dedicated per-VPN tunnels and 547 the scaling issues involved. Some of the text below (6.4) may be 548 moved here. Hierarchy applies to both MPLS and non-MPLS tunnels. 549 Discussion of multipoint operation might also go here. 551 There might also be a new top level section "Hierarchical Tunnels" 552 (or perhaps "Tunnel Scaling") that is independent of tunnel 553 maintenance, since scaling and maintenance are separate issues. Use 554 of hierarchical tunnels appears to be primarily about scaling, but 555 may also have other features. 557 6.4 Tunnel Maintenance 559 - Generally, for each tunnel, we need to set it up, and over time 560 make sure it is still up. There may optionally be a way to remove the 561 tunnel in the rare chance that we are done. 563 - Maintenance also related to routing model used - with VR there's a 564 routing instance running over the tunnel so no tunnel specific 565 mechanisms are needed, with Aggregated this isn't the case . 567 - Tunnel maintenance may be explicit or implicit. For example, for IP 568 in IP encapsulation, if you have been told that you can encapsulate 569 in address "w.x.y.z" for a particular VPN, you might just send a 570 packet there. Similarly in some cases MPLS tunnels can be setup by 571 simply advertising the label to use for specific sets of traffic. 572 Advantages of implicit (null) maintenance: Don't need n-squared 573 protocol exchanges. Disadvantage: Tunnel might not work due to a 574 network failure. There might have been some other way around the 575 failure. Note that for some approaches n-squared adjacencies might 576 need to exist for the routing protocol anyway (see routing section). 578 - Method for tunnel maintenance will vary with encapsulation. 580 6.4.1 Maintaining IP-in-IP and/or GRE Tunnels 582 We probably want to mention that tunneling over IP might be 583 implicitly multipoint to point. If you have "n" tunnel endpoints, 584 then at any one place you need only "n" pieces of information (the IP 585 address to tunnel to that point). If we ignore routing issues (see 586 section 8 below), then this implies that the scaling is O(n). 588 6.4.2 Maintaining LSPs as tunnels 590 - Label Exchange 592 - How do you decide which VPN is mapped to which LSP? 594 For this section, I think that piggybacking labels on BGP simply 595 makes BGP one possible signaling protocol for LSPs, although perhaps 596 one that in some usages becomes useful only in the specific case that 597 you know that you have a PE to PE tunnel, and you want to multiplex 598 multiple VPN-specific tunnels inside the PE to PE tunnel. 600 With point to point tunnels between PEs, or per-VPN between PEs, the 601 scaling would be O(n-squared). If a single level of tunnel is used, 602 each VPN-specific, and if tunnels are point to point, this could be a 603 lot of tunnels. This would be a problem for large networks (hundreds 604 of PEs). This problem can be solved through two compatible 605 mechanisms: 607 - Use hierarchical LSPs: VPN-specific tunnels can be multiplexed 608 inside PE-PE tunnels. 610 - Multipoint to point tunnels: The PE to PE tunnels can be multipoint 611 to point. This implies that if we have "n" PEs, then there are only 612 "n" LSPs within the core of the network. While each LSP could be 613 relatively complex (in that it has multiple branches), nonetheless on 614 each link there are only a maximum of n LSPs, and at each node in the 615 network the total amount of information is proportional to n times 616 the number of direct neighbors (ie, number of links * n is an upper 617 bound on information). 619 - VPN-specific tunnels which are multiplexed inside the PE to PE 620 tunnels can also either point to point or multipoint to point. If the 621 latter, then the amount of information for each ingress PE is 622 proportional to the number of VPNs that it supports times the number 623 of places that each VPN needs to send traffic. The amount of 624 information for each egress PE is proportional to the number of VPNs 625 that it supports. This is of course a minimal amount of information 626 which is needed by any solution. (note, also see routing scaling, 627 below). 629 6.4.3 Maintaining IPsec Associations as Tunnels 631 6.5 Multiplexing 633 636 7. Routing for VPNs Across the Public Network 638 - This refers to carrying of Private VPN routing information across 639 the public network. 641 7.1 Virtual Forwarding Instances 643 - PE routers may end up supporting a large number of VPNs, and 644 therefore a large number of routing instances. This makes scaling 645 hard in PE routers. On the other hand, the resource load on a 646 particular PE is largely linearly proportional to the number of VPNs 647 that the PE router supports, and to the size of the VPNs. 649 - Note that with any Network Based VPN, the PE gear is involved in 650 routing for the private networks that it supports. This implies that 651 scaling of the PE gear will by definition be no better than 652 proportional to the number of VPNs which the PE supports times the 653 average size of the VPNs. 655 7.2 Virtual Routers 657 - Route across the tunnels, and treat them as normal interfaces. 658 - as point to point tunnels 659 - as an NBMA network 660 - as a broadcast/multicast network 661 - Refer to overlay routing 662 - Since we are routing across the tunnels, failure of the tunnels is 663 detected by the routing protocols. 665 7.3 Aggregated Routing Model 667 Aggregated routing means one routing instance is used to carry routes 668 of many or all the VPNs supported by the PEs. This implies that 669 routing needs to be separated from data forwarding (the tunnels are 670 used for data forwarding). This model routing may be piggybacked on a 671 common routing protocol used for multiple VPNs, possibly involving 672 BGP. 674 The common routing protocol can be either the same protocol and 675 instance used for SP network routing, or a different routing 676 instance. 678 - Could use IGP or a BGP. Problems with IGP (OSPF or IS-IS implies 679 flooding all information throughout area). BGP allows separation of 680 information. 682 - Since we are not routing across the tunnels, other means are needed 683 to ensure that if the tunnels fail then either the tunnels are 684 rapidly re-constructed, or routing within the private network 685 responds. 687 7.3.1 Aggregated Routing with OSPF or IS-IS 689 - Link state protocols broadcast routing info throughout an area 691 - This is a problem (wrong way to distribute VPN routing 692 information). Scaling implications. 694 7.3.2 Aggregated Routing with BGP 696 - Flexibility regarding where information goes. 698 7.3.3 Managing PE to PE Backbone Networks 700 7.3.4 Partitioning of Routing Information with BGP 702 - May have separate set of route reflectors for Internet and VPN 703 routes 705 - May partition VPN routes among route reflectors 707 7.4 Inter-Domain Routing and Route Aggregation 709 This refers to dealing with VPNs which span multiple carrier routing 710 domains, and the routing implications thereof. 712 7.5 Header Lookups in the VFIs 714 - VFIs may (under the most straightforward implementation) have to do 715 more than one header lookup. Depending upon how the tunneling is 716 done, there could be several. Ways to reduce this are in the 717 following sections. 719 7.6 Penultimate Hop Popping for MPLS 720 - How PHP reduces header lookups. 722 - Situations in which you can or can't use this. 724 7.7 Demultiplexing to Eliminate the Tunnel Egress VFI Lookup 726 - How this might be done 727 - Using MPLS 728 - FECs for each LSP is mapped to the next hop 729 - Requires more LSPs, but less forwarding lookups. this is a 730 straightforward engineering tradeoff of resources (which resource 731 would be rather use). 733 - This can also be done with other encapsulations. This uses more 734 instances / values of the 'multiplexing' field, whatever that is. 736 8. QoS and IP Differentiated Services 738 8.1 QoS in the Public Network 740 - VPNs may use Diff Serve, as one way to obtain the QoS which is 741 desired in the VPN. 742 - Bandwidth guarantees for LSPs 744 8.2 Mapping QoS from the Private to Public Network 746 - IP Diff Serve, as used in the VPN, may be mapped to IP Diff Serve 747 across the carrier network. 749 9. Security Issues 751 Note: We need to think hard about this section: This is an important 752 issue for VPNs. Again in a framework document we only discuss 753 possible solutions and their tradeoffs, we don't pick any solution. 755 9.1 Security of User Data 757 - Need for authentication and/or encryption. 759 - Need to protect against spoofing (sending traffic which is alleged 760 to come from inside the private network), and denial of service 761 attacks. 766 - CPE to CPE (is this and also host to host outside of the scope of 767 the working group? At least it should probably be listed as a 768 possibility) 770 - PE to PE protection (encryption and/or authentication) does not 771 protect CE to PE link, but protects data between PEs. 773 9.2 Security of Routing Information 775 If overlay routing (with VRs and tunnels) then is tied to security of 776 the tunnels, which is the same as the security of the user data. With 777 aggregated model, is tied to security of a single instance of routing 778 information. In both cases we also depend on the security of the PEs 779 (assuming that if a PE is compromised then VRs within the PE will 780 also be compromised). 782 For both models, routing information is exchanged across the CE-PE 783 boundary. We need to consider whether this is another possible hole. 785 We should also discuss the impact of configuration errors. It is not 786 clear a priori whether this is the same or different with the 787 different approaches (we will need to work this out in detail). 789 9.3 Security of Membership Information 791 10. Interoperability 793 - It is likely that interoperability of any one VPN solution is based 794 on the completeness of the standard, and as such is outside of the 795 scope of the framework document. 797 - Interoperability between different VPN solutions might be discussed 798 here. 800 11. Intellectual Property 802 TBD. 804 12. Authors' Addresses 806 Ross Callon 807 Juniper Networks 808 1194 N. Mathilda Avenue, 809 Sunnyvale, CA 94089 810 +1-978-692-6724 811 E-mail: rcallon@juniper.net 813 Bryan Gleeson 814 Nortel Networks 815 2305 Mission College Blvd 816 Santa Clara CA 95054 817 +1-408-565-2625 818 E-mail bgleeson@shastanets.com 820 Eric C. Rosen 821 Cisco Systems, Inc. 822 250 Apollo Drive 823 Chelmsford, MA, 01824 824 +1-978-244-8918 825 E-mail: erosen@cisco.com 827 Chandru Sargor 828 Cosine Communications 829 1200 Bridge Parkway 830 Redwood City, CA 94065 831 +1-650-637-2416 832 Email: Chandramouli.Sargor@cosinecom.com 834 Jieyun Jessica Yu 835 Cosine Communications 836 1200 Bridge Parkway 837 Redwood City 838 CA 94065 839 Tel: (650) 628-4881 840 Email: jyy@cosinecom.com 842 13. References 844 tbd.