This work is licensed under a Creative Commons License The updated versions of the slides may be

Transcription

1 This work is licensed under a Creative Commons License The updated versions of the slides may be found on totem.info.ucl.ac.be/ BG

2 Outline Organization of the global Internet BG basics BG in large networks Interdomain traffic engineering with BG BG-based Virtual rivate Networks The VN problem rovider-provisionned BG/ MLS VNs BG/ The BG-based VNs were initially proposed in : E. osen, Y. ekhter, BG/ MLS VNs, FC2547, March 1999 They are now being developped without two IETF working groups : focusses on the provision of layer-2 VNs focusses on the provision of layer-3 VNs. We mainly discuss the layer-3 VNs in this tutorial

3 The VN problem Site2, alpha.com Site4, beta.be Site3, alpha.com Site1, beta.be Network provider Site3, beta.be Site1, alpha.com Site2, beta.be BG/ How to efficiently create one network containing the sites from alpha.com one network containing the sites from beta.be

4 What should be the goal of a good VN? A good VN service should Support multiple corporate customers in this case, the traffic from these customers should be isolated some security features should be supported to ensure that packets from public Internet can be introduced inside VN provide QoS guarantees for corporate customers typical solution is to reuse the classical mechanisms be easy to utilize and manage from the customer viewpoint from the service provider viewpoint BG/

5 The classical solution Site2, alpha.com Site4, beta.be Site1, beta.be Network providing leased lines Site3, alpha.com Site1, alpha.com Site3, beta.be BG/ Site2, beta.be rinciple Create leased lines between sites full mesh (beta.be), hub and spoke (alpha.com) topologies

6 Evaluation of the classical solution Advantage the quality of the service provided by the servic e provider is usually very good Drawbacks the number of leased lines can be high n*(n-1)/2 leased lines in total for full mesh For a VN with n sites, each router needs n-1 interfaces to obtain a full mesh Flexibility addition of a VN may require several new lines installation of leased line may require O(months) Cost can be high no statistical multiplexing on provider's backbone link costs even if no traffic is exchanged BG/

7 The I-VN problem Site2, alpha.com Site4, beta.be / 24 Site1, beta.be I-based Network provider Site3, alpha.com Site3, beta.be BG/ Site1, alpha.com / 24 Site2, beta.be / 24 How to efficiently create one network containing the sites from alpha.com one network containing the sites from beta.be When only I packets are exchanged

8 A customer-provisionned I VN Site2, alpha.com Site4, beta.be / 24 rinc iple create I tunnels from customer routers through IS drawback : configuration burden on customer routers BG/ Site1, beta.be Site1, alpha.com / 24 Site2, beta.be / 24 Site3, alpha.com Site3, beta.be

9 A customer-provisionned I-VN (2) Site2, alpha.com WAN interface : LAN interface : I Tunnels towards towards Site1, alpha.com / 24 For routing protocols used by routers of alpha.com, tunnel is considereed as a normal link between the connected routers Site3, alpha.com WAN interface : LAN interface : I Tunnels towards towards IS : / 16 Backbone routers only use this address block WAN interface : LAN interface : I Tunnels towards towards BG/

10 I Tunnels Many I tunneling protocols exist I in I tunneling can be used to carry I packets inside I packets Generic outing Encapsulation can be used to carry network layer packets inside I packets oint-to-point tunneling protocol can be used to carry frames through TC/I network Layer 2 Tunneling protocol can be used to carry frames through TC/I network ISec security (authentication/confidentiality) extensions to I also include tunneling capabilities BG/ A discussion of the various tunnels that could be used to build VNs may be found in :. Callon, M. Suzuki (Eds), A Framework for Layer 3 rovider rovisioned Virtual rivate Networks, Internet draft, <draft-ietf-l3vpnframework-00.txt>, work in progress, March 2003

11 GE Tunnel rinciple Tunnel is used to carry network layer packets Delivery I Header GE Header 32 bits Ver IHL DS Total length Identification Flags Fragment Offset TTL rotocol Checksum Source I address Destination I address C eserved Ver rotocol Type Checksum (option) eserved Tunneled acket I rotocol Value 47 is reserved to indicate that I packet carries GE-encapsulated packet rotocol Type Indicates the type of network layer packet carried by tunnel same values as Ethernet type field (0x800 for I packet) Tunneled packet may be optionally protected by Checksum in GE header Can contain any network layer packet understood by destination system that can be placed inside Ethernet frame BG/

12 Evaluation of the simple I solution Advantage Flexibility BG/ a single physical interface on each router Cost VN site can multiplex traffic to different sites on this link Drawbacks the number of tunnels can be high n*(n-1)/2 tunnels in total for full mesh For a VN with n sites, each router needs n-1 tunnels to obtain a full mesh Flexibility addition of a VN require adding new tunnels Sec urity depends on tunneling mechanism used weak with GE, better with Ipsec

13 A simple MLS-based solution Site2, alpha.com Site4, beta.be / 24 Site1, beta.be Site1, alpha.com / 24 Site2, beta.be / 24 Site3, alpha.com Site3, beta.be rinc iple Manually create LSs between customer routers from VN sites through MLS backbone BG/ This simple MLS-based solution is similar in principle to the solution used to support VN with technologies based on the label switching paradigm like ATM : Asynchronous Transfer Mode Frame elay

14 A simple MLS-based solution (2) Site2, alpha.com For routing protocols used by routers of alpha.com, LS is considered as a normal direct link between the connected routers Site3, alpha.com LAN interface : FEC /24, use label L / 24, use label L2 LAN interface : MLS backbone FEC / 24, use label L6, use label L3 BG/ Site1, alpha.com / 24 LAN interface : FEC /24, use label L /24, use label L5 Label switching table of backbone router L1 : -> North-East, O L2 : -> South-West, O L3 : -> North-West, O L4 : -> North-East, O L5 : -> North-West, O L6 : -> South-West, O

15 Evaluation of the simple MLS solution Advantages a single physical line per VN site QoS can be provided on a per-ls basis Flexibility bandwidth of each LS can be easily updated Cost statistical multiplexing is possible on MLS backbone Drawbacks MLS support routers of the VN sites must support MLS backbone routers must support MLS c onfiguration burden backbone routers must be configured for each new LS customer routers must be configured for each new site BG/

16 Outline Organization of the global Internet BG basics BG in large networks Interdomain traffic engineering with BG BG-based Virtual rivate Networks The VN problem rovider-provisionned BG/ MLS VNs BG/

17 rovider-provisionned MLS VN Objective Find a solution that is as automatic as possible for the service provider for the customers of the VN service Addition of a new site to an existing VN only the new customer router should need to be configured on the VN only a single router from the service provider should need to be configured on the provider's backbone BG/ The provider-provisionned MLS VNs are defined in FC2547 BG/MLS VNs. E. osen, Y. ekhter. March 1999.

18 rovider-provisionned MLS VN (2) rinc iple of the solution Site2, alpha.com Site2, beta.be Site1, beta.be A F Site1, alpha.com / 24 D IS backbone B E Site3, alpha.com transmission of one packet in beta.be, site1to site2 transmission of one packet in alpha.com, site1to site3 BG/

19 rovider-based MLS solution (3) BG/ Site2, alpha.com : Customer Edge router Sends normal I packets through the IS backbone to reach the other sites of its VN A router can only be attached to one or more E routers Does not know details of backbone Site1, alpha.com / 24 IS backbone E E E E : rovider Edge router Site3, alpha.com : rovider router The routers are managed by the IS and do not carry any VN specific configuration outer maintained by the IS Contains some per-vn configuration and ensures that the I packets sent by a particular VN site are delivered to the E router attached to the destination VN site

20 roblems to solve Site2, alpha.com Site2, beta.be BG/ Site1, beta.be Site1, alpha.com / 24 E1 IS backbone E2 E3 Site3, alpha.com How to forward the packets from one router to the appropriate router of the same VN? Need routing tables on, E and routers How to efficiently distribute these routing tables?

21 outing tables on the routers rinciple Each router contains one routing table with the routes belonging to its VN does not know anything about IS besides its attached E BG/ Site2, alpha.com Site1, beta.be Site1, alpha.com / 24 E1 IS backbone E2 Site2, beta.be E3 (site1),beta.be via E1 Site3, alpha.com (site3),alpha.com via E3 via E3 See Eric C. osen, Yakov ekhter, BG/MLS I VNs, Internet draft, draft-ietf-l3vpn-rfc2547bis-03.txt, October 2004, work in progress

22 outing tables on the routers rinciple routers only know how to reach the routers in their bac kbone routers do not know anything about VNs Site2, alpha.com Site2, beta.be Site1, beta.be Site1, alpha.com / 24 IS backbone E1 E3 a E2 b Site3, alpha.com b's routing table a North- West E2 West E3 North E1 North-West (via a) BG/

23 outing tables on the E routers roblem Corporate networks often use FC1918 addresses Two different VNs may use same I subnets Site1, alpha.com / 24 BG/ Site2, alpha.com Site1, beta.be E1 IS backbone E2 Site2, beta.be a b E3 Site3, alpha.com E3's possible routing table a West b South E1 West (via a) E2 South (via b) West (via E2) Where are???

24 outing tables on E routers (2) rinciple Eac h E router maintains several routing tables standard routing table one VN outing and Forwarding table (VF) per BG/ attached VN Site2, alpha.com Site1, beta.be Site1, alpha.com / 24 E1 IS backbone E2 Site2, beta.be a b E3 E3's beta.be routing table North () via E1 Site3, alpha.com E3's backbone routing table a West b South E1 West (via a) E2 South (via b) E3's alpha.com routing table North-East () / 24 via E2 via E1 The VF contains all the routes belonging to a given VN. This VF is used to forward the packets that are received inside the corresponding VN. For example, when considering E3, it will use the beta.be VF to forward a packet received on its North interface while it will use the alpha.com VF to forward a packet received on its Nort-East interfac e.

25 Distribution of the routing tables outing problem How can we correctly distribute the routing information to the, E and routers? A router must advertise its local routes to its attached E and must receive the remote routes (or a default route) from this router A E router must receive two types of routing information per VN routing information for the routes reachable through attached routers and through remote E routers For scalability reasons, a E router should only know the routing information about the VNs that it directly supports IS routing information to be able to reach other E routers A router must maintain routing information for the IS For scalability reasons, a router should not know any VN specific information BG/

26 Distribution of routing information(2) oute distribution between and E static routes both E and are configured with static routes suitable for small VN sites with a single link I I is used by the to announce the routes reachable on its local network I is used by the E to announce the routes of the same VN learned from the other E routers useful for medium VN sites with multiple links Other routing protocols OSF This is a special OSF instance between E and, not the OSF that is used inside the IS backbone ebg router uses ebg session to advertise routes to E BG/

27 Distribution of routing information(3) Site2, alpha.com E2 can reach / 24 Site1, alpha.com / 24 (site2) can reach E1 E2 E3 can reach / 24 Site3, alpha.com E3 E2 can reach (site3) c an reach In the backbone, all and E routers know IS backbone topology by using the normal IG BG/ In this example, the routes between the and the E routers can be exchanged by using any of the protoc ols discussed in the previous slide.

28 Distribution of routing information (4) BG/ Distribution of per VN routes between Es Site2, alpha.com /24 Site3, alpha.com IS backbone IBG Site1, beta.be E E IBG IBG Site2, beta.be E Site1, alpha.com / 24 rinc iple ibg full mesh between E routers routers do not need to run ibg since they do not maintain per-vn routes ibg sessions are used to redistribute the routes learned from routers to distant E routers If the IS network is large, the ibg full-mesh can be replaced by the classical ibg scaling techniques that are oute eflectors and Confederations. In the case of oute eflectors, a E would typically be client of two oute eflectors and the oute eflectors would be fully meshed. The ibg sessions used for normal Internet routing and for VNs can be the same or different. In some ISs, a different ibg distribution is used for the VNs.

29 The distribution of the VN routes by the E routers Two problems must be solved How to distribute the A and B routes for 10/ 8? How to ensure that E4 only receives B routes? 10/8 VN-A A E2 AS20 ibg 11/8 VN-A A2 10/8 VN-B B2 ibg ibg E E B3 VN-B 12/8 BG/

30 M-BG and the VN-Iv4 addresses M-BG an extension to BG that allows a BG router to advertise non-iv4 routes Iv6 I multicast VN-Iv4 The VN-Iv4 address family a method used by E routers to encode I v4 VN addresses before advertising them with M-BG a VN-Iv4 address contains an 8 bytes route distinguisher an Iv4 prefix BG considers VN-Iv4 addresses as opaque bitstring two types of route distinguishers AS:value Iaddress:value BG/ M-BG is defined in Tony Bates, avi Chandra, Dave Katz,Yakov ekhter Multiprotocol Extensions for BG-4, Internet draft, draft-ietf-idr-rfc2858bis-06.txt, 2004, work in progress

31 Controlling the distribution of VN routes How to ensure that VN-Iv4 routes only reach the E routers attached to those VNs? associate one or more route targets to each VF a route associated with T x must be distributed to all E routers that have a VF with T= x T is encoded as an BG extended community ASnumber:value Iv4address:value Control of the distribution E router knows the T supported by each of its peers and only advertises the appropriate VN-Iv4 routes or E router advertises all its VN-Iv4 routes and peers filter the received routes based on the attached T BG/ The BG Extended Community attribute is defined in : Sangli, Tappan and ekhter, BG Extended Communities Attribute, Internet draft, draft-ietf-idr-bgp-ext-communities-06.txt, work in progress, Aug Compared to the classical communities, the main advantage of the extended communities is their size. The classical communities are 32-bits wide, and a block of 2 16 values is allocated to each AS (ASX:1 to ASX:65535). If the communities were used to support VNs, an AS could only define 2 16 route target values. With extended communities, each AS can define 2 32 different route target values. The cooperative route filtering mechanism that can be used by E router to advertise to their peers the routes that they wish to receive is defined in : Chen, ekhter, Cooperative oute Filtering Capability for BG-4, Internet draft, draft-ietf-idr-route-filter-09.txt, work in progress, August 2003

32 M-BG and the VN-Iv4 addresses Example per-vn route distinguisher 10/8 VN-A BG/ A1 UDATE sent by E2 NextHop: VN-Iv4 address D:20:22 refix: / 8 oute Target (Ext.Com) Blue VN-B 10/8 B E2 ibg E ibg AS20 ibg E /8 UDATE sent by E5 NextHop: VN-Iv4 address D: 20:22 refix: / 8 oute Target (Ext.Com) Blue B3 VN-B 12/8 VN-A A2 An additional element of the FC2457 architecture that does not appear in the slides is that each E router defines, for each VN attached to the router: an import policy to specifiy, which routes received via BG or the E- protocol can be installed in the VF an export policy to specify which routes installed in the VF need to be advertised by using the E- protocol or BG Of course, those policies will depend on the route distinguishers and the route targets being used. In this example, the following import filters and import policies will be used E5 imports the ibg advertisements with extended communities blue and magenta since it has a route of VNA and VNB attached The routes with D 20:222 that are received by E5 are placed in its VN-A VF E4 does not import the BG advertisements that carry the Blue extended community since no router of VNA is attached to E4

33 M-BG and the VN-Iv4 addresses (2) 10/8 Example per-site route distinguisher VN-A A AS20 E2 ibg 11/8 VN-A A2 VN-B 10/8 B2 BG/ ibg E UDATE sent by E4 NextHop: VN-Iv4 address D: :10 refix: / 8 oute Target (Ext.Com) Magenta ibg E UDATE sent by E5 NextHop: VN-Iv4 address D: :123 refix: / 8 oute Target (Ext.Com) Magenta B3 VN-B 12/8 In this example, the following import filters and import policies will be used E5 imports the ibg advertisements with extended communities blue and magenta since it has a route of VNA and VNB attached The routes with D :10 that are received by E5 are placed in its VN-B VF E2 does not import the BG advertisements that carry the Magenta extended community since no router of VNB is attached to E2

34 Types of VN connectivity Utilization of the BG extended community attribute depends on the type of inter-sites connectivity within each supported VN Full mesh connectivity all sites are equal same route target for all sites of the VN beta.be / 24 beta.be IBG E2 E1 IBG E3 IBG beta.be BG/ In the figure above, the dotted lines show the packet flows between the routers of the beta.be VN

35 Types of VN connectivity (2) Hub & spoke connectivity two types of sites large (hub) site sends to all small (spoke) sites use hub as relay site to reach others one route targetfor Hub one route target for all spoke sites Spoke2, beta.be / 24 Hub, beta.be E2 IBG E1 IBG E3 IBG E Spoke1, beta.be BG/ Spoke3, beta.be / 24 In this example, Hub, beta.be is used as a transit router for all packets exchanged between any sites of the VN. For a discussion of the characteristics of deployed VNs, see : Satish aghunath, K.K. amakrishnan, Shivkumar Kalyanaraman, Chris Chase, "Measurement Based Characterization and rovisioning of I VNs,", Internet Measurements Conference, 2004

36 Types of VN connectivity (3) Site1, alpha.com / 24 BG/ E2 edistributes : VN beta Comm: beta_spoke,next-hop= E2 Imports routes with target : beta_hub Spoke2, beta.be / 24 Hub, beta.be E2 IBG E1 E3 edistributes VN betacomm: beta_spoke,next-hop= E3 VN alpha,comm: alpha,next-hop= E3 Imports the routes with target : beta_hub, alpha IBG E3 IBG Site3, alpha.com Spoke1, beta.be E1 edistributes to E3 and E2 the following routes VN alpha Comm: alpha,next-hop= E1 VN beta Comm: beta_hub,next-hop= E1 Imports the routes with target alpha, beta_spoke

37 Solving the forwarding problem How to forward the packets from each VN through the provider's backbone? sending pure I packets is not possible routers cannot know VN-specific routes different VNs use the same FC1918 addresses rinciple of the solution routers send normal I packets routers remain as simple as possible E routers maintain several routing tables one routing table per VN attached to E router one routing table for the IS backbone E encapsulate VN packets Common solution is to encapsulate with MLS Some ISs are using GE, L2T or ISec BG/

38 Solving the forwarding problem with MLS Spoke2, beta.be / 24 Hub, beta.be Site1, alpha.com / 24 BG/ Spoke3, beta.be / 24 E2 E1 E3 Site3, alpha.com rinciple of the solution : two levels of label one level of label is used to reach the next-hop E one level of label is used to indicate the VF to be used (and thus the outgoing ) in the egress E Spoke1, beta.be Example transmission from to in beta.be transmission from to in alpha.com

39 Distribution of labels Spoke2, beta.be / 24 Hub, beta.be Site1, alpha.com / 24 BG/ E2 LD Spoke3, beta.be / 24 E1 E3 LD Site3, alpha.com Inside IS backbone, use LD to distribute labels between and E routers each E knows the label to use to reach any E router number of labels in router depends on the number of E, and not on the number of VN sites E1 -> E2 :use label L8, port North -> E3 : use label L7, port South Spoke1, beta.be L7:West-> North-East:O... LD is the common way to distribute the labels to reach the E routers in the backbone. However, the E-E MLS LSs could also be traffic engineered tunnels established with SV-TE. Usually, the E-E MLS LS will be configured with penultimate label popping, i.e. the penultimate router will O the top label of the packet when sending the encapsulated packet to the final E router.

40 Distribution of labels (2) Spoke2, beta.be / 24 Hub, beta.be Site1, alpha.com / 24 E3 edistributes through ibg VN beta rt: beta_spoke,next-hop= E3, label:l4 VN alpha rt: alpha,next-hop= E3, label : L9 E2 IBG E1 IBG E3 IBG Site3, alpha.com Spoke1, beta.be E1 edistributes through ibg the following routes and labels VN alpha rt: alpha,next-hop= E1, label= L11 VN beta rt: beta_hub,next-hop= E1, label= L17 rinc iple use ibg to distribute VN labels between E routers BG/

41 acket flow in FC2457 VNs 10/8 With per-vn D, how does E2 reach 11/ 8? VN-A AS20 A1 E2 ibg ibg ibg E VN-A A2 A3 11/8 E4 BG/ E2 receives two routes for 20:10:11/8 20:10:11/ 8 from E4 with nexthop = (E4) 20:10:11/ 8 from E5 with nexthop = (E5) E2 selects the best route with its BG decision process and installs it inside its VN-A VF E2 may use two LSs to reach 11/ 8 via E4 and E5 In this example, we assume that the route target used by E5 is 20:10 (20 because the AS number of the IS and 10 is the number allocated by the IS for VN-A, assuming per-vn route targets)

42 acket flow in FC2457 VNs (2) 10/8 With per-site D, how does E2 reach 11/ 8? VN-A AS20 A1 E2 ibg ibg ibg E VN-A A2 A3 11/8 E4 BG/ E2 receives two routes for 11/ :123:11/ 8 from E4 with nexthop = (E4) :456:11/ 8 from E5 with nexthop = (E5) BG does not help E2 to select which route is the best, the selection is done when installing in VN-A VF E2 may use two LSs to reach 11/ 8 via E4 and E5 In this example, 123 and 456 are locally unique numbers managed by E4 and E5.

43 Backup links with FC2457 VNs 10/8 How to configure a backup link? VN-A A AS20 E2 ibg ibg E5 A2 VN-A ibg A3 11/8 E4 Backup link BG/ E4 adds localpref= 50 to route learned from A3 E4 and all routers will prefer the route via E5/A2 Failure of link A2-E5 will force E5 to withdraw its VN route towards 11/8 and the route via E4 will be used In this scenario, the convergence time in case of failure will depend on several factors : - the time to detect the failure of the E5-A2 link the best solution is clearly to detect the failure at layer1 or layer2. If the E- protocol is used to detect the failure, then it may elapse several tens of seconds before the failure is actually detect and E5 withdraws its VN- Iv4 route The type of route distinguishers used by E4 and E5 may influence the convergence time in large networks. If E4 and E5 use the same route distinguishers for the routes learned from respectively A3 and A2, then when E4 learns the D:11/8 via ibg, it will withdraw its own D:11/8 route. When link E5-A2 fails, E4 will need to advertise its own route to all E routers in the blue VN. The propagation of this advertisement may take some time. If E4 and E5 use different route distinguishers, e.g :20 and :21, then both VN-Iv4 routes will be received by all E routers attached to routers in VN-A. When installing the routes in their VF, all E routers will prefer the route with the :21 D since it has the highest localpref value. However, all E routers will always know both routes. Thus, if the route with D= :21 is withdrawn, then each E router can quickly switch to the route with D= :20 provided, of course, that there is already a LS between this E router and E4.

44 Solving the forwarding problem with tunnels Spoke2, beta.be / 24 Spoke3, beta.be / 24 Hub, beta.be Site1, alpha.com / 24 E2 E1 E3 Site3, alpha.com Spoke1, beta.be BG/ rinciple of the solution : Tunnel+ MLS one tunnel is used to reach the next-hop E one MLS label is used to indicate the VF to be used (and thus the outgoing ) in the egress E

45 Solving the forwarding problem with tunnels (2) How to the encapsulate the packets? Normal I packet E1 E3 Encapsulated packet Ver IHL ToS Total length Identification TTL rot.mls Flags Fragment Offset Checksum Normal I packet BG/ E1 I address E3 I address MLS Label TTL Ver IHL ToS Total length Identification Flags Fragment Offset TTL rotocol Checksum Source I address Destination I address ayload It is also possible to use GE tunnels to reach the egress E instead of using MLS-over-I tunnel. The MLS-over-I tunnel is described in : Tom Worster, Yakov ekhter, Eric C. osen, editor, Encapsulating MLS in I or Generic outing Encapsulation (GE), Internet draft, draft-ietf-mplsin-ip-or-gre-08.txt, 2004, Work in progress

46 Solving the forwarding problem with tunnels (3) E3 edistributes via ibg VN beta rt: beta_spoke,next-hop= E3, / 24:label:L4 VN beta rt: beta_spoke,next-hop= E3, :label:l5 VN alpha rt: alpha,next-hop= E3, label : L9 Site1, alpha.com / 24 BG/ Spoke2, beta.be / 24 Hub, beta.be Spoke3, beta.be / 24 E2 E1 E3 Site3, alpha.com Spoke1, beta.be Example transmission from to in beta.be transmission from to in alpha.com

47 Comparison of VN solutions rovider-provisionned BG/ MLS VNs Easy to configure for customer and provider rovider can provide special QoS to VN But customer routes are distributed inside the provider's network by ibg provider may need to carry a large number of routes if clients use /32, /30 or /28 subnets some ISs report BG/ MLS VN tables larger than the BG tables of backbone Internet routers stability and convergence time of routing in the customer network depends on provider's ibg BG has a rather slow convergence Customer does not entirely controls routing in its VN BG/

48 Comparison of VN solutions (2) Customer-provisionned VNs roviders are not involved in the provisionning of the VN no per-vn routing tables to maintain and distribute no revenue for value-added service Customer builds VN by establising tunnels it may be difficult to automate the tunnel establishment a large number of tunnels may be required Customer has full control over routing in the VN outing protocol can be tuned for fast convergence, load balancing or whatever no direct interactions between IS's routing and VN routing Customer must be able to configure routers correctly BG/

49 Thank you Questions and comments can be sent to Olivier Bonaventure Department of Computing Science and Engineering Université catholique de Louvain (UCL) lace Sainte- Barbe, 2, B-1348, Louvain- la-neuve (Belgium) Bonaventure@ info.ucl.ac.be UL : BG/