idnits 2.17.1 draft-zhang-ccamp-l1-topo-yang-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 161 has weird spacing: '...riority uin...' == Line 163 has weird spacing: '...du-type ide...' == Line 168 has weird spacing: '...riority uin...' == Line 170 has weird spacing: '...du-type ide...' -- The document date (April 25, 2017) is 2550 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) == Outdated reference: A later version (-22) exists of draft-ietf-teas-yang-te-topo-08 == Outdated reference: A later version (-02) exists of draft-sharma-ccamp-otn-tunnel-model-01 == Outdated reference: A later version (-28) exists of draft-ietf-ccamp-wson-yang-05 == Outdated reference: A later version (-20) exists of draft-ietf-netmod-rfc6087bis-12 == Outdated reference: A later version (-06) exists of draft-vergara-ccamp-flexigrid-yang-04 Summary: 0 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group H. Zheng 3 Internet-Draft Z. Fan 4 Intended status: Standards Track Huawei Technologies 5 Expires: October 27, 2017 A. Sharma 6 Google 7 X. Liu 8 Jabil 9 April 25, 2017 11 A YANG Data Model for Optical Transport Network Topology 12 draft-zhang-ccamp-l1-topo-yang-07 14 Abstract 16 A transport network is a server-layer network designed to provide 17 connectivity services for a client-layer network to carry the client 18 traffic transparently across the server-layer network resources. A 19 transport network can be constructed from equipments utilizing any of 20 a number of different transport technologies such as the evolving 21 Optical Transport Networks (OTN) or packet transport as provided by 22 the MPLS-Transport Profile (MPLS-TP). 24 This draft describes a YANG data model to describe the topologies of 25 an Optical Transport Network (OTN). It is independent of control 26 plane protocols and captures topological and resource related 27 information pertaining to OTN. This model enables clients, which 28 interact with a transport domain controller via a REST interface, for 29 OTN topology related operations such as obtaining the relevant 30 topology resource information. 32 Requirements Language 34 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 35 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 36 document are to be interpreted as described in [RFC2119]. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at http://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on October 27, 2017. 55 Copyright Notice 57 Copyright (c) 2017 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 73 2. Terminology and Notations . . . . . . . . . . . . . . . . . . 3 74 3. YANG Data Model for OTN Topology . . . . . . . . . . . . . . 4 75 3.1. the YANG Tree . . . . . . . . . . . . . . . . . . . . . . 4 76 3.2. Explanation of the OTN Topology Data Model . . . . . . . 5 77 3.3. The YANG Code . . . . . . . . . . . . . . . . . . . . . . 5 78 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 79 5. Manageability Considerations . . . . . . . . . . . . . . . . 13 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 81 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 82 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 84 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 85 9.2. Informative References . . . . . . . . . . . . . . . . . 15 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 88 1. Introduction 90 A transport network is a server-layer network designed to provide 91 connectivity services for a client-layer network to carry the client 92 traffic transparently across the server-layer network resources. A 93 transport network can be constructed of equipments utilizing any of a 94 number of different transport technologies such as the Optical 95 Transport Networks (OTN) or packet transport as provided by the MPLS- 96 Transport Profile (MPLS-TP). 98 This document defines a data model of an OTN network topology, using 99 YANG [RFC6020]. The model can be used by an application exposing to 100 a transport controller via a REST interface. Furthermore, it can be 101 used by an application for the following purposes (but not limited 102 to): 104 o To obtain a whole view of the network topology information of its 105 interest; 107 o To receive notifications with regard to the information change of 108 the OTN topology; 110 o To enforce the establishment and update of a network topology with 111 the characteristic specified in the data model, e.g., by a client 112 controller; 114 The YANG model defined in this draft is independent of control plane 115 protocols and captures topology related information pertaining to an 116 Optical Transport Networks (OTN)-electrical layer, as the scope 117 specified by [RFC7062] and [RFC7138]. Furthermore, it is not a 118 stand-alone model, but augmenting from the TE topology YANG model 119 defined in [I-D.ietf-teas-yang-te-topo]. 121 Optical network technologies, including fixed Dense Wavelength 122 Switched Optical Network (WSON) and flexible optical networks 123 (a.k.a., flexi-grid networks), are covered in 124 [I-D.ietf-ccamp-wson-yang] and [I-D.vergara-ccamp-flexigrid-yang], 125 respectively. 127 2. Terminology and Notations 129 A simplified graphical representation of the data model is used in 130 this document. The meaning of the symbols in the YANG data tree 131 presented later in this draft is defined in 132 [I-D.ietf-netmod-rfc6087bis]. They are provided below for reference. 134 o Brackets "[" and "]" enclose list keys. 136 o Abbreviations before data node names: "rw" means configuration 137 (read-write) and "ro" state data (read-only). 139 o Symbols after data node names: "?" means an optional node, "!" 140 means a presence container, and "*" denotes a list and leaf-list. 142 o Parentheses enclose choice and case nodes, and case nodes are also 143 marked with a colon (":"). 145 o Ellipsis ("...") stands for contents of subtrees that are not 146 shown. 148 3. YANG Data Model for OTN Topology 150 3.1. the YANG Tree 152 module: ietf-otn-topology 153 augment /nd:networks/nd:network/nd:network-types/tet:te-topology: 154 +--rw otn-topology! 155 augment /nd:networks/nd:network: 156 +--rw name? string 157 augment /nd:networks/nd:network/nd:node: 158 +--rw name? string 159 augment /nd:networks/nd:network/lnk:link/tet:te/tet:config: 160 +--rw available-odu-info* [priority] 161 | +--rw priority uint8 162 | +--rw odulist* [odu-type] 163 | +--rw odu-type identityref 164 | +--rw number? uint16 165 +--rw distance? uint32 166 augment /nd:networks/nd:network/lnk:link/tet:te/tet:state: 167 +--ro available-odu-info* [priority] 168 | +--ro priority uint8 169 | +--ro odulist* [odu-type] 170 | +--ro odu-type identityref 171 | +--ro number? uint16 172 +--ro distance? uint32 173 augment /nd:networks/nd:network/nd:node/lnk:termination-point 174 /tet:te/tet:config: 175 +--rw client-facing? empty 176 +--rw tpn? uint16 177 +--rw tsg? identityref 178 +--rw protocol-type? identityref 179 +--rw adaptation-type? adaptation-type 180 +--rw sink-adapt-active? boolean 181 +--rw source-adapt-active? boolean 182 +--rw tributary-slots 183 | +--rw values* uint8 184 +--rw supported-payload-types* [index] 185 +--rw index uint16 186 +--rw payload-type? string 187 augment /nd:networks/nd:network/nd:node/lnk:termination-point/ 188 tet:te/tet:state: 190 +--ro client-facing? empty 191 +--ro tpn? uint16 192 +--ro tsg? identityref 193 +--ro protocol-type? identityref 194 +--ro adaptation-type? adaptation-type 195 +--ro sink-adapt-active? boolean 196 +--ro source-adapt-active? boolean 197 +--ro tributary-slots 198 | +--ro values* uint8 199 +--ro supported-payload-types* [index] 200 +--ro index uint16 201 +--ro payload-type? string 203 3.2. Explanation of the OTN Topology Data Model 205 As can be seen, from the data tree shown in Section 3.1, the YANG 206 module presented in this draft augments from a more generic Traffic 207 Engineered (TE) network topology data model, i.e., the ietf-te- 208 topology.yang as specified in [I-D.ietf-teas-yang-te-topo]. The 209 entities and their attributes, such as node, termination points and 210 links, are still applicable for describing an OTN topology and the 211 model presented in this draft only specifies with technology-specific 212 attributes/information. For example, if the data plane complies with 213 ITU-T G.709 (2012) standards, the switching-capability and encoding 214 attributes MUST be filled as OTN-TDM and G.709 ODUk(Digital Path) 215 respectively. 217 Note the model in this draft re-uses some attributes defined in ietf- 218 transport-types.yang, which is specified in 219 [I-D.sharma-ccamp-otn-tunnel-model]. 221 One of the main augmentations in this model is that it allows to 222 specify the type of ODU container and the number a link can support 223 per priority level. For example, for a ODU3 link, it may advertise 224 32*ODU0, 16*ODU1, 4*ODU2 available, assuming only a single priority 225 level is supported. If one of ODU2 resource is taken to establish a 226 ODU path, then the availability of this ODU link is updated as 227 24*ODU0, 12*ODU1, 3*ODU2 available. If there are equipment hardware 228 limitations, then a subset of potential ODU type SHALL be advertised. 229 For instance, an ODU3 link may only support 4*ODU2. 231 3.3. The YANG Code 233 file "ietf-otn-topology@2017-04-25.yang" 235 module ietf-otn-topology { 236 yang-version 1.1; 238 namespace "urn:ietf:params:xml:ns:yang:ietf-otn-topology"; 239 prefix "otntopo"; 241 import ietf-network { 242 prefix "nd"; 243 } 245 import ietf-network-topology { 246 prefix "lnk"; 247 } 249 import ietf-te-topology { 250 prefix "tet"; 251 } 253 import ietf-transport-types { 254 prefix "tran-types"; 255 } 257 organization 258 "Internet Engineering Task Force (IETF) CCAMP WG"; 259 contact 260 " 261 WG List: 263 ID-draft editor: 264 Haomian Zheng (zhenghaomian@huawei.com); 265 Zheyu Fan (fanzheyu2@huawei.com); 266 Anurag Sharma (ansha@google.com); 267 Xufeng Liu (Xufeng_Liu@jabil.com) 268 "; 270 description 271 "This module defines a protocol independent Layer 1/ODU 272 topology data model."; 274 revision 2017-04-25 { 275 description 276 "Revision 0.3"; 277 reference 278 "draft-zhang-ccamp-l1-topo-yang-07.txt"; 279 } 281 /* 282 typedef 283 */ 284 typedef adaptation-type { 285 type enumeration { 286 enum CBR { 287 description "Constant Bit Rate."; 288 } 289 enum ATMvp { 290 description "ATM VP."; 291 } 292 enum GFP { 293 description "Generic Framing Procedure."; 294 } 295 enum NULL { 296 description "NULL"; 297 } 298 enum PRBS { 299 description "Pseudo Random Binary Sequence"; 300 } 301 enum RSn { 302 description "SDH/SONET section"; 303 } 304 enum ODUj-21 { 305 description "ODU payload type 21"; 306 } 307 enum ETHERNET_PP-OS { 308 description "ETHERNET_PP-OS, for ODU 2 only"; 309 } 310 enum CBRx { 311 description "CBRx(0.. 1.25G), for ODU0 only"; 312 } 313 enum ODU { 314 description "Optical Data Unit"; 315 } 316 } 318 description 319 "Defines a type representing the adaptation type 320 on the termination point."; 321 } 323 /* 324 Groupings 325 */ 327 grouping otn-topology-type { 328 container otn-topology { 329 presence "indicates a topology type of Optical 330 Transport Network (OTN)-electrical layer."; 331 description "otn topology type"; 332 } 333 description "otn-topology-type"; 334 } 336 grouping otn-topology-attributes { 337 leaf name { 338 type string; 339 description "the topology name"; 340 } 341 description "name attribute for otn topology"; 342 } 344 grouping otn-node-attributes { 345 description "otn-node-attributes"; 346 leaf name { 347 type string; 348 description "a name for this node."; 349 } 350 } 352 grouping otn-link-attributes { 353 description "otn link attributes"; 355 list available-odu-info{ 356 key "priority"; 357 max-elements "8"; 359 description 360 "List of ODU type and number on this link"; 361 leaf priority { 362 type uint8 { 363 range "0..7"; 364 } 365 description "priority"; 366 } 368 list odulist { 369 key "odu-type"; 371 description 372 "the list of available ODUs per priority level"; 374 leaf odu-type { 375 type identityref{ 376 base tran-types:tributary-protocol-type; 377 } 378 description "the type of ODU"; 380 } 382 leaf number { 383 type uint16; 384 description "the number of odu type supported"; 385 } 386 } 387 } 389 leaf distance { 390 type uint32; 391 description "distance in the unit of kilometers"; 392 } 393 } 395 grouping otn-tp-attributes { 396 description "otn-tp-attributes"; 398 leaf client-facing { 399 type empty; 400 description 401 "if present, it means this tp is a client-facing tp. 402 adding/dropping client signal flow."; 403 } 405 leaf tpn { 406 type uint16 { 407 range "0..4095"; 408 } 409 description 410 "Tributary Port Number. Applicable in case of mux services."; 411 reference 412 "RFC7139: GMPLS Signaling Extensions for Control of Evolving 413 G.709 Optical Transport Networks."; 414 } 416 leaf tsg { 417 type identityref { 418 base tran-types:tributary-slot-granularity; 419 } 420 description "Tributary slot granularity."; 421 reference 422 "G.709/Y.1331, February 2012: Interfaces for the Optical 423 Transport Network (OTN)"; 424 } 426 leaf protocol-type { 427 type identityref { 428 base tran-types:tributary-protocol-type; 429 } 430 description "Protocol type for the Termination Point."; 431 } 433 leaf adaptation-type { 434 type adaptation-type; 435 description 436 "This attribute indicates the type of the supported 437 adaptation function at the termination point."; 438 reference 439 "G.874.1, January 2002: Optical transport network (OTN): 440 Protocol-neutral management information model for the 441 network element view."; 442 } 444 leaf sink-adapt-active { 445 type boolean; 446 description 447 "This attribute allows for activation or deactivation of 448 the sink adaptation function. The value of TRUE means active."; 450 reference 451 "G.874.1, January 2002: Optical transport network (OTN): 452 Protocol-neutral management information model for the 453 network element view "; 454 } 456 leaf source-adapt-active { 457 type boolean; 458 description 459 "This attribute allows for activation or deactivation of 460 the sink adaptation function. The value of TRUE 461 means active."; 462 reference 463 "G.874.1, January 2002: Optical transport network (OTN): 464 Protocol-neutral management information model for 465 the network element view "; 466 } 468 container tributary-slots { 469 description 470 "A list of tributary slots used by the ODU 471 Termination Point."; 472 leaf-list values { 473 type uint8; 474 description 475 "Tributary slot value."; 476 reference 477 "G.709/Y.1331, February 2012: Interfaces for the 478 Optical Transport Network (OTN)"; 479 } 480 } 482 list supported-payload-types{ 483 key "index"; 485 description "supported payload types of a TP"; 487 leaf index { 488 type uint16; 489 description "payload type index"; 490 } 492 leaf payload-type { 493 type string; 494 description "the payload type supported by this client 495 tp"; 496 reference 497 "http://www.iana.org/assignments/gmpls-sig-parameters 498 /gmpls-sig-parameters.xhtml 499 not: the payload type is defined as the generalized PIDs 500 in GMPLS."; 501 } 502 } 503 } 505 /* 506 * Data nodes 507 */ 508 augment "/nd:networks/nd:network/nd:network-types/tet:te-topology" { 509 uses otn-topology-type; 510 description "augment network types to include otn newtork"; 511 } 513 augment "/nd:networks/nd:network" { 514 when "nd:network-types/tet:te-topology/otn-topology" { 515 description "Augment only for otn network"; 516 } 517 uses otn-topology-attributes; 518 description "Augment network configuration"; 519 } 521 augment "/nd:networks/nd:network/nd:node" { 522 when "../nd:network-types/tet:te-topology/otn-topology" { 523 description "Augment only for otn network"; 524 } 525 description "Augment node configuration"; 526 uses otn-node-attributes; 527 } 529 augment "/nd:networks/nd:network/lnk:link/tet:te/tet:config" { 530 when "../../../nd:network-types/tet:te-topology/otn-topology" { 531 description "Augment only for otn network."; 532 } 533 description "Augment link configuration"; 535 uses otn-link-attributes; 536 } 538 augment "/nd:networks/nd:network/lnk:link/tet:te/tet:state" { 539 when "../../../nd:network-types/tet:te-topology/otn-topology" { 540 description "Augment only for otn network."; 541 } 542 description "Augment link state"; 544 uses otn-link-attributes; 545 } 547 augment "/nd:networks/nd:network/nd:node/" 548 +"lnk:termination-point/tet:te/tet:config" { 549 when "../../../../nd:network-types/tet:te-topology/otn-topology" { 550 description "Augment only for otn network"; 551 } 552 description "OTN TP attributes config in a ODU topology."; 553 uses otn-tp-attributes; 554 } 556 augment "/nd:networks/nd:network/nd:node/" 557 +"lnk:termination-point/tet:te/tet:state" { 558 when "../../../../nd:network-types/tet:te-topology/otn-topology" { 559 description "Augment only for otn network"; 560 } 561 description "OTN TP attributes state in a ODU topology."; 562 uses otn-tp-attributes; 563 } 564 } 566 568 4. IANA Considerations 570 TBD. 572 5. Manageability Considerations 574 TBD. 576 6. Security Considerations 578 The data following the model defined in this draft is exchanged via, 579 for example, the interface between an orchestrator and a transport 580 network controller. The security concerns mentioned in 581 [I-D.ietf-teas-yang-te-topo] for using ietf-te-topology.yang model 582 also applies to this draft. 584 The YANG module defined in this document can be accessed via the 585 RESTCONF protocol defined in [RFC8040], or maybe via the NETCONF 586 protocol [RFC6241]. 588 There are a number of data nodes defined in the YANG module which are 589 writable/creatable/deletable (i.e., config true, which is the 590 default). These data nodes may be considered sensitive or vulnerable 591 in some network environments. Write operations (e.g., POST) to these 592 data nodes without proper protection can have a negative effect on 593 network operations. 595 Editors note: to list specific subtrees and data nodes and their 596 sensitivity/vulnerability. 598 7. Acknowledgements 600 We would like to thank Igor Bryskin, Zhe Liu, Dieter Beller and 601 Daniele Ceccarelli for their comments and discussions. 603 8. Contributors 605 Baoquan Rao 606 Huawei Technologies 607 Email: raobaoquan@huawei.com 609 Xian Zhang 610 Huawei Technologies 611 Email: zhang.xian@huawei.com 613 Sergio Belotti 614 Nokia 615 Email: sergio.belotti@nokia.com 616 Huub van Helvoort 617 Hai Gaoming BV 618 the Netherlands 619 Email: huubatwork@gmail.com 621 9. References 623 9.1. Normative References 625 [I-D.ietf-teas-yang-te-topo] 626 Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 627 O. Dios, "YANG Data Model for TE Topologies", draft-ietf- 628 teas-yang-te-topo-08 (work in progress), March 2017. 630 [I-D.sharma-ccamp-otn-tunnel-model] 631 Zhang, X., xiangkun, x., ansharma@infinera.com, a., and R. 632 Rao, "OTN Tunnel YANG Model", draft-sharma-ccamp-otn- 633 tunnel-model-01 (work in progress), March 2017. 635 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 636 Requirement Levels", BCP 14, RFC 2119, 637 DOI 10.17487/RFC2119, March 1997, 638 . 640 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 641 the Network Configuration Protocol (NETCONF)", RFC 6020, 642 DOI 10.17487/RFC6020, October 2010, 643 . 645 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 646 and A. Bierman, Ed., "Network Configuration Protocol 647 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 648 . 650 [RFC7138] Ceccarelli, D., Ed., Zhang, F., Belotti, S., Rao, R., and 651 J. Drake, "Traffic Engineering Extensions to OSPF for 652 GMPLS Control of Evolving G.709 Optical Transport 653 Networks", RFC 7138, DOI 10.17487/RFC7138, March 2014, 654 . 656 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 657 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 658 . 660 9.2. Informative References 662 [I-D.ietf-ccamp-wson-yang] 663 Lee, Y., Dhody, D., Zhang, X., Guo, A., Lopezalvarez, V., 664 King, D., and B. Yoon, "A Yang Data Model for WSON Optical 665 Networks", draft-ietf-ccamp-wson-yang-05 (work in 666 progress), February 2017. 668 [I-D.ietf-netmod-rfc6087bis] 669 Bierman, A., "Guidelines for Authors and Reviewers of YANG 670 Data Model Documents", draft-ietf-netmod-rfc6087bis-12 671 (work in progress), March 2017. 673 [I-D.vergara-ccamp-flexigrid-yang] 674 Madrid, U., Perdices, D., Lopezalvarez, V., Dios, O., 675 King, D., Lee, Y., and G. Galimberti, "YANG data model for 676 Flexi-Grid Optical Networks", draft-vergara-ccamp- 677 flexigrid-yang-04 (work in progress), March 2017. 679 [RFC7062] Zhang, F., Ed., Li, D., Li, H., Belotti, S., and D. 680 Ceccarelli, "Framework for GMPLS and PCE Control of G.709 681 Optical Transport Networks", RFC 7062, 682 DOI 10.17487/RFC7062, November 2013, 683 . 685 Authors' Addresses 687 Haomian Zheng 688 Huawei Technologies 689 F3 R&D Center, Huawei Industrial Base, Bantian, Longgang District 690 Shenzhen, Guangdong 518129 691 P.R.China 693 Email: zhenghaomian@huawei.com 695 Zheyu Fan 696 Huawei Technologies 697 F3 R&D Center, Huawei Industrial Base, Bantian, Longgang District 698 Shenzhen, Guangdong 518129 699 P.R.China 701 Email: fanzheyu2@huawei.com 702 Anurag Sharma 703 Google 704 1600 Amphitheatre Parkway 705 Mountain View, CA 94043 707 Email: ansha@google.com 709 Xufeng Liu 710 Jabil 712 Email: Xufeng_Liu@jabil.com