idnits 2.17.1 draft-wu-pce-traffic-steering-sfc-11.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 9, 2017) is 2599 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) == Unused Reference: 'RFC2753' is defined on line 457, but no explicit reference was found in the text == Unused Reference: 'RFC5394' is defined on line 467, but no explicit reference was found in the text == Outdated reference: A later version (-21) exists of draft-ietf-pce-stateful-pce-18 == Outdated reference: A later version (-11) exists of draft-ietf-pce-pce-initiated-lsp-09 == Outdated reference: A later version (-05) exists of draft-ietf-teas-pce-central-control-01 ** Downref: Normative reference to an Informational draft: draft-ietf-teas-pce-central-control (ref. 'I-D.ietf-teas-pce-central-control') == Outdated reference: A later version (-16) exists of draft-ietf-pce-segment-routing-08 == Outdated reference: A later version (-28) exists of draft-ietf-sfc-nsh-12 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group Q. Wu 3 Internet-Draft D. Dhody 4 Intended status: Standards Track Huawei 5 Expires: September 10, 2017 M. Boucadair 6 C. Jacquenet 7 Orange 8 J. Tantsura 9 March 9, 2017 11 PCEP Extensions for Service Function Chaining (SFC) 12 draft-wu-pce-traffic-steering-sfc-11 14 Abstract 16 This document provides an overview of the usage of Path Computation 17 Element (PCE) to dynamically structure service function chains. 18 Service Function Chaining (SFC) is a technique that is meant to 19 facilitate the dynamic enforcement of differentiated traffic 20 forwarding policies within a domain. Service function chains are 21 composed of an ordered set of elementary Service Functions (such as 22 firewalls, load balancers) that need to be invoked according to the 23 design of a given service. Corresponding traffic is thus forwarded 24 along a Service Function Path (SFP) that can be computed by means of 25 PCE. 27 This document specifies extensions to the Path Computation Element 28 Protocol (PCEP) that allow a stateful PCE to compute and instantiate 29 Service Function Paths. 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 http://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 September 10, 2017. 48 Copyright Notice 50 Copyright (c) 2017 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 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Conventions used in this document . . . . . . . . . . . . . . 3 67 3. Service Function Paths and PCE . . . . . . . . . . . . . . . 4 68 4. Overview of PCEP Operation in SFC-Enabled Networks . . . . . 6 69 4.1. SFP Instantiation . . . . . . . . . . . . . . . . . . . . 6 70 4.2. SFP Withdrawal . . . . . . . . . . . . . . . . . . . . . 6 71 4.3. SFP Delegation and Cleanup . . . . . . . . . . . . . . . 7 72 4.4. SFP State Synchronization . . . . . . . . . . . . . . . . 7 73 4.5. SFP Update and Report . . . . . . . . . . . . . . . . . . 7 74 5. Object Formats . . . . . . . . . . . . . . . . . . . . . . . 7 75 5.1. The OPEN Object . . . . . . . . . . . . . . . . . . . . . 7 76 5.2. The LSP Object . . . . . . . . . . . . . . . . . . . . . 8 77 5.2.1. SFP Identifiers TLV . . . . . . . . . . . . . . . . . 8 78 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . 9 79 7. SFP Instantiation Signaling and Forwarding Considerations . . 9 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 81 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 82 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 83 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 84 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 85 11.2. Informative References . . . . . . . . . . . . . . . . . 11 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 88 1. Introduction 90 Service Function Chaining (SFC) enables the creation of composite 91 services that consist of an ordered set of Service Functions (SF) 92 that must be applied to packets and/or frames and/or flows selected 93 as a result of service-inferred traffic classification as described 94 in [RFC7665]. A Service Function Path (SFP) is a path along which 95 traffic that is bound to a specific service function chain will be 96 forwarded. Packets typically follow a Service Function Path from a 97 classifier through the Service Functions (SF) that need to be invoked 98 according to the SFC instructions. Forwarding decisions are made by 99 Service Function Forwarders (SFF) according to such instructions. 101 [RFC5440] describes the Path Computation Element Protocol (PCEP) as 102 the protocol used by a Path Computation Client (PCC) and a Path 103 Control Element (PCE) to exchange information, thereby enabling the 104 computation of Multiprotocol Label Switching (MPLS) for Traffic 105 Engineering Label Switched Path (TE LSP), in particular. 107 [I-D.ietf-pce-stateful-pce] specifies extensions to PCEP to enable a 108 stateful control of MPLS TE LSPs. [I-D.ietf-pce-pce-initiated-lsp] 109 provides the extensions needed for stateful PCE-initiated LSP 110 instantiation. 112 This document specifies PCEP extensions that allow a stateful PCE to 113 compute and instantiate traffic-engineered Service Function Paths 114 (SFP). 116 2. Conventions used in this document 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in RFC2119 [RFC2119]. 122 This document makes use of these acronyms: 124 PCC: Path Computation Client. 126 PCE: Path Computation Element. 128 PCEP: Path Computation Element Protocol. 130 PDP: Policy Decision Point. 132 SF: Service Function. 134 SFC: Service Function Chain. 136 SFP: Service Function Path. 138 RSP: Rendered Service Path. 140 SFF: Service Function Forwarder. 142 UNI: User-Network Interface. 144 3. Service Function Paths and PCE 146 Service function chains are constructed as a sequence of SFs, where a 147 SF can be virtualized or embedded in a physical network element. One 148 or several SFs may be supported by the same physical network element. 149 A SFC creates an abstracted view of a service and specifies the set 150 of required SFs as well as the order in which they must be executed. 152 When an SFC is created, it is necessary to select the specific 153 instances of SFs that will be used. A service function path for that 154 SFC will then be established (notion of rendered service path) or can 155 be precomputed, based upon the sequence of SFs that need to be 156 invoked by the corresponding traffic, i.e., the traffic that is bound 157 to the corresponding SFC. Note that a SF instance can be serviced by 158 one or multiple SFFs. One or multiple SF instances can be serviced 159 by one SFF. Thus, the instantiation of an SFC results in the 160 establishment of a Service Function Path, either in a hop-by-hop 161 fashion, or by means of traffic-engineering capabilities. In the 162 latter case, the SFP is precomputed, i.e., an SFP is an instantiation 163 of the defined SFC as described in [RFC7665]. 165 The computation, the selection, and the establishment of a traffic- 166 engineered SFP can rely upon a set of (service-specific) policies 167 (forwarding and routing, QoS, security, etc., or a combination 168 thereof). Stateful PCE with appropriate SFC-aware PCEP extensions 169 can be used to compute traffic-engineered SFPs. 171 SFC Control Plane 172 +------------------------+ 173 |PCE based Controller | 174 I2 | +-------++-------+ | 175 +------------- |Policy || TE-DB | | 176 | I1 | +-------++-------+ <----+ 177 | +----------| +-------------+ | | 178 | |SFP | |LSP-DB/SFP-DB| | |I2 179 | |Instan- | +-------------+ | | 180 | |tiation +-----------^------------+ |policy-provisioning 181 | |PCEP | |information/ 182 | |Signaling I2 | |Carried by NETCONF, 183 | | | |BGP, for example 184 | | | | 185 | | | | 186 | | +------V+ +----+--+ 187 V V | | | | 188 +-----+ Forwarding| | Forwarding| | Forwarding 189 | SFC |----------->| SFF-1 | --------->| SFF-2 |-----------> 190 Classifier | | | | 191 | | | | | | 192 +-----+ ++-----++ +-----+-+ 193 | | | 194 +--+--+ ++----+ +--+--+ 195 |SF-1 | |SF-2 | |SF-3 | 196 | | | | | | 197 +--+--+ +---+-+ +--+--+ 198 |I2 |I2 |I2 199 V V V 201 Figure 1: PCE-based SFP instantiation 203 In Figure 1, the PCE-based Controller [I-D.ietf-teas-pce-central- 204 control] in the SFC Control plane is responsible for computing the 205 path for a given service function chain. This PCE-based controller 206 can operate as a stateful PCE ([I-D.draft_ietf-stateful-pce]) that 207 will provide a classifier (a headend from a PCE standpoint) with the 208 PCEP-formatted information to instantiate a given SFP. As a 209 consequence, the PCE-based controller derives the set of policy- 210 provisioning information (namely SFP configuration information and 211 traffic classification rules) that will be provided to the various 212 elements (Classifier, SFF) involved in the establishment of the SFP. 214 By doing so, SFC Classifier can bind a flow to a service function 215 chain and forward such flow along the corresponding SFP. The SFC 216 Control Plane [I-D.ietf-sfc-control-plane] is also responsible for 217 defining the appropriate policies (traffic classification, forwarding 218 and routing, etc.) that will be enforced by SFC Classifiers,SFF Nodes 219 and SF Nodes, as described in [RFC7665]. From that standpoint, the 220 SFC Control Plane embeds a Policy Decision Point that is responsible 221 for defining the SFC policies. SFC policies will be provided by the 222 PDP and enforced by SFC components like classifiers and SFFs by means 223 of policy-provision information. A protocol like NETCONF, BGP can be 224 used to carry such policy-provisioning information. 226 4. Overview of PCEP Operation in SFC-Enabled Networks 228 A PCEP speaker indicates its ability to support PCE-computed SFP 229 paths during the PCEP Initialization phase via a mechanism described 230 in Section 5.1. A PCE may initiate SFPs only for PCCs that 231 advertised this capability; a PCC follows the procedures described in 232 this document only for sessions where the PCE advertised this 233 capability. 235 As per Section 5.1 of [I-D.ietf-pce-pce-initiated-lsp], the PCE sends 236 a Path Computation LSP Initiate Request (PCInitiate) message to the 237 PCC to instantiate or delete a LSP. The Explicit Route Object (ERO) 238 is used to encode either a full sequence of SF instances or a 239 specific sequence of SFFs and SFs to establish an SFP. If the said 240 SFFs and SFs are identified with an IP address, the IP sub-object can 241 be used as a SF/SFF identification means. This document makes no 242 change to the PCInitiate message format but extends LSP objects 243 described in Section 5.2. 245 Editor's note: In case a PCE-Initiated signaling mechanism is used to 246 set up the service function path, does the classifier / PCE-Initiated 247 signaling protocol need to understand whether an IP address is 248 assigned to a SFF or a SF, or the signaling protocol is only used to 249 signal IP addresses for SFs? 251 To prevent multiple classifiers assign the same SFP ID to one Service 252 Function Path(SFP ID assignment conflict),in this document, we assume 253 SFP ID can be predetermined and assigned by stateful PCE when 254 stateful PCE can be used to compute traffic-engineered SFPs. 256 4.1. SFP Instantiation 258 The instantiation of a SFP is the same as defined in Section 5.3 of 259 [I-D.ietf-pce-pce-initiated-lsp]. Rules for processing and error 260 codes remain unchanged. 262 4.2. SFP Withdrawal 264 The withdrawal of an SFP is the same as defined in Section 5.4 of 265 [I-D.ietf-pce-pce-initiated-lsp]: the PCE sends an LSP Initiate 266 Message with an LSP object carrying the PLSP-ID of the SFP and the 267 SFP Identifier to be removed, as well as an SRP object with the R 268 flag set (LSP-REMOVE as per Section 5.2 of 269 [I-D.ietf-pce-pce-initiated-lsp]). Rules for processing and error 270 codes remain unchanged. 272 4.3. SFP Delegation and Cleanup 274 SFP delegation and cleanup operations are similar to those defined in 275 Section 6 of [I-D.ietf-pce-pce-initiated-lsp]. Rules for processing 276 and error codes remain unchanged. 278 4.4. SFP State Synchronization 280 State Synchronization operations described in Section 5.4 of 281 [I-D.ietf-pce-stateful-pce] can be applied to SFP state maintenance 282 as well. 284 4.5. SFP Update and Report 286 A PCE can send an SFP Update request to a PCC to update one or more 287 attributes of an SFP and to re-signal the SFP with the updated 288 attributes. A PCC can send an SFP state report to a PCE, and which 289 contains the SFP State information. The mechanism is described in 290 [I-D.ietf-pce-stateful-pce] and can be applied to SFPs as well. 292 5. Object Formats 294 5.1. The OPEN Object 296 The optional TLV shown in Figure 2 is defined for use in the OPEN 297 Object to indicate the PCEP speaker's Service Function Chaining 298 capability. 300 The SFC-PCE-CAPABILITY TLV is an optional TLV to be carried in the 301 OPEN Object to advertise the SFC capability during the PCEP session. 303 0 1 2 3 304 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 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | Type=TBD | length=4 | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | Reserved | Flags | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 SFC-PCE-CAPABILITY TLV Format 313 The code point for the TLV type is to be defined by IANA (see 314 Section 9). The TLV length is 4 octets. 316 As per [I-D.ietf-pce-stateful-pce], a PCEP speaker advertises the 317 capability of instantiating PCE-initiated LSPs via the Stateful PCE 318 Capability TLV (LSP-INSTANTIATION-CAPABILITY bit) carried in an Open 319 message. The inclusion of the SFC-PCE-CAPABILITY TLV in an OPEN 320 object indicates that the sender is SFC-capable. Both mechanisms 321 indicate the SFP instantiation capability of the PCEP speaker. 323 5.2. The LSP Object 325 The LSP object is defined in [I-D.ietf-pce-pce-initiated-lsp] and 326 included here for reference (Figure 3). 328 0 1 2 3 329 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 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | PLSP-ID | Flags |F|C| O|A|R|S|D| 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 // TLVs // 334 | | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 LSP Object Format 339 A new flag, called the SFC flag (F-bit), is introduced. The F-bit 340 set to "1" indicates that this LSP is actually an SFP. The C flag 341 will also be set to indicate it was created via a PCInitiate message. 343 5.2.1. SFP Identifiers TLV 345 As described in section 4, SFP ID is predetermined and assigned by 346 stateful PCE. The SFP Identifiers TLV MUST be included in the LSP 347 object for SFPs. The SFP Identifier TLV is used by the classifier to 348 select the SFP along which some traffic will be forwarded, according 349 to the traffic classification rules applied by the classifier 350 [RFC7665]. The SFP Identifier is part of the SFC metadata carried in 351 packets and is used by the SFF to invoke service functions and 352 identify the next SFF. 354 The format of the SFP Identifier TLV is shown in Figure 4. 356 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 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | Service Path ID | Service Index | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 Service Path ID (SPI): 24 bits 362 Service Index (SI): 8 bits 364 Figure 4 366 SPI: identifies a service path. The same ID is used by the 367 participating nodes for path setup/selection. An administrator can 368 use the SPI for reporting and troubleshooting packets along a 369 specific path. SPI along with PLSP-ID is used by PCEP to identify 370 the Service Path. 372 SI: provides location within the service path. 374 6. Backward Compatibility 376 The SFP instantiation capability defined as a PCEP extension and 377 documented in this draft MUST NOT be used if PCCs or the PCE did not 378 advertise their stateful SFP instantiation capability,Section 5.1. 379 If this is not the case and stateful operations on SFPs are 380 attempted, then a PCErr message with error-type 19 (Invalid 381 Operation) and error-value TBD needs to be generated. 383 [Editor's note: more information on exact error value is needed] 385 7. SFP Instantiation Signaling and Forwarding Considerations 387 The PCE-initiated SFP instantiation signaling described in this 388 document does not assume any specific mechanism to exchange SFP 389 information(e.g.,path identification 390 information,metadata[I-D.ietf-sfc-nsh]) and establish SFP in the data 391 plane throughout a SFC domain. For example, such mechanism can rely 392 upon the use of the SFC Encapsulation defined in [I-D.ietf-sfc-nsh]. 393 Likewise, [I-D.ietf-teas-pce-central-control] can use the signaling 394 mechanism described in this draft to enforce SFC-inferred traffic 395 engineering policies and provide load balancing between service 396 function nodes. The approach that relies upon the Segment Routing 397 technique [I-D.ietf-pce-segment-routing] can also take advantage of 398 the signaling mechanism described in this document to support Service 399 Path instantiation, which does not require any additional specific 400 extension to the Segment Routing machinery. 402 8. Security Considerations 404 The security considerations described in [RFC5440] and 405 [I-D.ietf-pce-pce-initiated-lsp] are applicable to this 406 specification. This document does not raise any additional security 407 issue. 409 9. IANA Considerations 411 IANA is requested to allocate a new code point in the PCEP TLV Type 412 Indicators registry, as follows: 414 Value Meaning Reference 415 ------- ---------------------------- -------------- 416 TBD SFC-PCE-CAPABILITY This document 418 10. Acknowledgements 420 Many thanks to Ron Parker, Hao Wang, Dave Dolson, Jing Huang, and 421 Joel M. Halpern for the discussion about the content for the 422 document. 424 11. References 426 11.1. Normative References 428 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 429 Requirement Levels", BCP 14, RFC 2119, 430 DOI 10.17487/RFC2119, March 1997, 431 . 433 [I-D.ietf-pce-stateful-pce] 434 Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP 435 Extensions for Stateful PCE", draft-ietf-pce-stateful- 436 pce-18 (work in progress), December 2016. 438 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 439 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 440 DOI 10.17487/RFC5440, March 2009, 441 . 443 [I-D.ietf-pce-pce-initiated-lsp] 444 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 445 Extensions for PCE-initiated LSP Setup in a Stateful PCE 446 Model", draft-ietf-pce-pce-initiated-lsp-09 (work in 447 progress), March 2017. 449 [I-D.ietf-teas-pce-central-control] 450 Farrel, A., Zhao, Q., Li, Z., and C. Zhou, "An 451 Architecture for Use of PCE and PCEP in a Network with 452 Central Control", draft-ietf-teas-pce-central-control-01 453 (work in progress), December 2016. 455 11.2. Informative References 457 [RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework 458 for Policy-based Admission Control", RFC 2753, 459 DOI 10.17487/RFC2753, January 2000, 460 . 462 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 463 Chaining (SFC) Architecture", RFC 7665, 464 DOI 10.17487/RFC7665, October 2015, 465 . 467 [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, 468 "Policy-Enabled Path Computation Framework", RFC 5394, 469 DOI 10.17487/RFC5394, December 2008, 470 . 472 [I-D.ietf-sfc-control-plane] 473 Boucadair, M., "Service Function Chaining (SFC) Control 474 Plane Components & Requirements", draft-ietf-sfc-control- 475 plane-08 (work in progress), October 2016. 477 [I-D.ietf-pce-segment-routing] 478 Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E., 479 Raszuk, R., Lopez, V., Tantsura, J., Henderickx, W., and 480 J. Hardwick, "PCEP Extensions for Segment Routing", draft- 481 ietf-pce-segment-routing-08 (work in progress), October 482 2016. 484 [I-D.ietf-sfc-nsh] 485 Quinn, P. and U. Elzur, "Network Service Header", draft- 486 ietf-sfc-nsh-12 (work in progress), February 2017. 488 Authors' Addresses 490 Qin Wu 491 Huawei 492 101 Software Avenue, Yuhua District 493 Nanjing, Jiangsu 210012 494 China 496 EMail: bill.wu@huawei.com 497 Dhruv Dhody 498 Huawei 499 Leela Palace 500 Bangalore, Karnataka 560008 501 INDIA 503 EMail: dhruv.ietf@gmail.com 505 Mohamed Boucadair 506 Orange 507 Rennes 35000 508 France 510 EMail: mohamed.boucadair@orange.com 512 Christian Jacquenet 513 Orange 514 Rennes 515 France 517 EMail: christian.jacquenet@orange.com 519 Jeff Tantsura 520 2330 Central Expressway 521 Santa Clara, CA 95050 522 US 524 EMail: jefftant.ietf@gmail.com