idnits 2.17.1 draft-dhody-teas-te-traffic-yang-01.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 226 has weird spacing: '...ch-type ide...' == Line 228 has weird spacing: '...w index uin...' == Line 238 has weird spacing: '...int-ref lea...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (7 March 2022) is 779 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 (-03) exists of draft-ietf-spring-sr-policy-yang-01 == Outdated reference: A later version (-10) exists of draft-ietf-teas-ietf-network-slice-nbi-yang-01 == Outdated reference: A later version (-36) exists of draft-ietf-teas-yang-te-29 Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TEAS Working Group D. Dhody 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track 7 March 2022 5 Expires: 8 September 2022 7 Traffic Mapping YANG model for Traffic Engineering (TE) 8 draft-dhody-teas-te-traffic-yang-01 10 Abstract 12 This document provides a YANG data model to map traffic to Traffic 13 Engineering (TE) paths. This model providers operator a seamless 14 control and management of which traffic to send on the underlying TE 15 resources. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on 8 September 2022. 34 Copyright Notice 36 Copyright (c) 2022 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 41 license-info) in effect on the date of publication of this document. 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. Code Components 44 extracted from this document must include Revised BSD License text as 45 described in Section 4.e of the Trust Legal Provisions and are 46 provided without warranty as described in the Revised BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2.1. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 3 53 2.2. Prefixes in Data Node Names . . . . . . . . . . . . . . . 4 54 2.3. References in the Model . . . . . . . . . . . . . . . . . 4 55 3. Discussion Items . . . . . . . . . . . . . . . . . . . . . . 5 56 4. Tree Structure . . . . . . . . . . . . . . . . . . . . . . . 5 57 5. YANG Model . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 59 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 60 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 61 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 62 8.2. Informative References . . . . . . . . . . . . . . . . . 12 63 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 13 64 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 13 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 67 1. Introduction 69 Data models are a representation of objects that can be configured or 70 monitored within a system. Within the IETF, YANG [RFC7950] is the 71 language of choice for documenting data models, and YANG models have 72 been produced to allow configuration or modeling of a variety of 73 network devices, protocol instances, and network services. 75 There are various YANG models to establish paths in the network, such 76 as: 78 * TE Tunnels [I-D.ietf-teas-yang-te] 80 * Segment Routing (SR) Policy [I-D.ietf-spring-sr-policy-yang] 82 * Service Function Chaining (SFC) 84 * Virtual Network (VN) 86 * IETF Network Slice 88 These models do not include an exact mechanism to describe the 89 traffic that needs to be mapped to the paths. Thus an operator lacks 90 a way to simply use the YANG model to tell requirements such as the 91 traffic from source X on port Y should go on a TE path with delay 92 less than Z. The YANG model defined in this document fills this gap. 94 To achieve this goal, the YANG model defined in this document 95 utilizes the concept borrowed from: 97 * BGP FlowSpec: Where the description of traffic flows is done by 98 the combination of multiple Flow Specification Components and 99 their dissemination as traffic flow specifications (Flow 100 Specifications) is described for BGP in [RFC8955]. In BGP, a Flow 101 Specification is comprised of traffic filtering rules and is 102 associated with actions to perform on the packets that match the 103 Flow Specification. The BGP routers that receive a Flow 104 Specification can classify received packets according to the 105 traffic filtering rules and can direct packets based on the 106 associated actions. 108 * Path Computation Element (PCE) FlowSpec: Extends the idea to PCE 109 Communication Protocol (PCEP) [RFC9168]. 111 * Access Control List (ACL): A basic elements used to configure 112 device-forwarding behavior in form of a user-ordered set of rules 113 that is used to filter traffic on a networking device. Each rule 114 is represented by an Access Control Entry (ACE). Each ACE has a 115 group of match criteria and a group of actions [RFC8519]. 117 The YANG model includes two key concepts: 119 * Traffic Description: The various fields that needs to be matched 120 to identify a traffic flow. 122 * Action: The associated action that needs to be taken. For the 123 purpose of this YANG model the action is to simply point to the TE 124 resource in form of the TE tunnel, SR Policy etc. 126 Note: The RFC Editor will replace XXXX with the number assigned to 127 the RFC once this draft becomes an RFC. 129 2. Conventions 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 133 "OPTIONAL" in this document are to be interpreted as described in 134 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 135 capitals, as shown here. 137 2.1. Tree Diagrams 139 A simplified graphical representation of the data model is used in 140 this document. The meaning of the symbols in these diagrams is 141 defined in [RFC8340]. 143 2.2. Prefixes in Data Node Names 145 In this document, names of data nodes and other data model objects 146 are often used without a prefix, as long as it is clear from the 147 context in which YANG module each name is defined. Otherwise, names 148 are prefixed using the standard prefix associated with the 149 corresponding YANG module, as shown in Table 1. 151 +========+==========+=============================================+ 152 | Prefix | YANG | Reference | 153 | | module | | 154 +========+==========+=============================================+ 155 | yang | ietf- | [RFC6991] | 156 | | yang- | | 157 | | types | | 158 +--------+----------+---------------------------------------------+ 159 | te | ietf-te | [I-D.ietf-teas-yang-te] | 160 +--------+----------+---------------------------------------------+ 161 | rt | ietf- | [RFC8349] | 162 | | routing | | 163 +--------+----------+---------------------------------------------+ 164 | sr- | ietf-sr- | [I-D.ietf-spring-sr-policy-yang] | 165 | policy | policy | | 166 +--------+----------+---------------------------------------------+ 167 | ietf- | ietf- | [I-D.ietf-teas-ietf-network-slice-nbi-yang] | 168 | ns | network- | | 169 | | slice | | 170 +--------+----------+---------------------------------------------+ 171 | acl | ietf- | [RFC8519] | 172 | | access- | | 173 | | control- | | 174 | | list | | 175 +--------+----------+---------------------------------------------+ 177 Table 1 179 2.3. References in the Model 181 Following documents are referenced in the model defined in this 182 document - 183 +=============================+==================================+ 184 | Document | Reference | 185 +=============================+==================================+ 186 | YANG Data Model for Network | [RFC8519] | 187 | Access Control Lists (ACLs) | | 188 +-----------------------------+----------------------------------+ 189 | A YANG Data Model for | [I-D.ietf-teas-yang-te] | 190 | Traffic Engineering Tunnels | | 191 | and Interfaces | | 192 +-----------------------------+----------------------------------+ 193 | YANG Data Model for Segment | [I-D.ietf-spring-sr-policy-yang] | 194 | Routing Policy | | 195 +-----------------------------+----------------------------------+ 197 Table 2 199 3. Discussion Items 201 For describing the traffic, currently the YANG models uses: 203 * The match criteria grouping from the 204 [I-D.ietf-teas-ietf-network-slice-nbi-yang]. If this document 205 gets WG backing, then it might be a good idea to move the grouping 206 to this document instead. 208 * The ACL Name. Should that be ACE instead? 210 * The match action granularity in case of IETF network slice and VN 211 needs to be discussed. 213 * The match action for SFC is not handled yet. 215 4. Tree Structure 216 module: ietf-traffic-map 217 +--rw traffic-map 218 +--rw maps* [id] 219 +--rw id string 220 +--rw traffic 221 | +--rw id? string 222 | +--rw (type)? 223 | +--:(match-criteria) 224 | | +--rw ns-match-criteria 225 | | +--rw ns-match-criterion* [match-type] 226 | | +--rw match-type identityref 227 | | +--rw values* [index] 228 | | +--rw index uint8 229 | | +--rw value? string 230 | +--:(acl) 231 | | +--rw acl? -> /acl:acls/acl/name 232 | +--:(flowspec) 233 | +--:(other) 234 +--rw action 235 | +--rw te-tunnel* te:tunnel-ref 236 | +--rw sr-policy* [policy-color-ref policy-endpoint-ref] 237 | | +--rw policy-color-ref leafref 238 | | +--rw policy-endpoint-ref leafref 239 | +--rw other 240 +--ro stats 241 +--ro matched-packets? yang:counter64 242 +--ro matched-octets? yang:counter64 244 5. YANG Model 246 file "ietf-traffic-map@2022-03-07.yang" 247 module ietf-traffic-map { 248 yang-version 1.1; 249 namespace "urn:ietf:params:xml:ns:yang:ietf-traffic-map"; 250 prefix tm; 252 import ietf-yang-types { 253 prefix yang; 254 reference 255 "RFC 6991: Common YANG Data Types"; 256 } 257 import ietf-te { 258 prefix te; 259 reference 260 "I-D.ietf-teas-yang-te: A YANG Data Model for Traffic 261 Engineering Tunnels and Interfaces"; 262 } 263 import ietf-routing { 264 prefix rt; 265 reference 266 "RFC8349: A YANG Data Model for Routing Management"; 267 } 268 import ietf-sr-policy { 269 prefix sr-policy; 270 reference 271 "I-D.ietf-spring-sr-policy-yang: YANG Data Model for Segment 272 Routing Policy"; 273 } 274 import ietf-network-slice { 275 prefix ietf-ns; 276 reference 277 "I-D.ietf-teas-ietf-network-slice-nbi-yang: IETF 278 Network Slice Service YANG Model"; 279 } 280 import ietf-access-control-list { 281 prefix acl; 282 reference 283 "RFC8519: YANG Data Model for Network Access Control 284 Lists (ACLs)"; 285 } 287 organization 288 "IETF Traffic Engineering Architecture and Signaling (TEAS) 289 Working Group"; 290 contact 291 "WG Web: 292 WG List: 293 Editor: Dhruv Dhody "; 294 description 295 "This module contains a YANG module to map traffic to 296 Traffic Engineering (TE) paths. 298 Copyright (c) 2022 IETF Trust and the persons identified as 299 authors of the code. All rights reserved. 301 Redistribution and use in source and binary forms, with or 302 without modification, is permitted pursuant to, and subject to 303 the license terms contained in, the Revised BSD License set 304 forth in Section 4.c of the IETF Trust's Legal Provisions 305 Relating to IETF Documents 306 (https://trustee.ietf.org/license-info). 308 This version of this YANG module is part of RFC XXXX; see the 309 RFC itself for full legal notices."; 311 revision 2022-03-07 { 312 description 313 "initial version."; 314 reference 315 "RFC XXXX: Traffic Mapping YANG model for Traffic 316 Engineering (TE)"; 317 } 319 grouping traffic-description { 320 description 321 "The traffic description"; 322 leaf id { 323 type string; 324 description 325 "The identifier for Traffic Description"; 326 } 327 choice type { 328 description 329 "The various ways the traffic can be described"; 330 case match-criteria { 331 description 332 "Use the match criteria"; 333 uses ietf-ns:ns-match-criteria; 334 } 335 case acl { 336 description 337 "Reference to ACL"; 338 leaf acl { 339 type leafref { 340 path "/acl:acls/acl:acl/acl:name"; 341 } 342 description 343 "The ACL Name. The action part of the ACL is not 344 used."; 345 reference 346 "RFC8519: YANG Data Model for Network Access Control 347 Lists (ACLs)"; 348 } 349 } 350 case flowspec { 351 description 352 "Based on FlowSpec component type - TODO"; 353 } 354 case other { 355 description 356 "TODO"; 357 } 358 } 359 } 360 grouping te-ref { 361 description 362 "Reference to TE paths"; 363 leaf-list te-tunnel { 364 type te:tunnel-ref; 365 description 366 "Reference to TE Tunnels"; 367 reference 368 "I-D.ietf-teas-yang-te: A YANG Data Model for Traffic 369 Engineering Tunnels and Interfaces"; 370 } 371 list sr-policy { 372 key "policy-color-ref policy-endpoint-ref"; 373 description 374 "SR Policy"; 375 reference 376 "I-D.ietf-spring-sr-policy-yang: YANG Data Model for 377 Segment Routing Policy"; 378 /*Headend needs to be added*/ 379 leaf policy-color-ref { 380 type leafref { 381 path 382 "/rt:routing/sr-policy:segment-routing" 383 + "/sr-policy:traffic-engineering/sr-policy:policies" 384 + "/sr-policy:policy/sr-policy:color"; 385 } 386 description 387 "Reference to sr-policy color"; 388 } 389 leaf policy-endpoint-ref { 390 type leafref { 391 path 392 "/rt:routing/sr-policy:segment-routing" 393 + "/sr-policy:traffic-engineering/sr-policy:policies" 394 + "/sr-policy:policy/sr-policy:endpoint"; 395 } 396 description 397 "Reference to sr-policy endpoint"; 398 } 399 } 400 container other { 401 description 402 "To dp - VN, IETF Network Slice, SFC etc"; 403 } 404 } 406 /* Configuration data nodes */ 407 container traffic-map { 408 description 409 "AP configurations"; 410 list maps { 411 key "id"; 412 description 413 "traffic map identifier"; 414 leaf id { 415 type string; 416 description 417 "The identifier for Traffic Maps"; 418 } 419 container traffic { 420 description 421 "The traffic description"; 422 uses traffic-description; 423 } 424 container action { 425 description 426 "The action is limited to identifying the TE resource"; 427 uses te-ref; 428 } 429 container stats { 430 config false; 431 description 432 "Statistics"; 433 leaf matched-packets { 434 type yang:counter64; 435 description 436 "The number of packets that matched the traffic 437 description"; 438 } 439 leaf matched-octets { 440 type yang:counter64; 441 description 442 "The number of octets (byte) that matched the traffic 443 description"; 444 } 445 } 446 } 447 } 448 } 450 452 6. Security Considerations 454 TBD 456 7. IANA Considerations 458 IANA is requested to make the following allocation for the URIs in 459 the "ns" subregistry within the "IETF XML Registry" [RFC3688]: 461 -------------------------------------------------------------------- 462 URI: urn:ietf:params:xml:ns:yang:ietf-traffic-map 463 Registrant Contact: The IESG. 464 XML: N/A, the requested URI is an XML namespace. 465 -------------------------------------------------------------------- 467 IANA is requested to make the following allocation for the YANG 468 module in the "YANG Module Names" registry [RFC6020]: 470 -------------------------------------------------------------------- 471 name: ietf-traffic-map 472 namespace: urn:ietf:params:xml:ns:yang:ietf-traffic-map 473 prefix: tm 474 reference: RFC XXXX 475 -------------------------------------------------------------------- 477 8. References 479 8.1. Normative References 481 [I-D.ietf-spring-sr-policy-yang] 482 Raza, K., Sawaya, R., Shunwan, Z., Voyer, D., Durrani, M., 483 Matsushima, S., and V. P. Beeram, "YANG Data Model for 484 Segment Routing Policy", Work in Progress, Internet-Draft, 485 draft-ietf-spring-sr-policy-yang-01, 7 April 2021, 486 . 489 [I-D.ietf-teas-ietf-network-slice-nbi-yang] 490 Wu, B., Dhody, D., Rokui, R., Saad, T., and L. Han, "IETF 491 Network Slice Service YANG Model", Work in Progress, 492 Internet-Draft, draft-ietf-teas-ietf-network-slice-nbi- 493 yang-01, 4 March 2022, . 496 [I-D.ietf-teas-yang-te] 497 Saad, T., Gandhi, R., Liu, X., Beeram, V. P., Bryskin, I., 498 and O. G. D. Dios, "A YANG Data Model for Traffic 499 Engineering Tunnels, Label Switched Paths and Interfaces", 500 Work in Progress, Internet-Draft, draft-ietf-teas-yang-te- 501 29, 7 February 2022, . 504 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 505 Requirement Levels", BCP 14, RFC 2119, 506 DOI 10.17487/RFC2119, March 1997, 507 . 509 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 510 DOI 10.17487/RFC3688, January 2004, 511 . 513 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 514 the Network Configuration Protocol (NETCONF)", RFC 6020, 515 DOI 10.17487/RFC6020, October 2010, 516 . 518 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 519 RFC 6991, DOI 10.17487/RFC6991, July 2013, 520 . 522 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 523 RFC 7950, DOI 10.17487/RFC7950, August 2016, 524 . 526 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 527 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 528 May 2017, . 530 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 531 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 532 . 534 [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for 535 Routing Management (NMDA Version)", RFC 8349, 536 DOI 10.17487/RFC8349, March 2018, 537 . 539 [RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, 540 "YANG Data Model for Network Access Control Lists (ACLs)", 541 RFC 8519, DOI 10.17487/RFC8519, March 2019, 542 . 544 8.2. Informative References 546 [RFC8955] Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. 547 Bacher, "Dissemination of Flow Specification Rules", 548 RFC 8955, DOI 10.17487/RFC8955, December 2020, 549 . 551 [RFC9168] Dhody, D., Farrel, A., and Z. Li, "Path Computation 552 Element Communication Protocol (PCEP) Extension for Flow 553 Specification", RFC 9168, DOI 10.17487/RFC9168, January 554 2022, . 556 Appendix A. Acknowledgments 558 Thanks to Adrian Farrel for the motivation behind this document. 560 Appendix B. Examples 562 TO be added in future revisions. 564 Author's Address 566 Dhruv Dhody 567 Huawei Technologies 568 Divyashree Techno Park, Whitefield 569 Bangalore 560066 570 India 571 Email: dhruv.ietf@gmail.com