idnits 2.17.00 (12 Aug 2021) /tmp/idnits16928/draft-salih-spring-srv6-inter-domain-sids-02.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 : ---------------------------------------------------------------------------- ** There are 66 instances of too long lines in the document, the longest one being 65 characters in excess of 72. == There are 4 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 398 has weird spacing: '...ate the heade...' -- The document date (2 March 2022) is 73 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) == Missing Reference: 'RFC2473' is mentioned on line 250, but not defined == Missing Reference: 'RFC6437' is mentioned on line 251, but not defined -- Looks like a reference, but probably isn't: '4' on line 382 -- Looks like a reference, but probably isn't: '6' on line 320 -- Looks like a reference, but probably isn't: '10' on line 345 -- Looks like a reference, but probably isn't: '12' on line 314 -- Looks like a reference, but probably isn't: '1' on line 384 -- Looks like a reference, but probably isn't: '16' on line 354 -- Looks like a reference, but probably isn't: '5' on line 292 -- Looks like a reference, but probably isn't: '7' on line 375 -- Looks like a reference, but probably isn't: '11' on line 292 -- Looks like a reference, but probably isn't: '13' on line 292 -- Looks like a reference, but probably isn't: '2' on line 290 -- Looks like a reference, but probably isn't: '3' on line 290 -- Looks like a reference, but probably isn't: '8' on line 290 -- Looks like a reference, but probably isn't: '9' on line 290 -- Looks like a reference, but probably isn't: '14' on line 290 -- Looks like a reference, but probably isn't: '15' on line 290 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING Working Group K. Salih 3 Internet-Draft S. Hegde 4 Intended status: Standards Track M. Rajesh 5 Expires: 3 September 2022 R. Bonica 6 Juniper Networks 7 H. wang 8 Huawei Technologies 9 Shaofu. Peng 10 ZTE Corporation 11 2 March 2022 13 SRv6 inter-domain mapping SIDs 14 draft-salih-spring-srv6-inter-domain-sids-02 16 Abstract 18 This document describes three new SRv6 end-point behaviors, called 19 END.REPLACE, END.REPLACEB6 and END.DB6. These behaviors are used in 20 distributed inter-domain solutions and are normally executed on 21 border routers. They also can be used to provide multiple intent- 22 based paths across these domains. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on 3 September 2022. 41 Copyright Notice 43 Copyright (c) 2022 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 48 license-info) in effect on the date of publication of this document. 49 Please review these documents carefully, as they describe your rights 50 and restrictions with respect to this document. Code Components 51 extracted from this document must include Revised BSD License text as 52 described in Section 4.e of the Trust Legal Provisions and are 53 provided without warranty as described in the Revised BSD License. 55 Table of Contents 57 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 59 3. Usecases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3.1. usecase 1 . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3.2. usecase 2 . . . . . . . . . . . . . . . . . . . . . . . . 3 62 4. SRv6 SID Behaviors . . . . . . . . . . . . . . . . . . . . . 4 63 4.1. END.REPLACE . . . . . . . . . . . . . . . . . . . . . . . 4 64 4.2. END.REPLACEB6 . . . . . . . . . . . . . . . . . . . . . . 4 65 4.3. END.DB6 . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 5. Interworking Procedures . . . . . . . . . . . . . . . . . . . 6 67 5.1. Option C Transport Interworking . . . . . . . . . . . . . 6 68 5.2. Option B service interworking . . . . . . . . . . . . . . 9 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 71 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 72 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 73 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 75 10.2. Informative References . . . . . . . . . . . . . . . . . 11 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 78 1. Overview 80 Segment Routing (SR) [RFC8402] allows source nodes to steer packets 81 through SR paths. It can be implemented over IPv6 [RFC8200] or MPLS 82 [RFC3031]. When SR is implemented over IPv6, it is called SRv6 83 [RFC8986]. 85 This document describes three new SRv6 end-point behaviors, called 86 END.REPLACE, END.REPLACEB6 and END.DB6. These behaviors are used to 87 build paths across SRv6 domains. They also facilitate end-to-end 88 SRv6 intent-based path stitching. 90 2. Requirements Language 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 94 "OPTIONAL" in this document are to be interpreted as described in BCP 95 14 [RFC2119] [RFC8174] when, and only when, they appear in all 96 capitals, as shown here. 98 3. Usecases 100 3.1. usecase 1 102 This use-case is mentioned in Section 4.1.1 of 103 [I-D.hegde-spring-mpls-seamless-sr]. 105 ---IBGP------EBGP----IBGP------EBGP-----IBGP--- 106 | | | | | | 108 +-----------+ +-----------+ +-----------+ 109 | | | | | | 110 | ASBR1+--+ASBR2 ASBR3+--+ASBR4 | 111 PE1+ AS1 | X | AS2 | X | AS3 +PE2 112 | ASBR5+--+ASBR6 ASBR7+--+ASBR8 | 113 | | | | | | 114 +-----+-----+ +-----------+ +-----------+ 115 PE3 117 |---SRv6---| |---SRv6---| |---SRv6---| 119 Figure 1: Multiple ASes connected with E-BGP 121 Figure 1 depicts three ASes (AS1, AS2 and AS3). All the three 122 domains deploy SRv6. Inter-provider Option C[RFC4364] connectivity 123 is maintained from PE1 to PE2. 125 3.2. usecase 2 127 +-----------+ +------------+ 128 / \ / \ 129 | ABR1 | 130 | | | 131 PE1+ AS1 + AS1 +PE2 132 | | | 133 | ABR2 | 134 \ /\ / 135 +------------+ +-----------+ 137 Figure 2: Singe AS with different IGP domains 139 The above diagram Figure 2 shows two different SRv6 IGP domains. 140 Services are running between PE1 and PE2 in option B [RFC4364] style. 141 The requirement here is to avoid service route lookup on ABR1 and 142 ABR2 to provide option B style end to end connectivity 144 4. SRv6 SID Behaviors 146 4.1. END.REPLACE 148 The END.REPLACE behavior is applicable in the Multiple ASes Connected 149 With E-BGP (Section 3.1) use-case. 151 The End.REPLACE SID cannot be the last segment in SRH or SR Policy. 153 Any SID instance of this behavior is associated with a set, J, of one 154 or more L3 adjacencies of immediate BGP neighbors 156 When Node N receives a packet destined to S and S is a locally 157 instantiated End.REPLACE SID, Node N executes the following 158 procedure: 160 S01. When an SRH is processed { 161 S02. If (Segments Left == 0) { 162 S03. Stop processing the SRH, and proceed to process the next 163 header in the packet, whose type is identified by 164 the Next Header field in the routing header. Procedure is as 165 per Section 4.1.1 of [RFC8986]. 166 S04. } 167 S05. If (IPv6 Hop Limit <= 1) { 168 S06. Send an ICMP Time Exceeded message to the Source Address with Code 0 169 (Hop limit exceeded in transit), interrupt packet processing, and discard packet 170 S07. } 171 S08. Decrement IPv6 Hop Limit by 1 172 S09. Update IPv6 DA with new destination address(SID) mapped with END.REPLACE SID. 173 S10. Submit the packet to the IPv6 module for transmission 174 to the new destination via a member of J. 175 S11. } 177 4.2. END.REPLACEB6 179 The END.REPLACEB6 behavior is applicable in the Multiple ASes 180 Connected With E-BGP (Section 3.1) use-case. 182 The End.REPLACEB6 SID cannot be the last segment in a SRH or SR 183 Policy. 185 Node N is configured with an IPv6 address T (e.g., assigned to its 186 loopback). 188 When Node N receives a packet destined to S and S is a locally 189 instantiated End.REPLACEB6 SID, Node N executes the following 190 procedure: 192 S01. When an SRH is processed { 193 S02. If (Segments Left == 0) { 194 S03. Stop processing the SRH, and proceed to process the next 195 header in the packet, whose type is identified by 196 the Next Header field in the routing header. Procedure is as 197 per Section 4.1.1 of [RFC8986]. 198 S04. } 199 S05. If (IPv6 Hop Limit <= 1) { 200 S06. Send an ICMP Time Exceeded message to the Source Address with Code 0 201 (Hop limit exceeded in transit), interrupt packet processing, and discard packet 202 S07. } 203 S08. Decrement IPv6 Hop Limit by 1 204 S09. Update IPv6 DA with new destination address(SID) mapped with END.REPLACEB6. 205 S10. Push an IPv6 header with an SRH. 206 S11. Set outer IPv6 SA = T and outer IPv6 DA to the first SID in the segment list 207 S12. Set outer Payload Length, Traffic Class, Hop Limit, and Flow Label fields 208 S13. Set the outer Next Header value 209 S14. Submit the packet to the IPv6 module for transmission to the First SID. 210 S15. } 212 Note : 213 S10 - S13. Implemetation may choose to avoid outer encapsulation for flex-algo and best effort based SRv6 transport tunnels. 214 S12. The Payload Length, Traffic Class, Hop Limit, and Next Header fields are set as per [RFC2473]. The Flow Label is 215 computed as per [RFC6437]. 217 4.3. END.DB6 219 For the use-case mentioned under Section 3.2 END.DB6 SID is 220 applicable. 222 The End.DB6 SID MUST be the last segment in SRH or SR Policy. 224 Node N is configured with an IPv6 address T (e.g., assigned to its 225 loopback). 227 When Node N receives a packet destined to S and S is a locally 228 instantiated End.DB6 SID, Node N executes the following procedure: 230 S01. When an SRH is processed { 231 S02. If (Segments Left != 0) { 232 S03. Send an ICMP Parameter Problem to the Source Address, 233 Code 0 (Erroneous header field encountered), 234 Pointer set to the Segments Left field, 235 interrupt packet processing and discard the packet. 236 S04. } 237 S05. If (Upper-Layer header type == 4(IPv4) OR Upper-Layer header type == 41(IPv6) OR 238 Upper-Layer header type == 143(Ethernet)) { 239 S06. Remove the outer IPv6 header with all its extension headers. 240 S07. Push the new IPv6 header with the SRv6 SIDs associated with the END.DB6 sid in an SRH. 241 S08. Set outer IPv6 SA = T and outer IPv6 DA to the first SID in the segment list. 242 S09. Set outer Payload Length, Traffic Class, Hop Limit, and Flow Label fields 243 S10. Set the outer Next Header value 244 S11. Submit the packet to the IPv6 module for transmission to First SID. 245 S12. } else { 246 S13. Process as per Section 4.1.1 of [RFC8986]. 247 S14. } 248 S15. } 249 Note : 250 S09. The Payload Length, Traffic Class, Hop Limit, and Next Header fields are set as per [RFC2473]. The Flow Label is 251 computed as per [RFC6437]. 253 5. Interworking Procedures 255 Here we will describe the control plane and data plane procedures by 256 taking examples. 258 Node n has a classic IPv6 loopback address An::1/128. One of the SID 259 at node n with locator block B and function F is represented by 260 B:n:F::sid_num. 262 A SID list is represented as 264 266 where S1 is the first SID to visit, S2 is the second SID to visit and 267 S3 is the last SID to visit along the SR path. 269 5.1. Option C Transport Interworking 271 Here we will discuss the use-case mentioned under Section 3.1 272 ---IBGP----------EBGP--------IBGP--------EBGP-------IBGP------- 273 | | | | | | 275 +-----[2]------+ +-----[8]-----+ +------[14]-----+ 276 | | | | | | 277 | [4] +---+ [6] [10]+----+[12] | 278 [1] AS1 | X | AS2 | X | AS3 [16] 279 | [5] +---+ [7] [11]+----+[13] | 280 | | | | | | 281 +-----[3]-----+ +-----[9]-----+ +------[15]-----+ 282 PE3 284 |---SRv6---| |---SRv6---| |---SRv6---| 286 Figure 3: Option C Style Interworking 288 Node [1] acts as ingress PE and Node [16] acts as egress PE. 290 Nodes [2], [3], [8], [9], [14] and [15] are P routers. 292 Nodes [4], [5], [6], [7], [10], [11], [12] and [13] are ASBR routers. 294 A VPN route is advertised via service RRs between an egress PE(node 295 16) and an ingress PE (node 1). The example below shows IBGP-CT 296 connection between border routers in each domain and single hop EBGP- 297 CT for inter-domain connections. However the forwarding procedure 298 for the sids remains the same irrespective of the the various inter- 299 domain protocol extensions used to advertise the sids. AS1, AS2 and 300 AS3 has SRTE policy for the required intent paths. 302 Control plane example: 304 For simplicity only one path is tracked. 306 For a route if the next hop is one hop away then while advertising use END.REPLACE SID. For a route if the 307 next hop is multi hop away then while advertising use END.REPLACEB6 SID. For single hop neighbor case, no encap 308 required as it is just replace and forward on specific link while in multihop case one encap will be required. 310 Routing Protocol(RP) @16: 311 * In ISIS advertise locator B:16::/48 and an END SID B:16::END::1. 312 * BGP AFI=1,SAFI=128 originates a VPN route RD:V/v via A:16::1 and Prefix-SID attribute B:16:DT4::1. 313 This route is advertised to service RR with color extended community red. 314 * BGP originates prefix A:16::1 with color red to ASBR [12] with SRv6 SID B:16:END::1 since its the egress node. 315 RP @12: 316 * BGP receives the route A:16::1 over the ibgp session and readvertises with nexthop self to ASBR [10]. 317 it advertises the SRv6 SID B:12:REPLACEB6::1 in the protocol extensions. As the advertisement was received on a 318 multihop i-bgp session this node allocates a REPLACEB6 sid. 319 RP @10: 320 * BGP receives the route A:16::1 over the ebgp session and readvertises with nexthop self to ASBR [6]. 321 it advertises the SRv6 SID B:10:REPLACE::1 in the protocol extensions. As the advertisement was received on a 322 single hop e-bgp session this node allocates a REPLACE sid. 323 RP @6: 324 * BGP receives the route A:16::1 over the ibgp session and readvertises with nexthop self to ASBR [4]. 325 it advertises the SRv6 SID B:6:REPLACEB6::1 in the protocol extensions. As the advertisement was received on a 326 multihop i-bgp session this node allocates a REPLACEB6 sid. 327 RP @4: 328 * BGP receives the route A:16::1 over the ebgp session and readvertises with nexthop self to PE [1]. 329 it advertises the SRv6 SID B:4:REPLACE::1 in the protocol extensions. As the advertisement was received on a 330 single hop e-bgp session this node allocates a REPLACE sid. 331 RP @1: 332 * BGP receives the route A:16::1 with color red over the ibgp session. 333 * BGP AFI=1, SAFI=128 learn service prefix RD:V/v, next hop A:16::1 and PrefixSID attribute TLV type 5 334 with SRv6 SID B:16:DT4 336 FIB State: 338 @1: IPv4 VRF V/v => H.Encaps.red with SRH, SRH NextHeader=IPv4 where the first 339 sid B:2:END::1 belongs to the SR-policy in AS1. 340 @2: IPv6 Table: B:2:END::1 => Update DA with B:4:REPLACE::1, decrement SL and forward towards the ASBR [4]. 341 @4: IPv6 Table: B:4:REPLACE::1 => Update DA with B:6:REPLACEB6::1 and forward on the interface/interfaces identified by the 342 ebgp neigbhor; the SL remains at 1. 343 @6: IPv6 Table: B:6:REPLACEB6::1 => Update DA with B:10:REPLACE::1 AND do a fresh H.Encaps.red 344 with SRH where the new SRH SIDs belong to SR policy in AS2. 345 @8: IPv6 Table: B:8:END::1 => Update outer IPv6 packet DA with B:10:END::1 and forward towards ASBR [10] 346 @10: IPv6 table: B:10:END::1 => Decap Outer IPv6 header and lookup next IPv6 DA B:10:REPLACE::1 => Update DA to B:12:REPLACEB6::1 347 and forward on the interface/interfaces identified by the ebgp neigbour. SL remains at 1. 348 @12: IPv6 Table B:12:REPLACEB6::1 => Update DA with B:16:END::1 and do a fresh H.Encaps.red with SRH 349 where the new SIDs belong to the SR policy in AS3. 350 @15: IPv6 Table B:15:END::1 => Update outer IPv6 packet DA with B:16:END::1 and forward towards [16]. 351 @16: IPv6 Table B:16:END::1 => Decap the outer header and lookup the inner DA which results in B:16:DT4::1 lookup. DT4 lookup 352 results in Decap and inner IPv4 packet DA lookup in the corresponding VRF. 354 Note: At [16] its possible to optimize the lookups required with minor control plane extensions. 356 5.2. Option B service interworking 358 Here we will discuss the use-case mentioned under Section 3.2 360 ---MP-IBGP/---- ---MP-IBGP/-- 361 | EBGP | EBGP | 363 +-----[2]------+-----[5]-----+ 364 | | | 365 | | | 366 [1] AS1 [4] AS1 [7] 367 | | | 368 | | | 369 +-----[3]------+-----[6]----+ 371 |---SRv6---| |---SRv6---| 373 Figure 4: Option B style Service Interworking 375 Nodes [1] and [7] are PE routers. Node [4] is an option B style 376 configured ABR/RR. 378 Control Plane example: 380 Routing Protocol(RP) @7: 381 * BGP AFI=1,SAFI=128 originates a VPN route RD:V/v via A:7::1 and Prefix-SID 382 attribute B:7:DT4::1. This route is advertised to service RR [4]. 383 RP @4: 384 * BGP receives the route over MP-IBGP/MP-EBGP session and readvertises with nexthop self to PE [1]. 385 it advertises the SRv6 SID B:4:DB6::1 in the Prefix-SID attribute TLV along with it. For all prefixes 386 having SRv6 service SID B:7:DT4::1; the same DB6 SID B:4:DB6::1 will be reused. if a different service sid 387 B:7:DT4::2 comes then a different DB6 SID B:4:DB6::2 will be allocated. This ensures that if the egress allocates 388 per CE sid; the translation at border also ensure per CE sid. 390 RP @1: 391 * BGP AFI=1, SAFI=128 learn service prefix RD:V/v, next hop A:4::1 and PrefixSID attribute TLV type 5 392 with SRv6 SID B:4:DB6::1 394 FIB State: 396 @1: IPv4 VRF V/v => H.Encaps.red with SRH, SRH NextHeader=IPv4 where the first sid belongs to the SR-policy in AS1 397 @4: IPv6 Table: B:4:DB6::1 => Decapsulate the incoming IPv6 header and H.Encaps 398 @7: IPv6 Table: B:7:DT4::1 => Decapsulate the header and lookup the inner IPv4 packet DA in the VRF 400 6. IANA Considerations 402 This document requires no IANA action. 404 The authors will request an early allocation from the "SRv6 Endpoint 405 Behaviors" sub-registry of the "Segment Routing Parameters" registry. 407 7. Security Considerations 409 Because SR inter-working requires co-operation between inter-working 410 domains, this document introduces no security consideration beyond 411 those addressed in [RFC8402], [RFC8754] and [RFC8986]. 413 8. Contributors 415 Jie Dong 416 Huawei Technologies 417 Email: jie.dong@huawei.com 419 Swamy SRK 420 Juniper Networks 421 Email: swamys@juniper.net 423 G. Sri Karthik Goud 424 Juniper Networks 425 Email: gkarthik@juniper.net 427 9. Acknowledgements 429 Thanks to Ram Santhanakrishnan, Srihari Sangli, Rajendra Prasad 430 Bollam and Kiran Kushalad for their valuable comments. 432 10. References 434 10.1. Normative References 436 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 437 Requirement Levels", BCP 14, RFC 2119, 438 DOI 10.17487/RFC2119, March 1997, 439 . 441 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 442 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 443 2006, . 445 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 446 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 447 May 2017, . 449 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 450 (IPv6) Specification", STD 86, RFC 8200, 451 DOI 10.17487/RFC8200, July 2017, 452 . 454 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 455 Decraene, B., Litkowski, S., and R. Shakir, "Segment 456 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 457 July 2018, . 459 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 460 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 461 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 462 . 464 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 465 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 466 (SRv6) Network Programming", RFC 8986, 467 DOI 10.17487/RFC8986, February 2021, 468 . 470 10.2. Informative References 472 [I-D.hegde-spring-mpls-seamless-sr] 473 Hegde, S., Bowers, C., Xu, X., Gulko, A., Bogdanov, A., 474 Uttaro, J., Jalil, L., Khaddam, M., Alston, A., and L. M. 476 Contreras, "Seamless SR Problem Statement", Work in 477 Progress, Internet-Draft, draft-hegde-spring-mpls- 478 seamless-sr-06, 24 September 2021, 479 . 482 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 483 Label Switching Architecture", RFC 3031, 484 DOI 10.17487/RFC3031, January 2001, 485 . 487 Authors' Addresses 489 Salih K A 490 Juniper Networks 491 Embassy Business Park 492 Bangalore 560093 493 KA 494 India 495 Email: salih@juniper.net 497 Shraddha Hegde 498 Juniper Networks 499 Embassy Business Park 500 Bangalore 560093 501 KA 502 India 503 Email: shraddha@juniper.net 505 Rajesh 506 Juniper Networks 507 Embassy Business Park 508 Bangalore 560093 509 KA 510 India 511 Email: mrajesh@juniper.net 513 Ron Bonica 514 Juniper Networks 515 Herndon, Virginia 20171 516 United States of America 517 Email: rbonica@juniper.net 518 Haibo Wang 519 Huawei Technologies 520 Huawei Campus, No. 156 Beiqing Road 521 Beijing 522 100095 523 China 524 Email: rainsword.wang@huawei.com 526 Peng Shaofu 527 ZTE Corporation 528 China 529 Email: peng.shaofu@zte.com.cn