idnits 2.17.1 draft-ietf-pce-pcep-stateful-pce-gmpls-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 40 has weird spacing: '... months and ...' == Line 41 has weird spacing: '... at any time...' == Line 42 has weird spacing: '...ference mate...' == Line 298 has weird spacing: '...orm the re-...' -- The document date (March 7, 2019) is 1877 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: 'RFC 5440' is mentioned on line 110, but not defined == Missing Reference: 'RFC7399' is mentioned on line 117, but not defined == Missing Reference: 'RFC5521' is mentioned on line 341, but not defined == Missing Reference: 'RFC7025' is mentioned on line 464, but not defined ** Downref: Normative reference to an Informational RFC: RFC 4655 Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PCE Working Group Young Lee (Editor) 2 Internet-Draft Fatai Zhang 3 Intended status: Standards Track Huawei 4 Ramon Casellas 5 CTTC 6 Oscar Gonzalez de Dios 7 Telefonica I+D 8 Zafar Ali 9 Cisco Systems 11 March 7, 2019 13 Path Computation Element (PCE) Protocol Extensions for Stateful PCE 14 Usage in GMPLS-controlled Networks 16 draft-ietf-pce-pcep-stateful-pce-gmpls-10 18 Abstract 20 The Path Computation Element (PCE) facilitates Traffic Engineering 21 (TE) based path calculation in large, multi-domain, multi-region, or 22 multi-layer networks. The PCE communication Protocol (PCEP) has been 23 extended to support stateful PCE functions where the PCE retains 24 information about the paths already present in the network, but 25 those extensions are technology-agnostic. This memo provides 26 extensions required for PCEP so as to enable the usage of a stateful 27 PCE capability in GMPLS-controlled networks. 29 Status of this Memo 31 This Internet-Draft is submitted to IETF in full conformance with 32 the provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF), its areas, and its working groups. Note that 36 other groups may also distribute working documents as Internet- 37 Drafts. 39 Internet-Drafts are draft documents valid for a maximum of six 40 months and may be updated, replaced, or obsoleted by other 41 documents at any time. It is inappropriate to use Internet-Drafts 42 as reference material or to cite them other than as "work in 43 progress." 44 The list of current Internet-Drafts can be accessed at 45 http://www.ietf.org/ietf/1id-abstracts.txt. 47 The list of Internet-Draft Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html. 50 This Internet-Draft will expire on September 7, 2019. 52 Copyright Notice 54 Copyright (c) 2019 IETF Trust and the persons identified as the 55 document authors. All rights reserved. 57 This document is subject to BCP 78 and the IETF Trust's Legal 58 Provisions Relating to IETF Documents 59 (http://trustee.ietf.org/license-info) in effect on the date of 60 publication of this document. Please review these documents 61 carefully, as they describe your rights and restrictions with 62 respect to this document. Code Components extracted from this 63 document must include Simplified BSD License text as described in 64 Section 4.e of the Trust Legal Provisions and are provided without 65 warranty as described in the Simplified BSD License. 67 Table of Contents 69 Table of Contents.................................................2 70 1. Introduction...................................................3 71 2. Conventions used in this document..............................3 72 3. Context of Stateful PCE and PCEP for GMPLS.....................4 73 4. Main Requirements..............................................4 74 5. PCEP Extensions................................................5 75 5.1. LSP Update in GMPLS-controlled Networks...................5 76 5.2. LSP Synchronization in GMPLS-controlled Networks..........5 77 5.3. Modification of Existing PCEP Messages and Procedures.....7 78 5.3.1. Modification for LSP Re-optimization.................7 79 5.3.2. Modification for Route Exclusion.....................8 80 5.3.3. Modification for SRP Object to indicate Bi-directional 81 LSP.........................................................9 82 5.4. Object Encoding...........................................9 83 6. IANA Considerations............................................9 84 6.1. New PCEP Error Codes......................................9 85 6.2. New Subobject for the Exclude Route Object...............10 86 6.3. New "B" Flag in the SRP Object...........................10 87 7. Manageability Considerations..................................10 88 7.1. Requirements on Other Protocols and Functional Components10 90 8. Security Considerations.......................................11 91 9. Acknowledgement...............................................11 92 10. References...................................................11 93 10.1. Normative References....................................11 94 10.2. Informative References..................................12 95 11. Contributors' Address........................................12 96 Authors' Addresses...............................................13 98 1. Introduction 100 [RFC4655] presents the architecture of a Path Computation Element 101 (PCE)-based model for computing Multiprotocol Label Switching (MPLS) 102 and Generalized MPLS (GMPLS) Traffic Engineering Label Switched 103 Paths (TE LSPs). To perform such a constrained computation, a PCE 104 stores the network topology (i.e., TE links and nodes) and resource 105 information (i.e., TE attributes) in its TE Database (TED). Such a 106 PCE is usually referred as a stateless PCE. To request path 107 computation services to a PCE, [RFC5440] defines the PCE 108 communication Protocol (PCEP) for interaction between a Path 109 Computation Client (PCC) and a PCE, or between two PCEs. PCEP as 110 specified in [RFC 5440] mainly focuses on MPLS networks and the PCEP 111 extensions needed for GMPLS-controlled networks are provided in 112 [PCEP-GMPLS]. 114 Stateful PCEs are shown to be helpful in many application scenarios, 115 in both MPLS and GMPLS networks, as illustrated in [RFC8051]. 116 Further discussion of concept of a stateful PCE can be found in 117 [RFC7399]. In order for these applications to able to exploit the 118 capability of stateful PCEs, extensions to PCEP are required. 120 [RFC8051] describes how a stateful PCE can be applicable to solve 121 various problems for MPLS-TE and GMPLS networks and the benefits it 122 brings to such deployments. 124 [RFC8231] provides the fundamental extensions needed for stateful 125 PCE to support general functionality, but leaves out the 126 specification for technology-specific objects/TLVs. This document 127 focuses on the extensions that are necessary in order for the 128 deployment of stateful PCEs in GMPLS-controlled networks. 130 2. Conventions used in this document 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 134 "OPTIONAL" in this document are to be interpreted as described in 135 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 136 capitals, as shown here. 138 3. Context of Stateful PCE and PCEP for GMPLS 140 This document is built on the basis of Stateful PCE [RFC8231] and 141 PCEP for GMPLS [PCEP-GMPLS]. 143 There are two types of LSP operation for Stateful PCE. 145 For Active Stateful PCE, PCUpd message is sent from PCE to PCC to 146 update the LSP state for the LSP delegated to PCE. Any changes to 147 the delegated LSPs generate a PCRpt message by the PCC to PCE to 148 convey the changes of the LSP. Any modifications to the Objects/TLVs 149 that are identified in this document to support GMPLS technology- 150 specific attributes will be carried in the PCRpt and PCUpd messages. 152 For Passive Stateful PCEs, PCReq/PCRep messages are used to convey 153 path computation instructions. GMPLS-technology specific Objects 154 and TLVs are defined in [PCEP-GMPLS], so this document just points 155 at that work and only adds the stateful PCE aspects where applicable. 156 Passive Stateful PCE makes use of PCRpt messages when reporting LSP 157 State changes sent by PCC to PCEs. Any modifications to the 158 Objects/TLVs that are identified in this document to support GMPLS 159 technology-specific attributes will be carried in the PCRpt message. 161 [PCEP-GMPLS] defines GMPLS-technology specific Objects/TLVs and this 162 document makes use of these Objects/TLVs without modifications where 163 applicable. Some of these Objects/TLVs may require modifications to 164 incorporate stateful PCE element where applicable. 166 4. Main Requirements 168 This section notes the main functional requirements for PCEP 169 extensions to support stateful PCE for use in GMPLS-controlled 170 networks, based on the description in [RFC8051]. Many 171 requirements are common across a variety of network types (e.g., 172 MPLS-TE networks and GMPLS networks) and the protocol extensions to 173 meet the requirements are already described in [RFC8231]. This 174 document does not repeat the description of those protocol 175 extensions. This document presents protocol extensions for a set of 176 requirements which are specific to the use of a stateful PCE in a 177 GMPLS-controlled network. 179 The basic requirements are as follows: 181 o Advertisement of the stateful PCE capability. This generic 182 requirement is covered in Section 5.4. of [RFC8231]. This 183 document assumes that STATEFUL-PCE-CAPABILITY TLV can be used for 184 GMPLS Stateful PCE capability and therefore does not provide any 185 further extensions. 187 o LSP delegation is already covered in Section 5.7. of [RFC8231]. 188 Section 2.2. of this document does not provide any further 189 extensions. 191 o Active LSP update is covered in Section 6.2 of [RFC8231]. Section 192 4.1. of this document provides extension for its application in 193 GMPLS-controlled networks. 195 o LSP state synchronization and LSP state report. This is a generic 196 requirement already covered in Section 5.6. of [RFC8231]. However, 197 there are further extensions required specifically for GMPLS- 198 controlled networks and discussed in Section 4.2. 200 5. PCEP Extensions 202 5.1. LSP Update in GMPLS-controlled Networks 204 [RFC8231] defines the Path Computation LSP Update Request (PCUpd) 205 message to enable to update the attributes of an LSP. However, that 206 document does not define technology-specific parameters. 208 A key element of the PCUpd message is the attribute-list construct 209 defined in [RFC5440] and extended by many other PCEP specifications. 211 For GMPLS purposes we note that the BANDWIDTH object used in the 212 attribute-list is defined in [PCEP-GMPLS]. Furthermore, additional 213 TLVs are defined for the LSPA object in [PCEP-GMPLS] and MAY be 214 included to indicate technology-specific attributes. There are other 215 technology-specific attributes that need to be conveyed in the 216 of the construct in the PCUpd 217 message. Note that these path details in the PCUpd message are the 218 same as the of the PCRep message. See Section 4.2 219 for the details. 221 5.2. LSP Synchronization in GMPLS-controlled Networks 223 PCCs need to report the attributes of LSPs to the PCE to enable 224 stateful operation of a GMPLS network. This process is known as 225 LSP state synchronization. The LSP attributes include bandwidth, 226 associated route, and protection information etc., are stored by the 227 PCE in the LSP database (LSP-DB). Note that, as described in 228 [RFC8231], the LSP state synchronization covers both the bulk 229 reporting of LSPs at initialization as well the reporting of new or 230 modified LSP during normal operation. Incremental LSP-DB 231 synchronization may be desired in a GMPLS-controlled network and it 232 is specified in [RFC8232]. 234 [RFC8231] describes mechanisms for LSP synchronization using the 235 Path Computation State Report (PCRpt) message, but does not cover 236 reporting of technology-specific attributes. As stated in [RFC8231], 237 the construct is further composed of a compulsory Explicit 238 Route Object (ERO) and a compulsory attribute-list and an optional 239 Record Route Object (RRO). In order to report LSP states in GMPLS 240 networks, this specification allows the use within a PCRpt message 241 both of technology- and GMPLS-specific attribute objects and TLVs 242 defined in [PCEP-GMPLS] as follows: 244 o Include Route Object (IRO)/ Exclude Route Object (XRO) 245 Extensions to support the inclusion/exclusion of labels and 246 label sub-objects for GMPLS. (See Section 2.6 and 2.7 in [PCEP- 247 GMPLS]) 249 o END-POINTS (Generalized END-POINTS Object Type. See Section 2.5 250 in [PCEP-GMPLS]) 252 o BANDWIDTH (Generalized BANDWIDTH Object Type. See Section 2.3 253 in [PCEP-GMPLS]) 255 o LSPA (PROTECTION ATTRIBUTE TLV, See Section 2.8 in [PCEP-GMPLS]. 257 The END-POINTS object SHOULD be carried within the attribute-list to 258 specify the endpoints pertaining to the reported LSP. The XRO object 259 MAY be carried to specify the network resources that the reported 260 LSP avoids and a PCE SHOULD consider avoid these network resources 261 during the process of re-optimizing after this LSP is delegated to 262 the PCE. To be more specific, the is updated as 263 follows using the notations of [RFC5511]: 265 ::= [] 266 [] 267 [] 268 [] 269 [] 270 [] 272 ::= [] 274 If the LSP being reported protects another LSP, the PROTECTION- 275 ATTRIBUTE TLV [PCEP-GMPLS] MUST be included in the LSPA object to 276 describe its attributes and restrictions. Moreover, if the status of 277 the protecting LSP changes from non-operational to operational, the 278 PCC SHOULD synchronize the state change of the LSPs to the stateful 279 PCE using a PCRpt message. This use case arises, for example, when 280 the protecting LSP becomes operational due to the failure of the 281 primary LSP. 283 5.3. Modification of Existing PCEP Messages and Procedures 285 One of the advantages mentioned in [RFC8051] is that the stateful 286 nature of a PCE simplifies the information conveyed in PCEP messages, 287 notably between PCC and PCE, since it is possible to refer to PCE 288 managed state for active LSPs. To be more specific, with a stateful 289 PCE, it is possible to refer to an LSP with a unique identifier in 290 the scope of the PCC-PCE session and thus use such identifier to 291 refer to that LSP. Note this is also applicable to packet networks. 293 5.3.1. Modification for LSP Re-optimization 295 The Request Parameters (RP) object on a Path Computation Request 296 (PCReq) message carries the R bit. When set, this indicates that 297 the PCC is requesting re-optimization of an existing LSP. Upon 298 receiving such a PCReq, a stateful PCE SHOULD perform the re- 299 optimization in the following cases: 301 o The existing bandwidth and route information of the LSP to be 302 re-optimized is provided in the PCReq message using the 303 BANDWIDTH object and the ERO. 305 o The existing bandwidth and route information is not supplied 306 in the PCReq message, but can be found in the PCE's LSP-DB. 307 In this case, the LSP MUST be identified using an LSP 308 identifier carried in the PCReq message, and that fact 309 requires that the LSP identifier was previously supplied 310 either by the PCC in a PCRpt message or by the PCE in a PCRep 311 message. [RFC8231] defines how this is achieved using a 312 combination of the per-node LSP identifier (PLSP-ID) and the 313 PCC's address. 315 If no LSP state information is available to carry out re- 316 optimization, the stateful PCE should report the error "LSP state 317 information unavailable for the LSP re-optimization" (Error Type = 318 TBD1, Error value= TBD2). 320 5.3.2. Modification for Route Exclusion 322 [RFC5521] defines a mechanism for a PCC to request or demand that 323 specific nodes, links, or other network resources are excluded from 324 paths computed by a PCE. A PCC may wish to request the computation 325 of a path that avoids all link and nodes traversed by some other LSP. 327 To this end this document defines a new sub-object for use with 328 route exclusion defined in [RFC5521]. The LSP exclusion sub-object 329 is as follows: 331 0 1 2 3 332 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 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 |X|Type (TBD3) | Length | Attributes | Flag | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | | 337 // Symbolic Path Name // 338 | | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 X bit and Attribute fields are defined in [RFC5521]. 343 Type: Subobject Type for an LSP exclusion sub-object. Value of 344 TBD3. To be assigned by IANA. 346 Length: The Length contains the total length of the subobject in 347 bytes, including the Type and Length fields. 349 Flags: This field may be used to further specify the exclusion 350 constraint with regard to the LSP. Currently, no values are 351 defined. 353 Symbolic Path Name: This is the identifier given to an LSP and is 354 unique in the context of the PCC address as defined in [RFC8231]. 356 Reserved: MUST be transmitted as zero and SHOULD be ignored on 357 receipt. 359 This sub-object is OPTIONAL in the exclude route object (XRO) and 360 can be present multiple times. When a stateful PCE receives a PCReq 361 message carrying this sub-object, it SHOULD search for the 362 identified LSP in its LSP-DB and then exclude from the new path 363 computation all resources used by the identified LSP. If the 364 stateful PCE cannot recognize one or more of the received LSP 365 identifiers, it should send an error message PCErr reporting "The 366 LSP state information for route exclusion purpose cannot be found" 367 (Error-type = TBD1, Error-value = TBD4). Optionally, it may provide 368 with the unrecognized identifier information to the requesting PCC 369 using the error reporting techniques described in [RFC5440]. 371 5.3.3. Modification for SRP Object to indicate Bi-directional LSP 373 The format of the SRP object is defined in [RFC8231]. The object is 374 used in PCUpd and PCInit messages for GMPLS. 376 This document defines a new flag to be carried in the Flags field of 377 the SRP object. This flag indicates a bidirectional co-routed LSP 378 setup operation initiated by the PCE as follows: 380 o B (Bidirectional LSP -- 1 bit): If set to 0, it indicates a 381 request to create a uni-directional LSP. If set to 1, it 382 indicates a request to create a bidirectional co-routed LSP. 384 The bit position is TBD5 as assigned by IANA (see Section 5.3) 386 5.4. Object Encoding 388 Note that, as is stated in Section 7 of [RFC8231], the P flag and 389 the I flag of the PCEP objects used on PCUpd and PCRpt messages 390 SHOULD be set to 0 on transmission and SHOULD be ignored on receipt 391 since these flags are exclusively related to path computation 392 requests. 394 6. IANA Considerations 396 6.1. New PCEP Error Codes 398 IANA is requested to make the following allocation in the "PCEP- 399 ERROR Object Error Types and Values" registry. 401 Error Type Meaning Reference 403 TBD1 LSP state information missing [This.I-D] 405 Error-value TBD2: LSP state information unavailable [This.I-D] 407 for the LSP re-optimization 409 Error-value TBD4: LSP state information for route 411 exclusion purpose cannot be found [This.I-D] 413 6.2. New Subobject for the Exclude Route Object 415 IANA maintains the "PCEP Parameters" registry containing a 416 subregistry called "PCEP Objects". This registry has a subregistry 417 for the XRO (Exclude Route Object) listing the sub-objects that can 418 be carried in the XRO. IANA is requested to assign a further sub- 419 object that can be carried in the XRO as follows: 421 Value Description Reference 423 ----------+------------------------------+------------- 425 TBD3 LSP identifier sub-object [This.I-D] 427 6.3. New "B" Flag in the SRP Object 429 IANA maintains a subregistry, named the "SRP Object Flag Field", 430 within the "Path Computation Element Protocol (PCEP) Numbers" 431 registry, to manage the Flag field of the SRP object. 433 IANA is requested to make an assignment from this registry as 434 follows: 436 Bit Description Reference 437 --- ---------------------------- ---------- 439 TDB5 Bi-directional co-routed LSP [This.I-D] 441 7. Manageability Considerations 443 The description and functionality specifications presented related 444 to stateful PCEs should also comply with the manageability 445 specifications covered in Section 8 of [RFC4655]. Furthermore, a 446 further list of manageability issues presented in [RFC8231] should 447 also be considered. 449 Additional considerations are presented in the next section. 451 7.1. Requirements on Other Protocols and Functional Components 453 When the detailed route information is included for LSP state 454 synchronization (either at the initial stage or during LSP state 455 report process), this requires the ingress node of an LSP carry the 456 RRO object in order to enable the collection of such information. 458 8. Security Considerations 460 This draft provides additional extensions to PCEP so as to 461 facilitate stateful PCE usage in GMPLS-controlled networks, on top 462 of [RFC8231]. The PCEP extensions to support GMPLS-controlled 463 networks should be considered under the same security as for MPLS 464 networks, as noted in [RFC7025]. Therefore, the security 465 considerations elaborated in [RFC5440] still apply to this draft. 466 Furthermore, [RFC8231] provides a detailed analysis of the 467 additional security issues incurred due to the new extensions and 468 possible solutions needed to support for the new stateful PCE 469 capabilities and they apply to this document as well. 471 9. Acknowledgement 473 We would like to thank Adrian Farrel and Cyril Margaria for the 474 useful comments and discussions. 476 10. References 478 10.1. Normative References 480 [RFC2119] Bradner, S., "Key words for use in RFCs to indicate 481 requirements levels", RFC 2119, March 1997. 483 [RFC4655] Farrel, A., Vasseur, J.-P., and Ash, J., "A Path 484 Computation Element (PCE)-Based Architecture", RFC 4655, 485 August 2006. 487 [RFC5440] Vasseur, J.-P., and Le Roux, JL., "Path Computation 488 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 489 March 2009. 491 [RFC8174] B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119 492 Key Words", RFC 8174, May 2017. 494 [RFC8231] Crabbe, E., Medved, J., Varga, R., Minei, I., "Path 495 Computation Element Communication Protocol (PCEP) 496 Extensions for Stateful PCE", RFC 8231, September 2017. 498 [PCEP-GMPLS] Margaria, C., Gonzalez de Dios, O., Zhang, F., "PCEP 499 extensions for GMPLS", draft-ietf-pce-gmpls-pcep- 500 extensions, work in progress. 502 10.2. Informative References 504 [RFC5511] A. Farrel, "Routing Backus-Naur Form (RBNF): A Syntax Used 505 to Form Encoding Rules in Various Routing Protocol 506 Specifications", RFC 5511, April 2009. 508 [RFC8051] Zhang, X., Minei, I., et al, "Applicability of Stateful 509 Path Computation Element (PCE) ", RFC 8051, January 2017. 511 [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 512 and D. Dhody, "Optimizations of Label Switched Path State 513 Synchronization Procedures for a Stateful PCE", RFC 8232, 514 September 2017. 516 11. Contributors' Address 518 Xian Zhang 519 Huawei Technologies 520 F3-5-B R&D Center, Huawei Base 521 Bantian, Longgang District 522 Shenzhen 518129 P.R.China 524 Phone: +86-755-28972645 525 Email: zhang.xian@huawei.com 527 Dhruv Dhody 528 Huawei Technology 529 India 531 Email: dhruv.ietf@gmail.com 533 Yi Lin 534 Huawei Technologies 535 F3-5-B R&D Center, Huawei Base 536 Bantian, Longgang District 537 Shenzhen 518129 P.R.China 539 Phone: +86-755-28972914 540 Email: yi.lin@huawei.com 542 Authors' Addresses 544 Young Lee (Editor) 545 Huawei 546 5340 Legacy Drive, Suite 170 547 Plano, TX 75023 548 US 550 Phone: +1 469 278 5838 551 EMail: leeyoung@huawei.com 553 Fatai Zhang 554 Huawei 555 F3-5-B R&D Center, Huawei Base 556 Bantian, Longgang District 557 P.R. China 559 Phone: +86-755-28972912 560 Email: zhangfatai@huawei.com 562 Ramon Casellas 563 CTTC 564 Av. Carl Friedrich Gauss n7 565 Castelldefels, Barcelona 08860 566 Spain 568 Phone: 569 Email: ramon.casellas@cttc.es 571 Oscar Gonzalez de Dios 572 Telefonica Investigacion y Desarrollo 573 Emilio Vargas 6 574 Madrid, 28045 575 Spain 577 Phone: +34 913374013 578 Email: ogondio@tid.es 580 Zafar Ali 581 Cisco Systems 582 Email: zali@cisco.com