idnits 2.17.1 draft-kaliraj-idr-bgp-transport-vpn-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC4364], [RFC8277]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: On receiving a BGP Transport-VPN route with a PNH that is not directly connected, e.g. an IBGP-route, the Route-Target on the route indicates which Transport Class this route belongs to. The routes in the associated Transport RIB are used to resolve the received PNH. If there does not exist a route in the Transport RIB for the PNH, the Transport-VPN route is considered unusable, and MUST not be re-advertised further. -- The document date (March 07, 2020) is 1510 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 538 == Unused Reference: 'RFC4271' is defined on line 514, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'SRTE' Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Vairavakkalai 3 Internet-Draft N. Venkataraman 4 Intended status: Standards Track B. Rajagopalan 5 Expires: September 8, 2020 Juniper Networks, Inc. 6 March 07, 2020 8 BGP Transport VPNs 9 draft-kaliraj-idr-bgp-transport-vpn-00 11 Abstract 13 This document specifies a mechanism, referred to as "service 14 mapping", to express association of overlay routes with underlay 15 routes using BGP. The document describes a framework for service 16 mapping, and specifies BGP protocol procedures that enable 17 dissimination of the service mapping information that may span across 18 administrative domains. It makes it possible to advertise multiple 19 tunnels to the same destination. 21 A new BGP transport address family is defined for this purpose that 22 uses BGP-VPN [RFC4364] technology and follows MPLS-BGP [RFC8277] NLRI 23 encoding. This new address family is called "Transport-VPN". 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in RFC 2119 [RFC2119]. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on September 8, 2020. 48 Copyright Notice 50 Copyright (c) 2020 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3. Transport Class . . . . . . . . . . . . . . . . . . . . . . . 5 68 4. Transport RIB . . . . . . . . . . . . . . . . . . . . . . . . 6 69 5. Transport Routing Instance . . . . . . . . . . . . . . . . . 6 70 6. Nexthop Resolution Scheme . . . . . . . . . . . . . . . . . . 6 71 7. BGP Transport-VPN Family NLRI . . . . . . . . . . . . . . . . 7 72 8. Comparison with other families using RFC-8277 encoding . . . 7 73 9. Protocol Procedures . . . . . . . . . . . . . . . . . . . . . 8 74 10. OAM considerations . . . . . . . . . . . . . . . . . . . . . 10 75 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 76 12. Security Considerations . . . . . . . . . . . . . . . . . . . 11 77 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 78 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 14.1. Normative References . . . . . . . . . . . . . . . . . . 11 80 14.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 83 1. Introduction 85 To facilitate service mapping, the tunnels in a network can be 86 grouped by the purpose they serve into a "Transport Class". The 87 tunnels could be created using any signaling protocol, such as LDP, 88 RSVP, BGP-LU or SPRING. The tunnels could also use native IP or 89 IPv6, as long as the tunnels can carry MPLS payload. Tunnels may 90 exist between different pair of end points. Multiple tunnels may 91 exist between the same pair of end points. 93 Thus, a Transport Class consists of tunnels created by many protocols 94 terminating in various nodes, each satisfying the properties of the 95 class. For example, a "Gold" transport class may consist of tunnels 96 that traverse the shortest path with fast re-route protection, a 97 "Silver" transport class may hold tunnels that traverse shortest 98 paths without protection, a "To NbrAS Foo" transport class may hold 99 tunnels that exit to neighboring AS Foo, and so on. 101 The extensions specified in this document can be used to create a BGP 102 transport tunnel that potentially spans domains, while preserving its 103 Transport Class. Examples of domain are Autonomous System (AS), or 104 IGP area. Within each domain, there is a second level underlay 105 tunnel used by BGP to cross the domain. The second level underlay 106 tunnels could be hetrogeneous: Each domain may use a different type 107 of tunnel, or use a differnet signaling protocol. A domain boundary 108 is demarcated by a rewrite of BGP nexthop to 'self' while re- 109 advertising tunnel routes in BGP. The path uses MPLS label-switching 110 when crossing inter-AS links and uses the native intra-AS tunnel of 111 the desired transport class when traversing within a domain. 113 Overlay routes carry sufficient indication of the Transport Class 114 they should be encapsulated over. A "route resolution" procedure on 115 the ingress node selects from the Transport Class an appropriate 116 tunnel whose destination matches the nexthop of the overlay route. 117 If the overlay route is carried in BGP, the protocol nexthop (or, 118 PNH) is generally carried as an attribute of the route. The PNH of 119 the overlay route is also referred to as "service endpoint". The 120 service endpoint may exist in the same domain as the service ingress 121 node or lie in a different domain, adjacent or non-adjacent. 123 This document describes mechanisms to: 125 Model a "Transport Class" as "Transport RIB" on a router, 126 consisting of tunnel ingress routes of a certain class. 128 Enable service routes to resolve over an intended Transport Class 129 by using the corresponding Transport RIB for finding nexthop 130 reachability. 132 Advertise tunnel ingress routes in a Transport RIB via BGP without 133 any path hiding, using BGP VPN technology and Add-path. Such that 134 overlay routes in the receiving domains can also resolve over 135 tunnels of associated Transport Class. 137 Provide a way for co-operating domains to reconcile between 138 independently administered extended community namespaces, and 139 interoperate between different transport signaling protocols in 140 each domain. 142 In this document we focus mainly on MPLS LSPs as transport tunnels, 143 but the mechanisms would work in similar manner for non-MPLS 144 transport tunnels too, provided the tunnel can carry MPLS payload. 146 2. Terminology 148 LSP: Label Switched Path 150 TE : Traffic Engineering 152 SN : Service Node 154 BN : Border Node 156 TN : Transport Node, P-router 158 BGP-VPN : VPNs built using RFC4364 mechanisms 160 RT : Route-Target extended community 162 RD : Route-Distinguisher 164 PNH : Protocol-Nexthop 166 Service Family : BGP address family used for advertising routes for 167 "data traffic", as opposed to tunnels 169 Transport Family : BGP address family used for advertising tunnels, 170 which are in turn used by service routes for resolution 172 Transport Tunnel : A tunnel over which a service may place traffic. 173 These tunnels can be GRE, UDP, LDP, RSVP, or SR-TE 175 Tunnel Domain : A domain of the network containing SN and BN, under a 176 single administrative control that has a tunnel between SN and BN. 177 An end-to-end tunnel spanning several adjacent tunnel domains can be 178 created by "stitching" them together using labels. 180 Transport Class : A group of transport tunnels offering the same type 181 of service. 183 Transport Class RT : A BGP-VPN Route-Target used to identify a 184 specific Transport Class 186 Transport RIB : At the SN and BN, a Transport Class has an associted 187 Transport RIB that holds its tunnel routes. 189 Transport RTI : A Routing Instance; container of Transport RIB, and 190 associated Transport Class RT and RD. 192 Transport-VPN : Set of Transport RTIs importing same Transport Class 193 RT. These are inturn stitched together to span across tunnel domain 194 boundaries using a mechanism similar to Inter-AS option-b to swap 195 labels at BN (nexthop-self). 197 Mapping Community : Community on a service route, that maps it to 198 resolve over a Transport Class 200 3. Transport Class 202 A Transport Class is defined as a set of transport tunnels that share 203 certain characteristics useful for underlay selection. 205 On the wire, a transport class is represented as the Transport Class 206 RT, which is a regular Route-Target extended community. 208 A Transport Class is configured at SN and BN, along with attributes 209 like RD and Route-Target. Creation of a Transport Class instantiates 210 the associated Transport RIB and a Transport routing instance to 211 contain them all. 213 The operator may configure a BN to classify a tunnel into an 214 appropriate Transport Class, which causes the tunnel's ingress routes 215 to be installed in the corresponding Transport RIB. These tunnel 216 routes may then be advertised into BGP. 218 Alternatively, a router receiving the transport routes in BGP with 219 appropriate signaling information can associate those ingress routes 220 to the appropriate Transport Class. E.g. for Transport-VPN 221 family(SAFI TBD) routes, the Transport Class RT indicates the 222 Transport Class. For BGP-LU family(SAFI 4) routes, import policy 223 based on Communities or inter-AS source-peer may be used to place the 224 route in the desired Transport Class. 226 When the ingress route is received via SRTE [SRTE], which encodes the 227 Transport Class as an integer "Color" in the NLRI as 228 "Color:Endpoint", the Color can be mapped to a Transport Class during 229 import processing. The Color could map to a Community, or Route- 230 Target that installs the ingress route for "Endpoint" in the 231 appropriate Transport RIB. The SRTE route when advertised out to BGP 232 speakers will then be advertised in Transport-VPN family with 233 Transport Class RT and a new label. The MPLS swap route thus 234 installed for the new label will pop the label and deliver 235 decapsulated-traffic into the path determined by SRTE route. 237 4. Transport RIB 239 A Transport RIB is a routing-only RIB that is not installed in 240 forwarding path. However, the routes in this RIB are used to resolve 241 reachability of overlay routes' PNH. Transport RIB is created when 242 the Transport Class it represents is configured. 244 Overlay routes that want to use a specific Transport Class confine 245 the scope of nexthop resolution to the set of routes contained in the 246 corresponding Transport RIB. This Transport RIB is the "Routing 247 Table" referred in Section 9.1.2.1 RFC4271 [1] 249 Routes in a Transport RIB are exported out in 'Transport-VPN' address 250 family. 252 5. Transport Routing Instance 254 A BGP VPN routing instance that is a container for the Transport 255 RIBs. It imports, and exports routes in this RIB with Transport 256 Class RT. Tunnel destination addresses in this routing instance's 257 context come from the "provider namespace". This is different from 258 user VRFs for e.g., which contain prefixes in "customer namespace" 260 The Transport Routing instance uses the RD and RT configured for the 261 Transport Class. 263 6. Nexthop Resolution Scheme 265 An implementation may provide an option for the service route to 266 resolve over less preferred Transport Classes, should the resolution 267 over preferred, or "primary" Transport Class fail. 269 To accomplish this, the set of service routes may be associated with 270 a user-configured "resolution scheme", which consists of the primary 271 Transport Class, and an ordered list of fallback Transport Classes. 273 A community called as "Mapping Community" is configured for a 274 "resolution scheme". A Mapping community maps to exactly one 275 resolution scheme. 277 When a resolution scheme comprises of a primary Transport Class 278 without any fallback, the Transport Class RT associated with the 279 primary Transport Class is used as the Mapping Community. 281 A BGP service route is associated with a resolution scheme during 282 import processing. The import processing matches against "Mapping 283 Community" on the service route and determines the resolution scheme 284 that should be used when resolving the route's PNH. If the route 285 contains more than one Mapping Communities, the first one mapping to 286 a resolution scheme is chosen. 288 A transport route received in BGP Transport-VPN family should use a 289 resolution scheme that contains only the primary Transport Class 290 without any fallbacks. The primary Transport Class is identified by 291 the Transport Class RT carried on the route. Thus Transport Class RT 292 serves as the Mapping Community for Transport-VPN routes. 294 7. BGP Transport-VPN Family NLRI 296 The Transport-VPN family will use the existing AFI of IPv4 or IPv6, 297 and a new SAFI TBD "Transport-VPN" that will apply to both IPv4 and 298 IPv6 AFIs. 300 The "Transport-VPN" SAFI NLRI itself is encoded as specified in 301 https://tools.ietf.org/html/rfc8277#section-2 [RFC8277]. 303 When AFI is IPv4 the "Prefix" portion of Transport-VPN family NLRI 304 consists of an 8-byte RD followed by an IPv4 prefix. When AFI is 305 IPv6 the "Prefix" consists of an 8-byte RD followed by an IPv6 306 prefix. 308 Attributes on a Transport-VPN route include the Route-Target extended 309 community, which is used to leak the route into the right Transport 310 RIBs on SNs and BNs in the network. 312 8. Comparison with other families using RFC-8277 encoding 314 SAFI 128 (Inet-VPN) is a RF8277 encoded family that carries service 315 prefixes in the NLRI, where the prefixes come from the customer 316 namespaces, and are contexualized into separate user virtual service 317 RIBs called VRFs, using RFC4364 procedures. 319 SAFI 4 (BGP-LU) is a RFC8277 encoded family that carries transport 320 prefixes in the NLRI, where the prefixes come from the provider 321 namespace. 323 SAFI TBD (Transport-VPN) is a RFC8277 encoded family that carries 324 transport prefixes in the NLRI, where the prefixes come from the 325 provider namespace, but are contexualized into separate Transport 326 RIBs, using RFC4364 procedures. 328 It is worth noting that SAFI 128 has been used to carry transport 329 prefixes in "L3VPN Inter-AS Carrier's carrier" scenario, where BGP- 330 LU/LDP prefixes in CsC VRF are advertised in SAFI 128 to the remote- 331 end baby carrier. 333 In this document a new AFI/SAFI is used instead of reusing SAFI 128 334 to carry these transport routes, because it is operationally 335 advantageous to segregate transport and service prefixes into 336 separate address families, RIBs. E.g. It allows to safely enable 337 "per-prefix" label allocation scheme for Transport-VPN prefixes 338 without affecting SAFI 128 service prefixes which may have huge 339 scale. "per prefix" label allocation scheme keeps the routing churn 340 local during topology changes. A new family also facilitates having 341 a different readvertisement path of the transport family routes in a 342 network than the service route readvertisement path. viz. Service 343 routes are exchanged over an EBGP multihop sessions between 344 Autonomous systems with nexthop unchanged; whereas Transport-VPN 345 routes are readvertised over EBGP single hop sessions with "nexthop- 346 self" rewrite over inter-AS links. 348 The Transport-VPN family is similar in vein to BGP-LU, in that it 349 carries transport prefixes. The only difference is, it also carries 350 in Route Target an indication of which Transport Class the transport 351 prefix belongs to, and uses RD to disambiguate multiple instances of 352 the same transport prefix in a BGP Update. 354 9. Protocol Procedures 356 This section summarizes the procedures followed by various nodes 357 speaking Transport-VPN family 359 Preparing the network for deploying Transport-VPNs 361 Operator decides on the Transport Classes that exist in the 362 network, and allocates a Route-Target to identify each Transport 363 Class. 365 Operator configures Transport Classes on the SNs and BNs in the 366 network with unique Route-Distinguishers and Route-Targets. 368 Implementations may provide automatic generation and assignment of 369 RD, RT values for a transport routing instance; they should also 370 provide a way to manually override the automatic mechanism, in 371 order to deal with any conflicts that may arise with existing RD, 372 RT values in the network. 374 Origination of Transport-VPN route: 376 At the ingress node of the tunnel's egress domain, the tunneling 377 protocols install routes in the Transport RIB associated with the 378 Transport Class the tunnel belongs to. The ingress node then 379 advertises this tunnel route into BGP as a Transport-VPN route 380 with NLRI RD:TunnelEndpoint, attaching a Route-Target that 381 identifies the Transport Class. 383 Alternatively, the egress node of the tunnel i.e. the tunnel 384 endpoint can originate the BGP Transport-VPN route, with NLRI 385 RD:TunnelEndpoint and PNH TunnelEndpoint, which will resolve over 386 the tunnel route at the ingress node. When the tunnel is up, the 387 Transport-VPN route will become usable and get re-advertised. 389 Unique RD is used by the originator of a Transport-VPN route to 390 disambiguate the multiple BGP advertisements for a transport end 391 point. 393 Ingress node receiving Transport-VPN route 395 On receiving a BGP Transport-VPN route with a PNH that is not 396 directly connected, e.g. an IBGP-route, the Route-Target on the 397 route indicates which Transport Class this route belongs to. The 398 routes in the associated Transport RIB are used to resolve the 399 received PNH. If there does not exist a route in the Transport 400 RIB for the PNH, the Transport-VPN route is considered unusable, 401 and MUST not be re-advertised further. 403 Border node readvertising Transport-VPN route with nexthop self: 405 The BN allocates an MPLS label to advertise upstream in Transport- 406 VPN NLRI. The BN also installs an MPLS swap-route for that label 407 that swaps the incoming label with a label received from the 408 downstream BGP speaker, or pops the incoming label. And then 409 pushes received traffic to the transport tunnel or direct 410 interface that the Transport-VPN route's PNH resolved over. 412 Border node receiving Transport-VPN route on EBGP : 414 If the route is received with PNH that is known to be directly 415 connected, e.g. EBGP single-hop peering address, the directly 416 connected interface is checked for MPLS forwarding capability. No 417 other nexthop resolution process is performed, as the inter-AS 418 link can be used for any Transport Class. 420 If the inter-AS links should honor Transport Class, then the BN 421 should follow procedures of an Ingress node described above, and 422 perform nexthop resolution process. The interface routes should 423 be installed in the Transport RIB belonging to the associated 424 Transport Class. 426 Avoiding path-hiding through Route Reflectors 427 When multiple BNs exist that advertise a RDn:PEn prefix to RRs, 428 the RRs may hide all but one of the BNs, unless ADDPATH [RFC7911] 429 is used for the Transport-VPN family. This is similar to L3VPN 430 option-B scenarios. Hence ADDPATH should be used for Transport- 431 VPN family, to avoid path-hiding through RRs. 433 Ingress node receiving service route with mapping community 435 Service routes received with mapping community resolve using 436 Transport RIBs determined by the resolution scheme. If the 437 resolution process does not find an usable Transport-VPN route or 438 tunnel route in any of the Transport RIBs, the service route MUST 439 be considered unusable for forwarding purpose. 441 Coordinating between domains using different community namespaces. 443 Domains not agreeing on RT, RD, Mapping-community values because 444 of independently administered community namespaces may deploy 445 mechanisms to map and rewrite the Route-target values on domain 446 boundaries, using per ASBR import policies. This is no different 447 than any other BGP VPN family. Mechanisms employed in inter-AS 448 VPN deployments may be used with the Transport-VPN family also. 450 Though RD can also be rewritten on domain boundaries, deploying 451 unique RDs is strongly recommended, because it helps in trouble 452 shooting by uniquely identifying originator of a route, and avoids 453 path-hiding. 455 Future versions of this document may define a new format of Route- 456 Target extended-community to carry Transport Class, to avoid 457 collision with regular Route Target namespace used by service 458 routes. 460 10. OAM considerations 462 TBD 464 11. IANA Considerations 466 This document makes following requests of IANA. 468 New BGP SAFI code for "Transport-VPN". Value TBD. 470 This will be used to create new AFI,SAFI pairs for IPv4, IPv6 471 Transport-VPN families. viz: 473 o "Inet, Transport-VPN". AFI/SAFI = "1/TBD" for carrying IPv4 474 Transport-VPN prefixes. 476 o "Inet6, Transport-VPN". AFI/SAFI = "2/TBD" for carrying IPv6 477 Transport-VPN prefixes. 479 Note to RFC Editor: this section may be removed on publication as an 480 RFC. 482 12. Security Considerations 484 Mechanisms described in this document carry Transport routes in a new 485 BGP address family. That minimizes possibility of these routes 486 leaking outside the expected domain or mixing with service routes. 488 When redistributing between SAFI 4 and SAFI TBD Transport-VPN routes, 489 there is a possibility of SAFI 4 routes mixing with SAFI 1 service 490 routes. To avoid such scenarios, it is recommended that 491 implementations support keeping SAFI 4 routes in a separate transport 492 RIB, distinct from service RIB that contain SAFI 1 service routes. 494 13. Acknowledgements 496 The authors thank Jeff Haas, John Scudder, Navaneetha Krishnan, Ravi 497 M R, Chandrasekar Ramachandran, Shradha Hegde, Richard Roberts, 498 Krzysztof Szarkowicz, John E Drake, Srihari Sangli, Vijay Kestur, 499 Santosh Kolenchery for the valuable discussions. 501 The decision to not reuse SAFI 128 and create a new address-family to 502 carry these transport-routes was based on suggestion made by Richard 503 Roberts and Krzysztof Szarkowicz. 505 14. References 507 14.1. Normative References 509 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 510 Requirement Levels", BCP 14, RFC 2119, 511 DOI 10.17487/RFC2119, March 1997, 512 . 514 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 515 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 516 DOI 10.17487/RFC4271, January 2006, 517 . 519 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 520 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 521 2006, . 523 [RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, 524 "Advertisement of Multiple Paths in BGP", RFC 7911, 525 DOI 10.17487/RFC7911, July 2016, 526 . 528 [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address 529 Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, 530 . 532 [SRTE] Previdi, S., Ed., "Advertising Segment Routing Policies in 533 BGP", 11 2019, . 536 14.2. URIs 538 [1] https://www.rfc-editor.org/rfc/rfc4271#section-9.1.2.1 540 Authors' Addresses 542 Kaliraj Vairavakkalai 543 Juniper Networks, Inc. 544 1133 Innovation Way, 545 Sunnyvale, CA 94089 546 US 548 Email: kaliraj@juniper.net 550 Natarajan Venkataraman 551 Juniper Networks, Inc. 552 1133 Innovation Way, 553 Sunnyvale, CA 94089 554 US 556 Email: natv@juniper.net 558 Balaji Rajagopalan 559 Juniper Networks, Inc. 560 Electra, Exora Business Park~Marathahalli - Sarjapur Outer 561 Ring Road, 562 Bangalore, KA 560103 563 India 565 Email: balajir@juniper.net