idnits 2.17.1 draft-acee-idr-lldp-peer-discovery-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 218 has weird spacing: '...Address octe...' -- The document date (March 13, 2017) is 2572 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: 'RFC7042' is mentioned on line 115, but not defined ** Downref: Normative reference to an Informational RFC: RFC 7938 (ref. 'BGP-DC') -- Possible downref: Non-RFC (?) normative reference: ref. 'LLDP' -- Obsolete informational reference (is this intentional?): RFC 5226 (ref. 'IANA-GUIDE') (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 2385 (ref. 'TCP-MD5') (Obsoleted by RFC 5925) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Lindem 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track K. Patel 5 Expires: September 14, 2017 Arrcus, Inc 6 S. Zandi 7 LinkedIn 8 March 13, 2017 10 BGP Logical Link Discovery Protocol (LLDP) Peer Discovery 11 draft-acee-idr-lldp-peer-discovery-00.txt 13 Abstract 15 Link Layer Discovery Protocol (LLDP) or IEEE 802.1AB is implemented 16 in networking equipment from many vendors. It is natural for IETF 17 protocols to avail this protocol for simple discovery tasks. This 18 document describes how BGP would use LLDP to discover directly 19 connected and 2-hop peers when peering is based on loopback 20 addresses. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 14, 2017. 39 Copyright Notice 41 Copyright (c) 2017 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 2 58 2. LLDP Extensions . . . . . . . . . . . . . . . . . . . . . . . 3 59 2.1. LLDP Organizationally Specific TLV Format . . . . . . . . 3 60 2.2. Local IP Address OS-TLV Format . . . . . . . . . . . . . 4 61 2.3. BGP Config OS-TLV Format . . . . . . . . . . . . . . . . 5 62 2.3.1. BGP Config OS-TLV - Peering Address Sub-TLV . . . . . 6 63 2.3.2. BGP Config OS-TLV - BGP Local AS Sub-TLV . . . . . . 7 64 2.3.3. BGP Config OS-TLV - BGP Capabilities Sub-TLV . . . . 8 65 3. BGP LLDP Peer Discovery Operations . . . . . . . . . . . . . 9 66 3.1. Advertising BGP Speaker . . . . . . . . . . . . . . . . . 9 67 3.2. Receiving BGP Speaker . . . . . . . . . . . . . . . . . . 9 68 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 70 5.1. IANA Assigned LLDP Subtype . . . . . . . . . . . . . . . 10 71 5.2. BGP Config LLDP OS-TLV Sub-TLVs . . . . . . . . . . . . . 11 72 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 6.1. Normative References . . . . . . . . . . . . . . . . . . 11 74 6.2. Informative References . . . . . . . . . . . . . . . . . 12 75 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 12 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 78 1. Introduction 80 Link Layer Discovery Protocol (LLDP) [LLDP] or IEEE 802.1AB is 81 implemented in networking equipment from many vendors. It is natural 82 for IETF protocols to avail this protocol for simple discovery tasks. 83 This document describes how BGP [BGP] would use LLDP to discover 84 directly connected and 2-hop peers when peering is based on loopback 85 addresses. 87 1.1. Requirements Notation 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in [RFC-KEYWORDS]. 93 2. LLDP Extensions 95 2.1. LLDP Organizationally Specific TLV Format 97 The format of the LLDP Basic Organizationally Specific TLV (OS-TLV) 98 is defined in [LLDP]. It is shown below for completeness. 100 0 1 2 3 101 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 103 | Type (127) | Length | OUI (3 Octets) 00-00-5E | 104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 105 | OUI Continued | Subtype | Value | 106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 107 | ... (Up to 507 Octets) | 109 Type Organizationally Specific TLV type value, 127. 111 Length The length of the remainder of the TLV. 113 OUI Organizationally unique identifier for the 114 organization's OUI. For the IANA, this is value is 115 00-00-5E as specified in [RFC7042]. 117 Subtype IETF specific subtype 119 Value Value for organizationally specific TLV. The Length of 120 the value is 4 octets less than the TLV length. 122 LLDP Organizationally Specific TLV 124 The OUI for the IANA was allocated in section 1.4 of [IEEE-802-IANA]. 125 This document requests creation of a registry for IETF specific sub- 126 types for LLDP Organizationally Specific TLVs. 128 2.2. Local IP Address OS-TLV Format 130 The Local IP Address Organizationally Specific TLV will be used to 131 advertise IPv4 or IPv6 addresses that are local to the link. A 132 network device can advertise multiple Local IP Address OS-TLVs in its 133 LLDP PDU and is only constrained by the length of the PDU. Normally 134 a network device would only advertise its own local address but 135 advertising addresses local to the link for another networking device 136 is not specifically disallowed. The format is shown below. 138 0 1 2 3 139 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | Type (127) | 8 or 20 | OUI (3 Octets) 00-00-5E | 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 | OUI Continued | 1 | Address Family| IPv4/IPv6 | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | IPv4/IPv6 Address | IPv6 Address | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | IPv6 Address | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | IPv6 Address | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | IPv6 Address | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 Length The length will be 8 for IPv4 addresses or 20 for IPv6 155 addresses. 157 Subtype IETF specific subtype for a Local IP address for the 158 link. The value shall be 1. 160 Address IANA Address family (1 for IPv4 or 2 for IPv6) 161 Family 163 Value Local IPv4 or IPv6 Address. 165 2.3. BGP Config OS-TLV Format 167 The BGP Config Organizationally Specific TLV (OS-TLV) will be used to 168 advertise BGP configuration information. The configuration 169 information will be composed of Sub-TLVs. Since the length is 170 limited to 507 octets, multiple BGP Config OS-TLVs could be included 171 in a single LLDP advertisement. 173 0 1 2 3 174 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | Type (127) | Length | OUI (3 Octets) 00-00-5E | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 |OUI Continued | 2 | BGP Config Sub-TLVs ... | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | ... (Up to 507 Octets) | 182 Length The length of the BGP TLV. 184 Subtype IETF specific subtype for BGP Config OS-TLV. The 185 value shall be 2. 187 Value BGP Config Sub-TLVs each with a 1 byte Type and 188 Length. The Length will include solely the value 189 portion of the TLV and not the Type and Length 190 fields themselves. 192 2.3.1. BGP Config OS-TLV - Peering Address Sub-TLV 194 The BGP OS-TLV Peering Address Sub-TLV will be used to advertise the 195 local IP address used for BGP sessions and the associated address 196 families. The format of the BGP Peering Address Sub-TLV is shown 197 below. 199 0 1 2 3 200 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | Type (1) | Length | Address Family| IPv4/IPv6 | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 ~ IPv4/IPv6 Peering Address ... ~ 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | AFI | SAFI | o o o 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 Type The Sub-TLV Type value shall be 1. 211 Length The Sub-TLV length in octets will be 4 for IPv4 or 16 212 for IPv6 plus 3 times the number of AFI/SAFI pairs. 214 Address IANA Address family (1 for IPv4 or 2 for IPv6) 215 Family 217 Peering An IPv4 address (4 octets) or an IPv6 address (16 218 Address octet) peering address. 220 AFI/SAFI One or more AFI/SAFI pairs for BGP session using this 221 Pairs peering address. 223 2.3.2. BGP Config OS-TLV - BGP Local AS Sub-TLV 225 The BGP Config OS-TLV Local AS Sub-TLV will be used to advertise the 226 4-octet local Autonomous System (AS) number. The format of the BGP 227 Local AS Sub-TLV is shown below. 229 0 1 2 3 230 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Type (2) | Length (4) | Local AS | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Local AS | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 Type The Sub-TLV Type value shall be 2. 239 Length The Sub-TLV Length will be 4 octets. 241 Local AS Local Autonomous System (AS) 243 2.3.3. BGP Config OS-TLV - BGP Capabilities Sub-TLV 245 The BGP Config OS-TLV Capabilities Sub-TLV will be used to advertise 246 an 8-octet Capabilities field. The capabilities are represented as 247 bit flags identifying the supported BGP capabilities. The format of 248 the BGP Capabilities Sub-TLV is shown below. 250 0 1 2 3 251 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | Type (3) | Length (8) | Capabilities | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | Capabilities | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | Capabilities | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 Type The Sub-TLV Type value shall be 3. 262 Length The Sub-TLV Length will be 8 octets. 264 Capabilities Bit fields identify BGP capabilities 266 The BGP Capabilities is an 8-octet bit field. The most significant 267 bit is the first bit (Bit 1) of the Capabilities. The following bits 268 are defined: 270 Bit 1: This bit indicates that support for TCP MD5 271 authentication [TCP-MD5]. 273 Bit 2: This bit indicates support for TCP-AO 274 authentication [TCP-AO]. 276 Bit 3: This bit indicates support for Generalized TTL 277 Security Mechanism (GTSM) [GTSM] with a 278 configured TTL range of 254-255. 280 TCP MD5 authentication is described in [TCP-MD5]. The TCP 281 Authentication Option (TCP-AO) is described in [TCP-AO]. The 282 Generalized TTL Security Mechanism (GTSM) is described in [GTSM]. If 283 both TCP MD5 authentication and TCP-AO authentication are specified 284 and TCP-AO is supported, it will take precedence. 286 3. BGP LLDP Peer Discovery Operations 288 The simple use case is to just use the peer address advertised in the 289 LLDP Packet Data Unit (PDU) to establish a 1-hop BGP peer session. 290 This can be used in data centers using BGP as described in [BGP-DC]. 291 The more complex use case is when a loopback address in advertised as 292 the peering address in the LLDP PDU. 294 3.1. Advertising BGP Speaker 296 A BGP speaker MAY advertise its BGP peering address in an LLDP PDU 297 for a link using the BGP Local Address Sub-TLV of BGP-OS TLV Format. 298 This can be an IPv4 or IPv6 address local to the link for 1-hop 299 peering or a loopback address for 2-hop peering. 301 Additionally, a BGP speaker MAY advertise one or more local addresses 302 IPv4 and IPv6 addresses. In the case of 2-hop peering, a local 303 address on the link can be used as a next-hop for the peering 304 address. In this manner both the peering address and reachability 305 can be discovered. 307 A BGP speaker MAY advertise its local AS number using BGP AS Sub-TLV 308 of BGP-OS TLV format. It may also announce relevant capabilities 309 using BGP Capabilities Sub-TLV of BGP-OS TLV format. 311 3.2. Receiving BGP Speaker 313 A BGP speaker configured for LLDP peer discovery will attempt to 314 establish peers using the address in the BGP Local Address Sub-TLV of 315 BGP-OS TLV format. If the peering address is directly accessible 316 over the link on which the LLDP PDU was received, the BGP speaker 317 will attempt to establish a 1-hop BGP session with the peer. 319 If the received BGP Peering Address is not directly accessible over 320 the link, the BGP speaker may add a route to the access the BGP peer. 321 The next-hop for the route MAY be one of the addresses the BGP 322 speaker has advertised in the Local IP Address OS-TLV. If the BGP 323 speaker receives the same BGP peering address in LLDP PDU on multiple 324 links, it will not establish multiple sessions. Rather a single 325 2-hop session will be established. Optionally, ECMP routes are added 326 to the BGP peering session over each link on which an LLDP PDU 327 containing the same Peering Address is received. 329 A BGP speaker MAY receive remote neighbor's local AS number in LLDP 330 in BGP AS Sub-TLV of the BGP-OS TLV. A BGP speaker MAY use the 331 received local AS number to perform validation check of AS received 332 in the OPEN message. Furthermore, A BGP speaker MAY receive remote 333 neighbor's capabilities in LLDP in BGP Capabilities Sub-TLV of the 334 BGP-OS TLV. A BGP speaker MAY use the received capabilities to 335 ensure appropriate neighbor based configuration is done locally so as 336 to facilitate the session establishment. 338 4. Security Considerations 340 This security considerations for BGP [BGP] apply equally to this 341 extension. 343 Additionally, BGP peering address discovery should only be done on 344 trusted links (e.g., in a data center network) since LLDP packets are 345 not authenticated or encrypted [LLDP]. 347 5. IANA Considerations 349 5.1. IANA Assigned LLDP Subtype 351 IANA is requested to create a registry for IANA assigned subtypes in 352 the Organizationally Specific TLV assigned to IANA (OUI of 000-00-53 353 [IEEE-802-IANA]. Assignment is requested for 1 for the Local IP 354 Address OS-TLV. Assignment is also requested for 2 for the BGP 355 Config OS-TLV. 357 +-------------+-----------------------------------+ 358 | Range | Assignment Policy | 359 +-------------+-----------------------------------+ 360 | 0 | Reserved (not to be assigned) | 361 | | | 362 | 1 | Local IP Address | 363 | | | 364 | 2 | BGP Configuration | 365 | | | 366 | 3-127 | Unassigned (IETF Review) | 367 | | | 368 | 128-254 | Reserved (Not to be assigned now) | 369 | | | 370 | 255 | Reserved (not to be assigned) | 371 +-------------+-----------------------------------+ 373 IANA LLDP Organizationally Specific TLV Sub-Types 375 o Types in the range 3-127 are to be assigned subject to IETF 376 Review. New values are assigned only through RFCs that have been 377 shepherded through the IESG as AD-Sponsored or IETF WG Documents 378 [IANA-GUIDE]. 380 o Types in the range 128-254 are reserved and not to be assigned at 381 this time. Before any assignments can be made in this range, 382 there MUST be a Standards Track RFC that specifies IANA 383 Considerations that covers the range being assigned. 385 5.2. BGP Config LLDP OS-TLV Sub-TLVs 387 IANA is requested to create a registry for Sub-TLVs of the BGP Config 388 LLDP OS-TLV. Assignment is requested for 1 for the BGP Peering 389 Address Sub-TLV. Assignment is also requested for 2 for the Local AS 390 Sub-TLV. Additionally, assignment is requested for 3 for the 391 Capabilities Sub-TLV. 393 +-------------+-----------------------------------+ 394 | Range | Assignment Policy | 395 +-------------+-----------------------------------+ 396 | 0 | Reserved (not to be assigned) | 397 | | | 398 | 1 | Peering Address | 399 | | | 400 | 2 | Local AS | 401 | | | 402 | 3 | Capabilities | 403 | | | 404 | 4-127 | Unassigned (IETF Review) | 405 | | | 406 | 128-254 | Reserved (Not to be assigned now) | 407 | | | 408 | 255 | Reserved (not to be assigned) | 409 +-------------+-----------------------------------+ 411 LLDP BGP Config OS-TLV Types 413 o Types in the range 4-127 are to be assigned subject to IETF 414 Review. New values are assigned only through RFCs that have been 415 shepherded through the IESG as AD-Sponsored or IETF WG Documents 416 [IANA-GUIDE]. 418 o Types in the range 128-254 are reserved and not to be assigned at 419 this time. Before any assignments can be made in this range, 420 there MUST be a Standards Track RFC that specifies IANA 421 Considerations that covers the range being assigned. 423 6. References 425 6.1. Normative References 427 [BGP] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 428 Protocol 4 (BGP-4)", RFC 4271, January 2006. 430 [BGP-DC] Lapukhov, P., Premji, A., and J. Mitchell, "BGP Routing in 431 Data Centers", RFC 7938, August 2016. 433 [LLDP] IEEE, "IEEE Standard for Local and metropolitan area 434 networks-- Station and Media Access Control Connectivity 435 Discovery Corrigendum 2: Technical and Editorial 436 Corrections", IEEE 802.1AB-2009/Cor 2-2015, DOI 10.1109/ 437 ieeestd.2015.7056401, March 2015. 439 [RFC-KEYWORDS] 440 Bradner, S., "Key words for use in RFC's to Indicate 441 Requirement Levels", BCP 14, RFC 2119, March 1997. 443 6.2. Informative References 445 [GTSM] Gill, V., Heasley, J., Savola, P., and C. Pignataro, "The 446 Generalized TTL Security Mechanism", RFC 5082, October 447 2007. 449 [IANA-GUIDE] 450 Narten, T. and H. Alvestrand, "Guidelines for Writing an 451 IANA Considerations Section in RFCs", RFC 5226, May 2008. 453 [IEEE-802-IANA] 454 Eastlake, D. and J. Abley, "IANA Considerations and IETF 455 Protocol and Documentation Usage for IEEE 802 Parameters", 456 RFC 7042, October 2013. 458 [TCP-AO] Touch, J., Mankin, A., and R. Bonica, "The TCP 459 Authentication Option", RFC 5925, June 2010. 461 [TCP-MD5] Heffernan, A., "TCP MD5 Signature Option", RFC 2385, 462 August 1998. 464 Appendix A. Acknowledgments 466 The RFC text was produced using Marshall Rose's xml2rfc tool. 468 Authors' Addresses 470 Acee Lindem 471 Cisco Systems 472 301 Midenhall Way 473 Cary, NC 27513 474 USA 476 Email: acee@cisco.com 477 Keyur Patel 478 Arrcus, Inc 480 Email: keyur@arrcus.com 482 Shawn Zandi 483 LinkedIn 484 222 2nd Street 485 San Francisco, CA 94105 486 USA 488 Email: szandi@linkedin.com