idnits 2.17.1 draft-ietf-idr-next-hop-capability-07.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 -- The document date (8 December 2021) is 869 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Decraene 3 Internet-Draft Orange 4 Updates: 6790 (if approved) K. Kompella 5 Intended status: Standards Track Juniper Networks, Inc. 6 Expires: 11 June 2022 W. Henderickx 7 Nokia 8 8 December 2021 10 BGP Next-Hop dependent capabilities 11 draft-ietf-idr-next-hop-capability-07 13 Abstract 15 RFC 5492 advertises the capabilities of the BGP peer. When the BGP 16 peer is not the same as the BGP Next-Hop, it is useful to also be 17 able to advertise the capability of the BGP Next-Hop, in particular 18 to advertise forwarding plane features. This document defines a 19 mechanism to advertise such BGP Next Hop dependent Capabilities. 21 This document defines a new BGP non-transitive attribute to carry 22 Next-Hop Capabilities. This attribute is guaranteed to be deleted or 23 updated when the BGP Next Hop is changed, in order to reflect the 24 capabilities of the new BGP Next-Hop. 26 This document also defines a Next-Hop capability to advertise the 27 ability to process the MPLS Entropy Label as an egress LSR for all 28 NLRI advertised in the BGP UPDATE. It updates RFC 6790 with regard 29 to this BGP signaling. 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 11 June 2022. 48 Copyright Notice 50 Copyright (c) 2021 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 (https://trustee.ietf.org/ 55 license-info) in effect on the date of publication of this document. 56 Please review these documents carefully, as they describe your rights 57 and restrictions with respect to this document. Code Components 58 extracted from this document must include Revised BSD License text as 59 described in Section 4.e of the Trust Legal Provisions and are 60 provided without warranty as described in the Revised BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 66 3. BGP Next-Hop dependent Capabilities Attribute . . . . . . . . 3 67 3.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 3 68 3.2. Attribute Operation . . . . . . . . . . . . . . . . . . . 4 69 3.3. Interpreting received Capability . . . . . . . . . . . . 5 70 3.4. Attribute Error Handling . . . . . . . . . . . . . . . . 5 71 3.5. Network operation considerations . . . . . . . . . . . . 6 72 4. Entropy Label Next-Hop dependent Capability . . . . . . . . . 6 73 4.1. Readable Label Depth . . . . . . . . . . . . . . . . . . 7 74 4.2. Entropy Label Next-Hop Capability error handling . . . . 8 75 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 76 5.1. Next-Hop Capabilities Attribute . . . . . . . . . . . . . 9 77 5.2. Next-Hop Capability registry . . . . . . . . . . . . . . 9 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 79 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10 80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 81 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 82 8.2. Informative References . . . . . . . . . . . . . . . . . 11 83 Appendix A. Changes / Author Notes . . . . . . . . . . . . . . . 12 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 86 1. Introduction 88 [RFC5492] advertises the capabilities of the BGP peer. When the BGP 89 peer is not the same as the BGP Next-Hop, it is useful to also be 90 able to advertise the capability of the BGP Next-Hop, in particular 91 to advertise forwarding plane features. This document defines a 92 mechanism to advertise such BGP Next Hop Capabilities. 94 This document defines a new BGP non-transitive attribute to carry 95 Next-Hop Capabilities. This attribute is guaranteed to be deleted or 96 updated when the BGP Next Hop is changed, in order to reflect the 97 capabilities of the new BGP Next-Hop. Hence it allows advertising 98 capabilities which are dependent of the BGP Next-Hop. 100 This attribute advertises the capabilities of the BGP Next-Hop for 101 the NLRI advertised in the same BGP update. A BGP Next-Hop may 102 advertise different capabilities for different set of NLRI. 104 This document also defines a first application to advertise the 105 capability to handle the MPLS Entropy Label defined in [RFC6790]. 106 Note that RFC 6790 had originally defined a BGP attribute for this 107 but it has been latter deprecated in [RFC7447]. 109 2. Requirements Language 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 113 "OPTIONAL" in this document are to be interpreted as described in BCP 114 14 [RFC2119] [RFC8174] when, and only when, they appear in all 115 capitals, as shown here. 117 3. BGP Next-Hop dependent Capabilities Attribute 119 3.1. Encoding 121 The BGP Next-Hop dependent Capabilities Attribute is an optional, 122 non-transitive BGP Attribute, of value TBD1. The attribute consists 123 of a set of Next-Hop Capabilities. 125 The inclusion of a Next-Hop Capability "X" in a BGP UPDATE message, 126 indicates that the BGP Next-Hop, encoded in either the NEXT_HOP 127 attribute defined in [RFC4271] or the Network Address of Next Hop 128 field of the MP_REACH_NLRI attribute defined in [RFC4760], supports 129 the capability "X" for the NLRI advertised in this BGP UPDATE. 131 This document does not make a distinction between these two Next-Hop 132 fields and uses the term 'BGP Next-Hop' to refer to whichever one is 133 used in a given BGP UPDATE message. 135 A Next-Hop Capability is a triple (Capability Code, Capability 136 Length, Capability Value) aka a TLV: 138 +------------------------------+ 139 | Capability Code (2 octets) | 140 +------------------------------+ 141 | Capability Length (2 octets) | 142 +------------------------------+ 143 | Capability Value (variable) | 144 ~ ~ 145 +------------------------------+ 147 Figure 1: BGP Next-Hop Capability 149 Capability Code: a two-octets unsigned binary integer which indicates 150 the type of "Next-Hop Capability" advertised and unambiguously 151 identifies an individual capability. 153 Capability Length: a two-octets unsigned binary integer which 154 indicates the length, in octets, of the Capability Value field. A 155 length of 0 indicates that no Capability Value field is present. 157 Capability Value: a variable-length field. It is interpreted 158 according to the value of the Capability Code. 160 BGP speakers SHOULD NOT include more than one instance of a Next-Hop 161 capability with the same Capability Code, Capability Length, and 162 Capability Value. Note, however, that processing of multiple 163 instances of such capability does not require special handling, as 164 additional instances do not change the meaning of the announced 165 capability; thus, a BGP speaker MUST be prepared to accept such 166 multiple instances. 168 BGP speakers MAY include more than one instance of a capability (as 169 identified by the Capability Code) with non-zero Capability Length 170 field, but with different Capability Value and either the same or 171 different Capability Length. Processing of these capability 172 instances is specific to the Capability Code and MUST be described in 173 the document introducing the new capability. 175 3.2. Attribute Operation 177 The BGP Next-Hop dependent Capabilities attribute being non- 178 transitive, as per [RFC4271], a BGP speaker which does not understand 179 it will quietly ignore it and not pass it along to other BGP peers. 181 A BGP speaker that understands the BGP Next-Hop dependent 182 Capabilities Attribute and does not change the BGP Next-Hop, SHOULD 183 NOT change the BGP Next-Hop dependent Capabilities Attribute and 184 SHOULD pass the attribute unchanged along to other BGP peers. 186 A BGP speaker that understands the BGP Next-Hop dependent 187 Capabilities Attribute and changes the BGP Next-Hop, MUST remove or 188 update the received BGP Next-Hop dependent Capabilities Attribute 189 before propagating the BGP UPDATE to other BGP peers. If the 190 capability is not removed, it MUST be updated to only advertise the 191 capabilities of the new BGP Next-Hop for these NLRIs. An 192 implementation MAY allow, by configuration, to not advertise some of 193 the capabilities of a BGP Next-Hop. If a received capability is 194 unknown, it can't be updated hence unknown capabilities MUST be 195 removed when the BGP Next-Hop is changed. 197 The BGP Next-Hop Capability Code MUST reflect the capability of the 198 router indicated in the BGP Next-Hop, for the NLRI advertised in the 199 BGP UPDATE. If a BGP speaker sets the BGP Next-Hop to an address of 200 a different router, it MUST NOT advertise a BGP Next-Hop Capability 201 not supported by this router for these NLRI. 203 3.3. Interpreting received Capability 205 A BGP speaker receiving a BGP Next-Hop Capability Code that it 206 supports behave as defined in the document defining this Capability 207 Code. A BGP speaker receiving a BGP Next-Hop Capability Code that it 208 does not support MUST ignore this BGP Next-Hop Capability Code. In 209 particular, this MUST NOT be handled as an error. In both cases, the 210 BGP speaker MUST examine the remaining BGP Next-Hop Capability 211 Code(s) that may be present in the BGP Next-Hop Capabilities 212 Attribute. 214 The presence of a Next-Hop Capability SHOULD NOT influence route 215 selection or route preference, unless tunneling is used to reach the 216 BGP Next-Hop or the selected route has been learnt from EBGP (i.e. 217 the Next-Hop is in a different AS). Indeed, it is in general 218 impossible for a node to know that all BGP routers of the Autonomous 219 System (AS) will understand a given Next-Hop Capability; and having 220 different routers, within an AS, use a different preference for a 221 route, may result in forwarding loops if tunnelling is not used to 222 reach the BGP Next-Hop. 224 3.4. Attribute Error Handling 226 A BGP Next-Hop dependent Capabilities Attribute is considered 227 malformed if the length of the Attribute is not equal to the sum of 228 all (BGP Next-Hop dependent Capability Length +4) of the capabilities 229 carried in this attribute. Note that "4" is the length of the fields 230 "Type" and "Length" of each BGP Next Hop dependent Capability, as the 231 capability length only account for the length of the Value field. 233 A BGP UPDATE message with a malformed BGP Next-Hop dependent 234 Capabilities Attribute SHALL be handled using the approach of 235 "attribute discard" defined in [RFC7606]. 237 Unknown Next-Hop Capabilities Codes MUST NOT be considered as an 238 error. 240 A document that specifies a new Next-Hop Capability SHOULD provide 241 specifics regarding what constitutes an error for that Next-Hop 242 Capability. 244 If a Next-Hop dependent Capability is malformed, this Capability MUST 245 be ignored and removed. Others Next-Hop Capabilities MUST be 246 processed as usual. 248 3.5. Network operation considerations 250 In the corner case where multiple nodes use the same IP address as 251 their BGP Next-Hop, aka anycast nodes as described in [RFC4786], a 252 BGP speaker MUST NOT advertise a given Next-Hop Capability unless all 253 nodes sharing this same IP address support this Next-Hop Capability. 254 The network operator operating those anycast nodes is responsible for 255 enforcing that an anycast node does not advertise a BGP Next-Hop 256 capability not supported by all nodes advertising this anycast 257 address. This can be performed by using anycast nodes sharing the 258 same capabilities or by filtering the BGP Next-Hop Capabilities which 259 are not shared by all anycast nodes. 261 For security considerations, a network operator may want to filter 262 the BGP Next-Hop capabilities advertised from or to external 263 Autonomous Systems on a per capability, capability type or attribute 264 basis. 266 4. Entropy Label Next-Hop dependent Capability 268 The Entropy Label Next-Hop Capability has type code 1 and a length of 269 0 or 1 octet. 271 The inclusion of the "Entropy Label" Next-Hop Capability indicates 272 that the BGP Next-Hop can be sent packets, for all routes indicated 273 in the NRLI, with a MPLS entropy label (ELI, EL) added immediately 274 after the label stack advertised with the NLRI. 276 On the receiving side, suppose BGP speaker S has determined that 277 packet P is to be forwarded according to BGP route R, where R is a 278 route of one of the labeled address families. And suppose that L is 279 the label stack embedded in the NLRI of route R. Then to forward 280 packet P according to route R, S either replaces P's top label with 281 L, or else pushes L onto the MPLS label stack. If the EL-Capability 282 is advertised in the BGP UPDATE advertising this route R, S knows 283 that it may safely place the ELI and an EL on the label stack 284 immediately beneath L. 286 A BGP speaker S that sends an UPDATE with the BGP Next-Hop "NH" MAY 287 include the Entropy Label Next-Hop Capability only if the NLRI are 288 labelled and for all the NLRI in the BGP UPDATE, either of the 289 following is true: 291 * Egress case: NH is the egress of the LSP advertised with the NLRI 292 and its capable of handling the ELI during the lookup of the MPLS 293 top label. 295 * Transit LSR case: NH is a transit LSR for the LSP advertised with 296 the NLRI (i.e. NH swaps one of the label advertised in the NLRI) 297 and next downstream BGP Next-Hop(s) has(have) advertised the 298 Entropy Label Next-Hop Capability (or a similar capability 299 signalled by protocol P if the route is redistributed, by NH, from 300 protocol P into BGP). 302 4.1. Readable Label Depth 304 When stacked LSPs are used and a LSR nests LSP(s) inside this BGP 305 signalled LSP, its useful for the ingress LSRs to know how many 306 labels the BGP Next-Hop and its downstream LSR(s) may read when load- 307 balancing based on the Entropy Label. In other words, how many 308 labels the ingress LER may push, before pushing an entropy label that 309 will be seen by the BGP Next-Hop and its downstream LSR(s). 311 This maximum number of labels is called the Readable Label Depth 312 (RLD) of the LSP(s). It is related, yet different, to the RLD of an 313 node which is defined in [I-D.ietf-mpls-spring-entropy-label] 315 The RLD of the LSP(s) advertised in the NLRI, may be advertised in 316 the first octet of value field of the Entropy Label Next-Hop 317 Capability. This value field is optional. If present, the value 318 field is a one-octet unsigned binary integer which indicates the 319 maximum Readable Label Depth (RLD) of the LSP(s) advertised in the 320 NLRI. In other words, this is the maximum number of MPLS labels that 321 may be pushed by the ingress, before pushing the ELI, EL labels, 322 where the BGP Next-Hop and its downstream LSR(s) are capable of 323 performing load-balancing based on the entropy label. 325 S SHOULD advertise a RLD of: 327 * If S is the egress of the LSP(s) advertised in the NLRI: its own 328 local RLD; 330 * If S is propagating in BGP a route received in BGP: the minimum 331 of: 333 - its own node RLD; 335 - the RLD of the LSP from itself to the BGP NEXT_HOP of its 336 received route minus (Number of Labels in the received NLRI - 337 Number of Labels in the sent NLRI); 339 - 0 if a RLD is not present in its received routes or the RLD in 340 the received BGP route minus (Number of Labels in the received 341 NLRI - Number of Labels in the sent NLRI). 343 - Note that the first term represents the limitation of the new 344 BGP NEXT_HOP (S), the second term the contribution of the 345 LSR(s) between the new BGP NEXT_HOP (S) and the old (received) 346 BGP NEXT_HOP (S'), the third term represent the contribution 347 from the old BGP NEXT_HOP (S') toward the egress. 349 * If S is propagating in BGP a route received in protocol X: the 350 minimum of: 352 - its own node RLD; 354 - the minimum of thg RLD(s) in the received protocol X to reach 355 the NLRI(s). 357 255 is a reserved value. 359 Note that the local RLD is meant as a node value. If a router has 360 multiple line cards with different capabilities, the router SHOULD 361 advertise the smallest one. However, a router MAY choose to only 362 consider the line cards that may be used by the BGP routers receiving 363 the ELC. e.g. if the ELC is advertised over an EBGP session with peer 364 A, a router MAY consider only the line cards connected to peer A. 366 Advertisement of the RLD is optional. When used, changes in IGP 367 routing may trigger BGP re-advertisement and hence will increase BGP 368 churn. If the RLD is decreased, it SHOULD be readvertised 369 immediatly. If the RLD is increased readvertisement MAY be delayed. 370 We note however that labelled BGP routes are typically not advertised 371 outside of an administrative domain hence the churn would be limited 372 to this administrative domain. 374 4.2. Entropy Label Next-Hop Capability error handling 376 If the Entropy Label Next-Hop Capability is present more than once, 377 it MUST be considered as received once with a length of 0. 379 If the Entropy Label Next-Hop Capability is received with a length 380 other than 0 or 1, it is not considered malformed, and its semantics 381 are exactly the same as if it had a length of 1. In other words, 382 additional octets MUST be ignored. This allows for the graceful 383 addition of future extensions. 385 5. IANA Considerations 387 5.1. Next-Hop Capabilities Attribute 389 IANA is requested to allocate a new Path Attribute, called "Next-Hop 390 Capabilities", type Code TBD1, from the "BGP Path Attributes" 391 registry. 393 5.2. Next-Hop Capability registry 395 The IANA is requested to create and maintain a registry entitled "BGP 396 Next-Hop Capabilities". 398 The registration policies [RFC8126] for this registry are: 400 0 Reserved 401 1-63 IETF Review 402 64-65534 First Come First Served 403 65535 Reserved 405 IANA is requested to make the following initial assignments: 407 Registry Name: Next-Hop Capability. 409 Value Meaning Reference 410 ---------- ---------------------------------------- --------- 411 0 Reserved (not to be allocated) This document 412 1 Entropy Label This document 413 2-65534 Unassigned 414 65535 Reserved for future registry extension This document 416 6. Security Considerations 418 This document does not introduce new security vulnerabilities in BGP. 419 Specifically, an operator who is relying on the information carried 420 in BGP must have a transitive trust relationship back to the source 421 of the information. Specifying the mechanism(s) to provide such a 422 relationship is beyond the scope of this document. Please refer to 423 the Security Considerations section of [RFC4271] for security 424 mechanisms applicable to BGP. 426 As this attribute is removed when the BGP Next-Hop is changed, the 427 source of the information is the router which IP address is indicated 428 in the BGP Next-Hop. Such Next-Hop is typically either within the AS 429 when a BGP Next-Hop Self policy is configured, or in the neighboring 430 AS with which an interconnection and an EBGP has been established. 431 If this neighboring AS is not trusted with regards to information 432 carried in the BGP attribute, or carried in a specific capability, 433 this attribute or specific capability should be removed when 434 received. Note that in some cases, this Next-Hop may advertise 435 information based on information it has received from its own 436 downstream BGP Next-Hop, hence the transitive trust relationship. If 437 the underlying transport between both ASes is not trusted, BGP 438 transport should be protected for integrity and authentification. 440 The advertisement of BGP Next-Hop capabilities to EBGP peers may 441 disclose, to the peer AS, some capabilities of the BGP node and may 442 help fingerprinting its hardware model and software version. This 443 may be mitigated by filtering the capability advertised to EBGP 444 peers. 446 Security of the Entropy Label capability advertisement is unchanged 447 compared to [RFC6790] which originally defined this signaling. 449 7. Acknowledgement 451 The Entropy Label Next-Hop Capability defined in this document is 452 based on the ELC BGP attribute defined in section 5.2 of [RFC6790]. 454 The authors wish to thank John Scudder for the discussions on this 455 topic and Eric Rosen for his in-depth review of this document. 457 The authors wish to thank Jie Dong and Robert Raszuk for their review 458 and comments. 460 8. References 462 8.1. Normative References 464 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 465 Requirement Levels", BCP 14, RFC 2119, 466 DOI 10.17487/RFC2119, March 1997, 467 . 469 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 470 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 471 DOI 10.17487/RFC4271, January 2006, 472 . 474 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 475 "Multiprotocol Extensions for BGP-4", RFC 4760, 476 DOI 10.17487/RFC4760, January 2007, 477 . 479 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 480 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 481 RFC 6790, DOI 10.17487/RFC6790, November 2012, 482 . 484 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 485 Patel, "Revised Error Handling for BGP UPDATE Messages", 486 RFC 7606, DOI 10.17487/RFC7606, August 2015, 487 . 489 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 490 Writing an IANA Considerations Section in RFCs", BCP 26, 491 RFC 8126, DOI 10.17487/RFC8126, June 2017, 492 . 494 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 495 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 496 May 2017, . 498 8.2. Informative References 500 [I-D.ietf-mpls-spring-entropy-label] 501 Kini, S., Kompella, K., Sivabalan, S., Litkowski, S., 502 Shakir, R., and J. Tantsura, "Entropy Label for Source 503 Packet Routing in Networking (SPRING) Tunnels", Work in 504 Progress, Internet-Draft, draft-ietf-mpls-spring-entropy- 505 label-12, 16 July 2018, . 508 [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast 509 Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, 510 December 2006, . 512 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 513 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 514 2009, . 516 [RFC7447] Scudder, J. and K. Kompella, "Deprecation of BGP Entropy 517 Label Capability Attribute", RFC 7447, 518 DOI 10.17487/RFC7447, February 2015, 519 . 521 Appendix A. Changes / Author Notes 523 [RFC Editor: Please remove this section before publication] 525 Changes -01: 527 * Capability code and length encoded over 2 octets (from one). IANA 528 registry is now mainly FCFS. 530 * Addition of section "Network operation considerations", in 531 particular to discuss anycast nodes. 533 * Enhanced Security consideration (capability advertised to external 534 ASes). 536 * Editorial changes and typo corrections. 538 Changes -02: No change. Refresh only. 540 Changes -03: Addition of the optional Readable Label Depth. 542 Changes -04: Update to security section, following discussion on the 543 IDR mailing list. 545 Changes -05 to -07: No change. Refresh only. 547 Authors' Addresses 549 Bruno Decraene 550 Orange 552 Email: bruno.decraene@orange.com 553 Kireeti Kompella 554 Juniper Networks, Inc. 555 1194 N. Mathilda Avenue 556 Sunnyvale, CA 94089 557 United States of America 559 Email: kireeti.kompella@gmail.com 561 Wim Henderickx 562 Nokia 563 Copernicuslaan 50 564 95134 Antwerp 2018 565 Belgium 567 Email: wim.henderickx@nokia.com