idnits 2.17.1 draft-boutros-nvo3-geneve-applicability-for-sfc-03.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 (March 6, 2019) is 1878 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 145, but not defined -- Looks like a reference, but probably isn't: '0' on line 268 == Missing Reference: 'RFC2104' is mentioned on line 436, but not defined == Unused Reference: 'KEYWORDS' is defined on line 504, but no explicit reference was found in the text == Unused Reference: 'Geneve' is defined on line 509, 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: September 7, 2019 March 6, 2019 15 Geneve applicability for service function chaining 16 draft-boutros-nvo3-geneve-applicability-for-sfc-03 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 implementing service functions, or 105 on physical routers connected to service function appliances. NVO3 106 domain uses tunneling and encapsulation protocols such as Geneve to 107 provide connectivity for tenants workloads and service function 108 running in its domain. NVEs in an NVO3 domain are typically 109 controlled by a centralized network virtualization authority NVA. 111 [RFC8300] defines a new encapsulation protocol, network service 112 header (NSH) to encode the SFP and the metadata. 114 1.1 Requirement for SFC in NVO3 domain 116 The requirement is to provide service function chaining in an NVO3 117 domain without the need to implement yet another control plane for 118 service topology. 120 1.2 Proposed solution for SFC in NVO3 domain 122 This document specifies the applicability of using Generic Network 123 Virtualization Encapsulation (Geneve), to carry the service function 124 path (SFP) information, and the network service header (NSH) 125 encapsulation. 127 The SFP will be implemented using a new Geneve Service Function List 128 (SFL) option for use strictly between Network Virtualization Edges 129 (NVEs) performing the service forwarding function (SFF) in the same 130 Network Virtualization Overlay over Layer 3 NVO3 domain. The next 131 protocol in the Geneve Header will be the NSH EtherType, 0x894F. The 132 NSH encapsulation will include the Service Path Identifier (SPI) and 133 the Service Index (SI). The NSH SI will serve as an index to the VNF 134 hop to visit in the SFL. 136 In the absence of the SFL we would need a service topology control 137 plane. The Geneve overlay will encap the NSH encapsulation and the 138 next protocol on Geneve will be the NSH Ethertype. 140 2. Terminology 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in RFC 2119 [RFC2119]. 146 3. Abbreviations 148 NVO3 Network Virtualization Overlays over Layer 3 150 OAM Operations, Administration, and Maintenance 152 TLV Type, Length, and Value 154 VNI Virtual Network Identifier 156 NVE Network Virtualization Edge 158 NVA Network Virtualization Authority 160 NIC Network interface card 162 VTEP Virtual Tunnel End Point 164 Transit device Underlay network devices between NVE(s). 166 Service Function (SF): Defined in [RFC7665]. 168 Service Function Chain (SFC): Defined in [RFC7665]. 170 Service Function Forwarder (SFF): Defined in [RFC7665]. 172 Service Function Path (SFP): Defined in [RFC7665]. 174 Metadata: Defined in [[draft-ietf-sfc-nsh] 176 NFV: Network function virtualization. 178 VNF: Virtual network function 180 4. Geneve Option TLV(s) 182 4.1 Geneve Service Function List (SFL) Option TLV 184 Geneve Header: 186 0 1 2 3 187 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 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 |Ver| Opt Len |O|C| Rsvd. |Protocol Type = NSH Ethertype | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | Virtual Network Identifier (VNI) | Reserved | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 Geneve Option Header: 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | SFL Option Class | Type |R|R|R| Length | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | Variable Option Data | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 Followed by the NSH encapsulation which is composed of a 4-byte 203 Base Header, a 4-byte Service Path Header, and optional Context 204 Headers. 206 0 1 2 3 207 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 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | Base Header | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | Service Path Header | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | | 214 ~ Context Header(s) ~ 215 | | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 SFL Option Class = To be assigned by IANA 220 Type = To be assigned by IANA 222 'C' bit set, indicating endpoints must drop if they do not 223 recognize this option) 225 Length = variable. 227 Variable option data: 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 |Version|Flags |Reserved | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 ~ SF List[0] (32 or 128 bits IPv4/6 address) ~ 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | | 237 | | 238 ... 239 | | 240 | | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 ~ SF List [n] (32 or 128 bits IPv4/6 address) ~ 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 // // 245 // Optional sub-Type Length Value objects (variable) // 246 // // 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 Figure 1: Service Function List (SFL) Option TLV. 251 Reserved: 12 bits. SHOULD be unset on transmission and MUST be 252 ignored on receipt. 254 Flags: 255 0 1 2 3 4 5 6 7 256 +-+-+-+-+-+-+-+-+ 257 |H| Unused | 258 +-+-+-+-+-+-+-+-+ 259 Figure 2: SFL flags 261 H-flag: HMAC flag. If set, the HMAC sub-TLV is present and is 262 encoded as the last sub-TLV. 264 SF List[n]: 32 or 128 bits IPv4/6 addresses representing the nth 265 service function ip address in the List. 267 The SF List is encoded starting from the last hop of the path. I.e., 268 the first element of the list (SF List [0]) contains the last service 269 function of the path while the last element of the SF List (SF 270 List[n]) contains the first service function in the path. 272 HMAC sub-TLV is optional and contains the HMAC information. The 273 HMAC sub-TLV has the following format: 275 0 1 2 3 276 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 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Type | Length | Reserved | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | HMAC Key ID (4 octets) | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | // 283 | HMAC (32 octets) // 284 | // 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 Figure 3: SFL HMAC sub-TLV. 288 Type: to be assigned by IANA (suggested value 1). 289 Length: 38. 290 Reserved: 2 octets. SHOULD be unset on transmission and MUST be 291 ignored on receipt. 292 HMAC Key ID: 4 octets. 293 HMAC: 32 octets. 294 HMAC and HMAC Key ID usage is described in Operation section. 296 The Following applies to the HMAC TLV: 298 When present, the HMAC sub-TLV MUST be encoded as the last sub-TLV 300 If the HMAC sub-TLV is present, the H-Flag (Figure 2) MUST be set. 302 When the H-flag is set, the NVE inspecting the Geneve Service 303 Function List Option TLV MUST find the HMAC sub-TLV in the last 38 304 octets of the option TLV. 306 5.. Operation 308 The mechanisms described in this section should work with both ipv4 309 and ipv6 for both customer inner payload and Geneve tunnel packets. 311 5.1 Operation at Ingress 313 A Source NVE acting as a service function classifier and a service 314 function forwarder can be any node in an NVO3 domain, originating 315 based on a classification policy for some customer inner payload an 316 IP Geneve tunnel packet with the service function list (SFL) option 317 TLV. The service functions in the SFL represent the IP addresses of 318 the service functions that the inner customer packets needs to be 319 inspected by. A controller can program the ingress NVE node to 320 classify traffic and identify a service function paths i.e the set of 321 service functions in the path. The mechanism through which an SFL is 322 derived by a controller or any other mechanisms is outside of the 323 scope of this document. 325 The ingress NVE node fills in the list of service functions in the 326 path, to the Geneve Service Function List option TLV, putting the 327 first service function ip address as the last element in the list and 328 the last service function ip address as the first element, setting of 329 the NSH service index to the first element. The ingress NVE node, 330 then, resolves the service first function ip address, to the NVE 331 virtual tunnel endpoint node hosting or directly connected to the 332 service function. 334 The Geneve tunnel destination is then set to the NVE tunnel endpoint 335 hosting the first service function, and the service index is 336 decremented to n-1 (where n is the number of elements in the SFL), 337 and set on the SFL option TLV. An NSH metadata can also be set on the 338 packet by the NVE ingress node. 340 The Geneve packet is sent out towards the first NVE. 342 HMAC optional sub-TLV may be set too. 344 5.2 Operation at each NVE along the service function path 346 The NVE node along the service function path corresponding to the 347 Geneve tunnel destination of the packet, receives the packet, perform 348 the service function forwarder function and identifies the SFL 349 option, and locates the service function in the list based on the 350 service index. 352 The Geneve tunnel header and option TLV(s) will be stripped and the 353 packet will be delivered to the service function or virtual network 354 function (VNF). The NVE maintains state related to the association of 355 the SFL option TLV and the NSH service path identifier. The packet 356 passed to the service function encaped with the NSH header and NSH 357 context, if the SF is NSH aware, other encapsulations like vlan or q- 358 in-q encap may be used to pass the metadata and NSH SPI to the SF 359 too. 361 When the packet comes back from the service function along with the 362 service path identifier (SPI) context, based on SPI on the packet the 363 NVE acting as the SFF will be able to locate the SFL option TLV. 365 If the metadata context indicate (1) that some service functions need 366 to be bypassed the NVE should bypass in the SFL the service functions 367 to be skipped and update the NSH service index accordingly. (2) A new 368 classification need to be performed on the packet, in that case the 369 NVE can re-classify the packet or sent it to an NVE node capable of 370 classification. 372 The NVE node, then, resolves the next service function ip address, to 373 the NVE virtual tunnel endpoint node hosting or directly connected to 374 the service function. 376 The NVE then sets the Geneve tunnel destination to the next NVE 377 tunnel endpoint, and the NSH service index is decremented by 1 and 378 set on the NSH Header, along with other NSH metadata option TLV. 380 The Geneve ip packet is sent out towards the next NVE. 382 5.3 Operation at Egress 384 At the last NVE node along the service function path, the NVE locates 385 the service function in the SFL option TLV based on the NSH service 386 index. The service index received at the last NVE node will be set to 387 1. 389 The Geneve tunnel header and option TLV(s) will be stripped and the 390 packet will be delivered to the service function. The NVE maintains 391 state related to the association of the SFL option TLV and the NSH 392 service path identifier. The packet passed to the service function 393 encaped with the NSH header and NSH context, if the SF is NSH aware, 394 other encapsulations like vlan or q-in-q encap may be used to pass 395 the metadata and NSH SPI to the SF too. 397 When the packet comes back from the service function, based on NSH 398 SPI on the packet or based the NVE will be able to locate the SFL 399 option TLV. 401 Given that the service index will be set to 1, the last NVE will now 402 deliver the packet to the NVE hosting or directly connected to the 403 inner packet destination. 405 A packet received with a service function index of 0 MUST be dropped. 407 6. Security Considerations 409 Only NVE(s) that are the destinations of the Geneve tunnel packet 410 will be inspecting the List of Service Function next hops Option. A 411 Source routing option has some well-known security issues as 412 described in [RFC4942] and [RFC5095]. 414 The main use case for the use of the Geneve List of Service Function 415 next hops Option will be within a single NVO3 administrative domain 416 where only trusted NVE nodes are enabled and configured participate, 417 this is the same model as in [RFC6554]. 419 NVE nodes MUST ignore the Geneve List of Service Function next hops 420 Option created by outsiders based on NVA or trusted control plane 421 information. 423 There is a need to prevent non-participating NVE node from using the 424 Geneve Service Function List option TLV, as described in [draft-ietf- 425 6man-segment-routing-header], we will use a security sub-TLV in the 426 Service Function List option TLV, the security sub-TLV will be based 427 on a key-hashed message authentication code (HMAC). 429 HMAC sub-TLV will contain: 431 HMAC Key-id, 32 bits wide; 433 HMAC, 256 bits wide (optional, exists only if HMAC Key-id is not 0). 435 The HMAC field is the output of the HMAC computation (per RFC 2104 436 [RFC2104]) using a pre-shared key identified by HMAC Key-id and of 437 the text which consists of the concatenation of: 439 The source IPv4/IPv6 Geneve tunnel address 441 Version and Flags 443 HMAC Key-id. 445 All addresses in the List. 447 The purpose of the HMAC optional sub-TLV is to verify the validity, 448 the integrity and the authorization of the Geneve Service Function 449 List option TLV itself. 451 The HMAC optional sub-TLV is located at the end of the Geneve Service 452 Function List option TLV. 454 The HMAC Key-id field serves as an index to the right combination of 455 pre-shared key and hash algorithm and except that a value of 0 means 456 that there is no HMAC field. 458 The HMAC Selection of a hash algorithm and Pre-shared key management 459 will follow the procedures described in [draft-ietf-6man-segment- 460 routing-header] section 6.2. 462 7. Management Considerations 463 The Source NVE can receive its information through any form of north 464 bound Orchestrator. These could be from any open networking 465 automation platform (ONAP) or others. The ingress to egress tunnel is 466 built and managed by the service function classifier and service 467 function forwarder by each node in an NVO3 domain. Error handling, is 468 handled by the classifier reporting to north bound management 469 systems. 471 8. Acknowledgements 473 The authors would like to acknowledge Jim Guichard for his feedback 474 and valuable comments to this document. 476 9. IANA Considerations 478 This document makes the following registrations in the "Geneve Option 479 Class" registry maintained by IANA: 481 Suggested Description Reference 482 Value 483 ---------------------------------------------------------- 484 XX Geneve List of Service Function next hops This document 486 In addition, this document request IANA to create and maintain a 487 new Registry: "Geneve List of Service Function next hops 488 Type-Value Objects". 490 The following code-point are requested from the registry: 492 Registry: Geneve List of Service Function next hops Type-Value 493 Objects 495 Suggested Description Reference 496 Value 497 ----------------------------------------------------- 498 1 HMAC TLV This document 500 10. References 502 10.1 Normative References 504 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 505 Requirement Levels", BCP 14, RFC 2119, March 1997. 507 10.2 Informative References 509 [Geneve] "Generic Network Virtualization Encapsulation", [I-D.ietf- 510 nvo3-geneve] 512 [RFC8300] Quinn, P., Elzur, U., and C. Pignataro, "Network Service 513 Header (NSH)", RFC 8300, January 2018, . 516 [RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 517 Transition/Co-existence Security Considerations", RFC 4942, DOI 518 10.17487/RFC4942, September 2007, . 521 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 522 Routing Header for Source Routes with the Routing Protocol for Low- 523 Power and Lossy Networks (RPL)", RFC 6554, DOI 10.17487/RFC6554, 524 March 2012, . 526 [draft-ietf-6man-segment-routing-header] Previdi, S., et all, "IPv6 527 Segment Routing Header (SRH)", July 20, 2017, draft-ietf-6man- 528 segment-routing-header-07 530 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 531 of Type 0 Routing Headers in IPv6", RFC 5095, DOI 10.17487/RFC5095, 532 December 2007, . 534 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 535 Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 536 2015, . 538 Authors' Addresses 540 Sami Boutros 541 VMware 542 Email: sboutros@vmware.com 544 Dharma Rajan 545 VMware 546 Email: drajan@vmware.com 548 Philip Kippen 549 VMware 550 Email: pkippen@vmware.com 552 Pierluigi Rolando 553 VMware 554 Email: prolando@vmware.com 555 Jim Guichard 556 Huawei 557 Email: james.n.guichard@huawei.com 559 Sam Aldrin 560 Google 561 Email:aldrin.ietf@gmail.com