idnits 2.17.1 draft-boutros-nvo3-geneve-applicability-for-sfc-04.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 (September 16, 2019) is 1682 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: 'RFC2119' is mentioned on line 146, but not defined -- Looks like a reference, but probably isn't: '0' on line 270 == Missing Reference: 'RFC2104' is mentioned on line 438, but not defined == Unused Reference: 'KEYWORDS' is defined on line 506, but no explicit reference was found in the text == Unused Reference: 'Geneve' is defined on line 511, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Sami Boutros, Ed. 3 Intended Status: Standard Track VMware 4 Dharma Rajan 5 Philip Kippen 6 Pierluigi Rolando 7 VMware 8 Jim Guichard 9 Huawei 10 Sam Aldrin 11 Google 13 Expires: March 19, 2020 September 16, 2019 15 Geneve applicability for service function chaining 16 draft-boutros-nvo3-geneve-applicability-for-sfc-04 18 Abstract 20 This document describes the applicability of using Generic Network 21 Virtualization Encapsulation (Geneve), to carry the service function 22 path (SFP) information, and the network service header (NSH) 23 encapsulation. The SFP information will be carried in Geneve option 24 TLV(s). 26 Status of this Memo 28 This Internet-Draft is submitted to IETF in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as 34 Internet-Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/1id-abstracts.html 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html 47 Copyright and License Notice 49 Copyright (c) 2019 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1 Requirement for SFC in NVO3 domain . . . . . . . . . . . . . 3 66 1.2 Proposed solution for SFC in NVO3 domain . . . . . . . . . . 3 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 4. Geneve Option TLV(s) . . . . . . . . . . . . . . . . . . . . . 5 70 4.1 Geneve Service Function List (SFL) Option TLV . . . . . . . 5 71 5.. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 5.1 Operation at Ingress . . . . . . . . . . . . . . . . . . . . 7 73 5.2 Operation at each NVE along the service function path . . . 8 74 5.3 Operation at Egress . . . . . . . . . . . . . . . . . . . . 9 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 9 76 7. Management Considerations . . . . . . . . . . . . . . . . . . . 10 77 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 78 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 11 79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 80 10.1 Normative References . . . . . . . . . . . . . . . . . . . 11 81 10.2 Informative References . . . . . . . . . . . . . . . . . . 11 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 84 1. Introduction 86 The Service Function Chaining (SFC) Architecture [rfc7665] defines a 87 service function chain (SFC) as (1) the instantiation of an ordered 88 set of service functions and (2) the subsequent "steering" of traffic 89 through them. 91 SFC defines a Service Function Path (SFP) as the exact set of service 92 function forwarders (SFF)/service functions (SF)s the packet will 93 visit when it actually traverses the network. 95 An optimized SFP helps to build an efficient Service function chain 96 (SFC) that can be used to steer traffic based on classification 97 rules, and metadata information to provide services for Network 98 Function Virtualization (NFV). Metadata are typically passed between 99 service functions and Service function forwarders SFF(s) along a 100 service function path. 102 In a Network Virtualization Overlays (NVO3) domain, Network 103 Virtualization Edges (NVE)s can be implemented on hypervisors hosting 104 virtual network functions VNF(s) or cloud native functions CNF(s) 105 implementing service functions, or on CNFs on bare metal servers or 106 on physical routers connected to service function appliances. NVO3 107 domain uses tunneling and encapsulation protocols such as Geneve to 108 provide connectivity for tenants workloads and service function 109 running in its domain. NVEs in an NVO3 domain are typically 110 controlled by a centralized network virtualization authority NVA. 112 [RFC8300] defines a new encapsulation protocol, network service 113 header (NSH) to encode the SFP and the metadata. 115 1.1 Requirement for SFC in NVO3 domain 117 The requirement is to provide service function chaining in an NVO3 118 domain without the need to implement yet another control plane for 119 service topology. 121 1.2 Proposed solution for SFC in NVO3 domain 123 This document specifies the applicability of using Generic Network 124 Virtualization Encapsulation (Geneve), to carry the service function 125 path (SFP) information, and the network service header (NSH) 126 encapsulation. 128 The SFP will be implemented using a new Geneve Service Function List 129 (SFL) option for use strictly between Network Virtualization Edges 130 (NVEs) performing the service forwarding function (SFF) in the same 131 Network Virtualization Overlay over Layer 3 NVO3 domain. The next 132 protocol in the Geneve Header will be the NSH EtherType, 0x894F. The 133 NSH encapsulation will include the Service Path Identifier (SPI) and 134 the Service Index (SI). The NSH SI will serve as an index to the 135 VNF/CNF hop to visit in the SFL. 137 In the absence of the SFL we would need a service topology control 138 plane. The Geneve overlay will encap the NSH encapsulation and the 139 next protocol on Geneve will be the NSH Ethertype. 141 2. Terminology 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in RFC 2119 [RFC2119]. 147 3. Abbreviations 149 NVO3 Network Virtualization Overlays over Layer 3 151 OAM Operations, Administration, and Maintenance 153 TLV Type, Length, and Value 155 VNI Virtual Network Identifier 157 NVE Network Virtualization Edge 159 NVA Network Virtualization Authority 161 NIC Network interface card 163 VTEP Virtual Tunnel End Point 165 Transit device Underlay network devices between NVE(s). 167 Service Function (SF): Defined in [RFC7665]. 169 Service Function Chain (SFC): Defined in [RFC7665]. 171 Service Function Forwarder (SFF): Defined in [RFC7665]. 173 Service Function Path (SFP): Defined in [RFC7665]. 175 Metadata: Defined in [[draft-ietf-sfc-nsh] 177 NFV: Network function virtualization. 179 VNF: Virtual network function 180 CNF: Cloud native function 182 4. Geneve Option TLV(s) 184 4.1 Geneve Service Function List (SFL) Option TLV 186 Geneve Header: 188 0 1 2 3 189 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 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 |Ver| Opt Len |O|C| Rsvd. |Protocol Type = NSH Ethertype | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | Virtual Network Identifier (VNI) | Reserved | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 Geneve Option Header: 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | SFL Option Class | Type |R|R|R| Length | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | Variable Option Data | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 Followed by the NSH encapsulation which is composed of a 4-byte 205 Base Header, a 4-byte Service Path Header, and optional Context 206 Headers. 208 0 1 2 3 209 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 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | Base Header | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | Service Path Header | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | | 216 ~ Context Header(s) ~ 217 | | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 SFL Option Class = To be assigned by IANA 222 Type = To be assigned by IANA 224 'C' bit set, indicating endpoints must drop if they do not 225 recognize this option) 227 Length = variable. 229 Variable option data: 231 0 1 2 3 232 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 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 |Version|Flags |Reserved | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 ~ SF List[0] (32 or 128 bits IPv4/6 address) ~ 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | | 239 | | 240 ... 241 | | 242 | | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 ~ SF List [n] (32 or 128 bits IPv4/6 address) ~ 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 // // 247 // Optional sub-Type Length Value objects (variable) // 248 // // 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 Figure 1: Service Function List (SFL) Option TLV. 253 Reserved: 12 bits. SHOULD be unset on transmission and MUST be 254 ignored on receipt. 256 Flags: 257 0 1 2 3 4 5 6 7 258 +-+-+-+-+-+-+-+-+ 259 |H| Unused | 260 +-+-+-+-+-+-+-+-+ 261 Figure 2: SFL flags 263 H-flag: HMAC flag. If set, the HMAC sub-TLV is present and is 264 encoded as the last sub-TLV. 266 SF List[n]: 32 or 128 bits IPv4/6 addresses representing the nth 267 service function ip address in the List. 269 The SF List is encoded starting from the last hop of the path. I.e., 270 the first element of the list (SF List [0]) contains the last service 271 function of the path while the last element of the SF List (SF 272 List[n]) contains the first service function in the path. 274 HMAC sub-TLV is optional and contains the HMAC information. The 275 HMAC sub-TLV has the following format: 277 0 1 2 3 278 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 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Type | Length | Reserved | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | HMAC Key ID (4 octets) | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | // 285 | HMAC (32 octets) // 286 | // 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 Figure 3: SFL HMAC sub-TLV. 290 Type: to be assigned by IANA (suggested value 1). 291 Length: 38. 292 Reserved: 2 octets. SHOULD be unset on transmission and MUST be 293 ignored on receipt. 294 HMAC Key ID: 4 octets. 295 HMAC: 32 octets. 296 HMAC and HMAC Key ID usage is described in Operation section. 298 The Following applies to the HMAC TLV: 300 When present, the HMAC sub-TLV MUST be encoded as the last sub-TLV 302 If the HMAC sub-TLV is present, the H-Flag (Figure 2) MUST be set. 304 When the H-flag is set, the NVE inspecting the Geneve Service 305 Function List Option TLV MUST find the HMAC sub-TLV in the last 38 306 octets of the option TLV. 308 5.. Operation 310 The mechanisms described in this section should work with both ipv4 311 and ipv6 for both customer inner payload and Geneve tunnel packets. 313 5.1 Operation at Ingress 315 A Source NVE acting as a service function classifier and a service 316 function forwarder can be any node in an NVO3 domain, originating 317 based on a classification policy for some customer inner payload an 318 IP Geneve tunnel packet with the service function list (SFL) option 319 TLV. The service functions in the SFL represent the IP addresses of 320 the service functions that the inner customer packets needs to be 321 inspected by. A controller can program the ingress NVE node to 322 classify traffic and identify a service function paths i.e the set of 323 service functions in the path. The mechanism through which an SFL is 324 derived by a controller or any other mechanisms is outside of the 325 scope of this document. 327 The ingress NVE node fills in the list of service functions in the 328 path, to the Geneve Service Function List option TLV, putting the 329 first service function ip address as the last element in the list and 330 the last service function ip address as the first element, setting of 331 the NSH service index to the first element. The ingress NVE node, 332 then, resolves the service first function ip address, to the NVE 333 virtual tunnel endpoint node hosting or directly connected to the 334 service function. 336 The Geneve tunnel destination is then set to the NVE tunnel endpoint 337 hosting the first service function, and the service index is 338 decremented to n-1 (where n is the number of elements in the SFL), 339 and set on the SFL option TLV. An NSH metadata can also be set on the 340 packet by the NVE ingress node. 342 The Geneve packet is sent out towards the first NVE. 344 HMAC optional sub-TLV may be set too. 346 5.2 Operation at each NVE along the service function path 348 The NVE node along the service function path corresponding to the 349 Geneve tunnel destination of the packet, receives the packet, perform 350 the service function forwarder function and identifies the SFL 351 option, and locates the service function in the list based on the 352 service index. 354 The Geneve tunnel header and option TLV(s) will be stripped and the 355 packet will be delivered to the service function or virtual network 356 function VNF or CNF. The NVE maintains state related to the 357 association of the SFL option TLV and the NSH service path 358 identifier. The packet passed to the service function encaped with 359 the NSH header and NSH context, if the SF is NSH aware, other 360 encapsulations like vlan or q- in-q encap may be used to pass the 361 metadata and NSH SPI to the SF too. 363 When the packet comes back from the service function along with the 364 service path identifier (SPI) context, based on SPI on the packet the 365 NVE acting as the SFF will be able to locate the SFL option TLV. 367 If the metadata context indicate (1) that some service functions need 368 to be bypassed the NVE should bypass in the SFL the service functions 369 to be skipped and update the NSH service index accordingly. (2) A new 370 classification need to be performed on the packet, in that case the 371 NVE can re-classify the packet or sent it to an NVE node capable of 372 classification. 374 The NVE node, then, resolves the next service function ip address, to 375 the NVE virtual tunnel endpoint node hosting or directly connected to 376 the service function. 378 The NVE then sets the Geneve tunnel destination to the next NVE 379 tunnel endpoint, and the NSH service index is decremented by 1 and 380 set on the NSH Header, along with other NSH metadata option TLV. 382 The Geneve ip packet is sent out towards the next NVE. 384 5.3 Operation at Egress 386 At the last NVE node along the service function path, the NVE locates 387 the service function in the SFL option TLV based on the NSH service 388 index. The service index received at the last NVE node will be set to 389 1. 391 The Geneve tunnel header and option TLV(s) will be stripped and the 392 packet will be delivered to the service function. The NVE maintains 393 state related to the association of the SFL option TLV and the NSH 394 service path identifier. The packet passed to the service function 395 encaped with the NSH header and NSH context, if the SF is NSH aware, 396 other encapsulations like vlan or q-in-q encap may be used to pass 397 the metadata and NSH SPI to the SF too. 399 When the packet comes back from the service function, based on NSH 400 SPI on the packet or based the NVE will be able to locate the SFL 401 option TLV. 403 Given that the service index will be set to 1, the last NVE will now 404 deliver the packet to the NVE hosting or directly connected to the 405 inner packet destination. 407 A packet received with a service function index of 0 MUST be dropped. 409 6. Security Considerations 411 Only NVE(s) that are the destinations of the Geneve tunnel packet 412 will be inspecting the List of Service Function next hops Option. A 413 Source routing option has some well-known security issues as 414 described in [RFC4942] and [RFC5095]. 416 The main use case for the use of the Geneve List of Service Function 417 next hops Option will be within a single NVO3 administrative domain 418 where only trusted NVE nodes are enabled and configured participate, 419 this is the same model as in [RFC6554]. 421 NVE nodes MUST ignore the Geneve List of Service Function next hops 422 Option created by outsiders based on NVA or trusted control plane 423 information. 425 There is a need to prevent non-participating NVE node from using the 426 Geneve Service Function List option TLV, as described in [draft-ietf- 427 6man-segment-routing-header], we will use a security sub-TLV in the 428 Service Function List option TLV, the security sub-TLV will be based 429 on a key-hashed message authentication code (HMAC). 431 HMAC sub-TLV will contain: 433 HMAC Key-id, 32 bits wide; 435 HMAC, 256 bits wide (optional, exists only if HMAC Key-id is not 0). 437 The HMAC field is the output of the HMAC computation (per RFC 2104 438 [RFC2104]) using a pre-shared key identified by HMAC Key-id and of 439 the text which consists of the concatenation of: 441 The source IPv4/IPv6 Geneve tunnel address 443 Version and Flags 445 HMAC Key-id. 447 All addresses in the List. 449 The purpose of the HMAC optional sub-TLV is to verify the validity, 450 the integrity and the authorization of the Geneve Service Function 451 List option TLV itself. 453 The HMAC optional sub-TLV is located at the end of the Geneve Service 454 Function List option TLV. 456 The HMAC Key-id field serves as an index to the right combination of 457 pre-shared key and hash algorithm and except that a value of 0 means 458 that there is no HMAC field. 460 The HMAC Selection of a hash algorithm and Pre-shared key management 461 will follow the procedures described in [draft-ietf-6man-segment- 462 routing-header] section 6.2. 464 7. Management Considerations 465 The Source NVE can receive its information through any form of north 466 bound Orchestrator. These could be from any open networking 467 automation platform (ONAP) or others. The ingress to egress tunnel is 468 built and managed by the service function classifier and service 469 function forwarder by each node in an NVO3 domain. Error handling, is 470 handled by the classifier reporting to north bound management 471 systems. 473 8. Acknowledgements 475 The authors would like to acknowledge Jim Guichard for his feedback 476 and valuable comments to this document. 478 9. IANA Considerations 480 This document makes the following registrations in the "Geneve Option 481 Class" registry maintained by IANA: 483 Suggested Description Reference 484 Value 485 ---------------------------------------------------------- 486 XX Geneve List of Service Function next hops This document 488 In addition, this document request IANA to create and maintain a 489 new Registry: "Geneve List of Service Function next hops 490 Type-Value Objects". 492 The following code-point are requested from the registry: 494 Registry: Geneve List of Service Function next hops Type-Value 495 Objects 497 Suggested Description Reference 498 Value 499 ----------------------------------------------------- 500 1 HMAC TLV This document 502 10. References 504 10.1 Normative References 506 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 507 Requirement Levels", BCP 14, RFC 2119, March 1997. 509 10.2 Informative References 511 [Geneve] "Generic Network Virtualization Encapsulation", [I-D.ietf- 512 nvo3-geneve] 514 [RFC8300] Quinn, P., Elzur, U., and C. Pignataro, "Network Service 515 Header (NSH)", RFC 8300, January 2018, . 518 [RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 519 Transition/Co-existence Security Considerations", RFC 4942, DOI 520 10.17487/RFC4942, September 2007, . 523 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 524 Routing Header for Source Routes with the Routing Protocol for Low- 525 Power and Lossy Networks (RPL)", RFC 6554, DOI 10.17487/RFC6554, 526 March 2012, . 528 [draft-ietf-6man-segment-routing-header] Previdi, S., et all, "IPv6 529 Segment Routing Header (SRH)", July 20, 2017, draft-ietf-6man- 530 segment-routing-header-07 532 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 533 of Type 0 Routing Headers in IPv6", RFC 5095, DOI 10.17487/RFC5095, 534 December 2007, . 536 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 537 Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 538 2015, . 540 Authors' Addresses 542 Sami Boutros 543 VMware 544 Email: boutross@vmware.com 546 Dharma Rajan 547 VMware 548 Email: drajan@vmware.com 550 Philip Kippen 551 VMware 552 Email: pkippen@vmware.com 554 Pierluigi Rolando 555 VMware 556 Email: prolando@vmware.com 557 Jim Guichard 558 Huawei 559 Email: james.n.guichard@huawei.com 561 Sam Aldrin 562 Google 563 Email:aldrin.ietf@gmail.com