idnits 2.17.1 draft-ietf-netmod-sub-intf-vlan-model-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 210 has weird spacing: '...ag-type dot...' == Line 272 has weird spacing: '...ag-type dot...' == Line 284 has weird spacing: '...ag-type dot...' == Line 293 has weird spacing: '...ag-type dot...' == Line 301 has weird spacing: '...ag-type dot...' == (1 more instance...) == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 13, 2017) is 2600 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC7224' is defined on line 1071, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-netmod-intf-ext-yang-04 ** Obsolete normative reference: RFC 7223 (Obsoleted by RFC 8343) -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 6536 (Obsoleted by RFC 8341) Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force R. Wilton, Ed. 3 Internet-Draft D. Ball 4 Intended status: Informational T. Singh 5 Expires: September 14, 2017 Cisco Systems 6 S. Sivaraj 7 Juniper Networks 8 March 13, 2017 10 Sub-interface VLAN YANG Data Models 11 draft-ietf-netmod-sub-intf-vlan-model-01 13 Abstract 15 This document defines YANG modules to add support for classifying 16 traffic received on interfaces as Ethernet/VLAN framed packets to 17 sub-interfaces based on the fields available in the Ethernet/VLAN 18 frame headers. These modules allow configuration of Layer 3 and 19 Layer 2 sub-interfaces (e.g. attachment circuits) that can 20 interoperate with IETF based forwarding protocols; such as IP and 21 L3VPN services; or L2VPN services like VPWS, VPLS, and EVPN. The 22 sub-interfaces also interoperate with VLAN tagged traffic orginating 23 from an IEEE 802.1Q compliant bridge. Primarily the classification 24 is based on VLAN identifiers in the 802.1Q VLAN tags, but the model 25 also has support for matching on some other layer 2 frame header 26 fields and is designed to be extensible to match on other arbitrary 27 header fields. 29 The model differs from an IEEE 802.1Q bridge model in that the 30 configuration is interface/sub-interface based as opposed to being 31 based on membership of an 802.1Q VLAN bridge. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on September 14, 2017. 50 Copyright Notice 52 Copyright (c) 2017 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 69 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4 70 2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 2.1. Interoperability with IEEE 802.1Q compliant bridges . . . 4 72 2.2. Extensibility . . . . . . . . . . . . . . . . . . . . . . 4 73 3. L3 Interface VLAN Model . . . . . . . . . . . . . . . . . . . 5 74 4. Flexible Encapsulation Model . . . . . . . . . . . . . . . . 5 75 5. L3 Interface VLAN YANG Module . . . . . . . . . . . . . . . . 7 76 6. Flexible Encapsulation YANG Module . . . . . . . . . . . . . 10 77 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 78 8. ChangeLog . . . . . . . . . . . . . . . . . . . . . . . . . . 19 79 8.1. WG version -01 . . . . . . . . . . . . . . . . . . . . . 19 80 8.2. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 20 81 8.3. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 20 82 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 83 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 84 10.1. if-l3-vlan.yang . . . . . . . . . . . . . . . . . . . . 21 85 10.2. flexible-encapsulation.yang . . . . . . . . . . . . . . 21 86 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 87 11.1. Normative References . . . . . . . . . . . . . . . . . . 23 88 11.2. Informative References . . . . . . . . . . . . . . . . . 23 89 Appendix A. Comparison with the IEEE 802.1Q Configuration Model 24 90 A.1. Sub-interface based configuration model overview . . . . 24 91 A.2. IEEE 802.1Q Bridge Configuration Model Overview . . . . . 25 92 A.3. Possible Overlap Between the Two Models . . . . . . . . . 26 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 95 1. Introduction 97 This document defines two YANG [RFC7950] modules that augment the 98 encapsulation choice YANG element defined in Interface Extensions 99 YANG [I-D.ietf-netmod-intf-ext-yang] and the generic interfaces data 100 model defined in [RFC7223]. The two modules provide configuration 101 nodes to support classification of Ethernet/VLAN traffic to sub- 102 interfaces, that can have interface based feature and service 103 configuration applied to them. 105 The purpose of these models is to allow IETF defined forwarding 106 protocols, such as IPv6 [RFC2460], Ethernet Pseudo Wires [RFC4448] 107 and VPLS [RFC4761] [RFC4762] to be configurable via YANG when 108 interoperating with VLAN tagged traffic received from an IEEE 802.1Q 109 compliant bridge. 111 In the case of layer 2 Ethernet services, the flexible encapsulation 112 module also supports flexible rewriting of the VLAN tags contained 113 the in frame header. 115 For reference, a comparison between the sub-interface based YANG 116 model documented in this draft and an IEEE 802.1Q bridge model is 117 described in Appendix A. 119 In summary, the YANG modules defined in this internet draft are: 121 if-l3-vlan.yang - Defines the model for basic classification of 122 VLAN tagged traffic to L3 transport services 124 flexible-encapsulation.yang - Defines the model for flexible 125 classification of Ethernet/VLAN traffic to L2 transport services 127 1.1. Terminology 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in RFC 2119 [RFC2119]. 133 Sub-interface: A sub-interface is a small augmentation of a regular 134 interface in the standard YANG module for Interface Management that 135 represents a subset of the traffic handled by its parent interface. 136 As such, it supports both configuration and operational data using 137 any other YANG models that augment or reference interfaces in the 138 normal way. It is defined in Interface Extensions YANG 139 [I-D.ietf-netmod-intf-ext-yang]. 141 1.2. Tree Diagrams 143 A simplified graphical representation of the data model is used in 144 this document. The meaning of the symbols in these diagrams is as 145 follows: 147 o Brackets "[" and "]" enclose list keys. 149 o Abbreviations before data node names: "rw" means configuration 150 (read-write), and "ro" means state data (read-only). 152 o Symbols after data node names: "?" means an optional node, "!" 153 means a presence container, and "*" denotes a list or leaf-list. 155 o Parentheses enclose choice and case nodes, and case nodes are also 156 marked with a colon (":"). 158 o Ellipsis ("...") stands for contents of subtrees that are not 159 shown. 161 2. Objectives 163 The primary aim of the YANG modules contained in this draft is to 164 provide the core model that is required to implement VLAN transport 165 services on router based devices that is fully compatible with IEEE 166 802.1Q complaint bridges. 168 A secondary aim is for the modules to be structured in such a way 169 that they can be cleanly extended in future. 171 2.1. Interoperability with IEEE 802.1Q compliant bridges 173 The modules defined in this document are designed to fully 174 interoperate with IEEE 802.1Q compliant bridges. In particular, the 175 models are restricted to only matching, adding, or rewriting the 176 802.1Q VLAN tags in frames in ways that are compatible with IEEE 177 802.1Q compliant bridges. 179 2.2. Extensibility 181 The modules are structured in such a way that they can be sensibly 182 extended. In particular: 184 The tag stack is represented as a list to allow a tag stack of 185 more than two tags to be supported if necessary in future. 187 The tag stack list elements allow other models, or vendors, to 188 include additional forms of tag matching and rewriting. The 189 intention, however, is that it should not be necessary to have any 190 vendor specific extensions to any of the YANG models defined in 191 this document to implement standard Ethernet and VLAN services. 193 3. L3 Interface VLAN Model 195 The L3 Interface VLAN model provides appropriate leaves for 196 termination of an 802.1Q VLAN tagged segment to a sub-interface based 197 L3 service. It allows for termination of traffic with up to two 198 802.1Q VLAN tags. 200 The "if-l3-vlan" YANG module has the following structure: 202 module: ietf-if-l3-vlan 203 augment /if:interfaces/if:interface/if-cmn:encapsulation/ 204 if-cmn:encaps-type: 205 +--:(vlan) 206 +--rw vlan 207 +--rw tag* [index] 208 +--rw index uint8 209 +--rw dot1q-tag 210 +--rw tag-type dot1q-tag-type 211 +--rw vlan-id ieee:vlanid 213 4. Flexible Encapsulation Model 215 The Flexible Encapsulation model is designed to allow for the 216 flexible provisioning of layer 2 services. It provides the 217 capability to classify Ethernet/VLAN frames received on an Ethernet 218 trunk interface to sub-interfaces based on the fields available in 219 the layer 2 headers. Once classified to sub-interfaces, it provides 220 the capability to selectively modify fields within the layer 2 221 headers before the frame is handed off to the appropriate forwarding 222 code for further handling. 224 The model supports a common core set of layer 2 header matches based 225 on the 802.1Q tag type and VLAN Ids contained within the header up to 226 a tag stack depth of two tags. 228 The model supports flexible rewrites of the layer 2 frame header for 229 data frames as they are processed on the interface. It defines a set 230 of standard tag manipulations that allow for the insertion, removal, 231 or rewrite of one or two 802.1Q VLAN tags. The expectation is that 232 manipulations are generally implemented in a symmetrical fashion, 233 i.e. if a manipulation is performed on ingress traffic on an 234 interface then the reverse manipulation is always performed on egress 235 traffic out of the same interface. However, the model also allows 236 for asymmetrical rewrites, which may be required to implement some 237 forwarding models (such as E-Tree). 239 The structure of the model is currently limited to matching or 240 rewriting a maximum of two 802.1Q tags in the frame header but has 241 been designed to be easily extensible to matching/rewriting three or 242 more VLAN tags in future, if required. 244 The final aim for the model design is for it to be cleanly extensible 245 to add in additional match and rewrite criteria of the layer 2 246 header, such as matching on the source or destination MAC address, 247 PCP or DEI fields in the 802.1Q tags, or the EtherType of the frame 248 payload. Rewrites can also be extended to allow for modification of 249 other fields within the layer 2 frame header. 251 The "flexible-encapsulation" YANG module has the following structure: 253 module: ietf-flexible-encapsulation 254 augment /if:interfaces/if:interface/if-cmn:encapsulation/ 255 if-cmn:encaps-type: 256 +--:(flexible) {flexible-encapsulation-rewrites}? 257 +--rw flexible 258 +--rw match 259 | +--rw (match-type) 260 | +--:(default) 261 | | +--rw default? empty 262 | +--:(untagged) 263 | | +--rw untagged? empty 264 | +--:(priority-tagged) 265 | | +--rw priority-tagged 266 | | +--rw tag-type? dot1q-types:dot1q-tag-type 267 | +--:(vlan-tagged) 268 | +--rw vlan-tagged 269 | +--rw tag* [index] 270 | | +--rw index uint8 271 | | +--rw dot1q-tag 272 | | +--rw tag-type dot1q-tag-type 273 | | +--rw vlan-id union 274 | +--rw match-exact-tags? empty 275 +--rw rewrite {flexible-rewrites}? 276 +--rw (direction)? 277 +--:(symmetrical) 278 | +--rw symmetrical 279 | +--rw tag-rewrite {tag-rewrites}? 280 | +--rw pop-tags? uint8 281 | +--rw push-tag* [index] 282 | +--rw index uint8 283 | +--rw dot1q-tag 284 | +--rw tag-type dot1q-tag-type 285 | +--rw vlan-id ieee:vlanid 286 +--:(asymmetrical) {asymmetric-rewrites}? 287 +--rw ingress 288 | +--rw tag-rewrite {tag-rewrites}? 289 | +--rw pop-tags? uint8 290 | +--rw push-tag* [index] 291 | +--rw index uint8 292 | +--rw dot1q-tag 293 | +--rw tag-type dot1q-tag-type 294 | +--rw vlan-id ieee:vlanid 295 +--rw egress 296 +--rw tag-rewrite {tag-rewrites}? 297 +--rw pop-tags? uint8 298 +--rw push-tag* [index] 299 +--rw index uint8 300 +--rw dot1q-tag 301 +--rw tag-type dot1q-tag-type 302 +--rw vlan-id ieee:vlanid 303 augment /if:interfaces/if:interface: 304 +--rw flexible-encapsulation 305 +--rw local-traffic-default-encaps 306 +--rw tag* [index] 307 +--rw index uint8 308 +--rw dot1q-tag 309 +--rw tag-type dot1q-tag-type 310 +--rw vlan-id ieee:vlanid 312 5. L3 Interface VLAN YANG Module 314 This YANG module augments the encapsultion container defined in 315 Interface Extensions YANG [I-D.ietf-netmod-intf-ext-yang]. 317 file "ietf-if-l3-vlan@2017-03-13.yang" 318 module ietf-if-l3-vlan { 319 yang-version 1.1; 321 namespace "urn:ietf:params:xml:ns:yang:ietf-if-l3-vlan"; 323 prefix if-l3-vlan; 325 import ietf-interfaces { 326 prefix if; 327 } 328 import iana-if-type { 329 prefix ianaift; 330 } 332 import ieee802-dot1q-types { 333 prefix dot1q-types; 334 } 336 import ietf-interfaces-common { 337 prefix if-cmn; 338 } 340 organization 341 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 343 contact 344 "WG Web: 345 WG List: 347 WG Chair: Lou Berger 348 350 WG Chair: Kent Watsen 351 353 Editor: Robert Wilton 354 "; 356 description 357 "This YANG module models L3 VLAN sub-interfaces"; 359 revision 2017-03-13 { 360 description "Latest draft revision"; 362 reference 363 "Internet-Draft draft-ietf-netmod-sub-intf-vlan-model-01"; 364 } 366 /* 367 * Add support for the 802.1Q VLAN encapsulation syntax on layer 3 368 * terminated VLAN sub-interfaces. 369 */ 370 augment "/if:interfaces/if:interface/if-cmn:encapsulation/" + 371 "if-cmn:encaps-type" { 372 when "../if:type = 'ianaift:l2vlan' and 373 derived-from-or-self(../if-cmn:forwarding-mode, 374 'if-cmn:network-layer')" { 375 description 376 "Applies only to VLAN sub-interfaces that are operating at 377 layer 3"; 378 } 379 description 380 "Augment the generic interface encapsulation with an 381 encapsulation for layer 3 VLAN sub-interfaces"; 383 /* 384 * Matches a VLAN, or pair of VLAN Ids to classify traffic 385 * into an L3 service. 386 */ 387 case vlan { 388 container vlan { 389 description 390 "Match VLAN tagged frames with specific VLAN Ids"; 391 list tag { 392 must 'index != 0 or ' + 393 'count(../tag/index) != 2 or ' + 394 'dot1q-tag/tag-type = "s-vlan"' { 395 error-message 396 "When matching two tags, the outer tag must be of 397 S-VLAN tag type"; 398 description 399 "For IEEE 802.1Q interoperability, when matching two 400 tags, it is required that the outer tag is an S-VLAN, 401 and the inner tag is a C-VLAN"; 402 } 404 must 'index != 1 or ' + 405 'count(../tag/index) != 2 or ' + 406 'dot1q-tag/tag-type = "c-vlan"' { 407 error-message 408 "When matching two tags, the inner tag must be of 409 C-VLAN tag type"; 410 description 411 "For IEEE 802.1Q interoperability, when matching two 412 tags, it is required that the outer tag is an S-VLAN, 413 and the inner tag is a C-VLAN"; 414 } 416 key "index"; 417 min-elements 1; 418 max-elements 2; 420 description 421 "The tags to match, with the outermost tag to match with 422 index 0"; 423 leaf index { 424 type uint8 { 425 range "0..1"; 426 } 428 /* 429 * Only allow matching on an inner tag (at index 1), if 430 * also matching on the outer tag at the same time. 431 */ 432 must ". = 0 or 433 count(../../tag[index = 0]/index) > 0" { 434 error-message 435 "An inner tag can only be matched on when also 436 matching on an outer tag"; 437 description 438 "Only allow matching on an inner tag, if also 439 matching on the outer tag at the same time"; 440 } 442 description 443 "The index into the tag stack, outermost tag first"; 444 } 446 uses dot1q-types:dot1q-tag-classifier-grouping; 447 } 448 } 449 } 450 } 451 } 452 454 6. Flexible Encapsulation YANG Module 456 This YANG module augments the encapsultion container defined in 457 Interface Extensions YANG [I-D.ietf-netmod-intf-ext-yang]. 459 This YANG module also augments the interface container defined in 460 [RFC7223]. 462 file "ietf-flexible-encapsulation@2017-03-13.yang" 463 module ietf-flexible-encapsulation { 464 yang-version 1.1; 466 namespace 467 "urn:ietf:params:xml:ns:yang:ietf-flexible-encapsulation"; 469 prefix flex; 470 import ietf-interfaces { 471 prefix if; 472 } 474 import ietf-interfaces-common { 475 prefix if-cmn; 476 } 478 import ieee802-dot1q-types { 479 prefix dot1q-types; 480 } 482 organization 483 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 485 contact 486 "WG Web: 487 WG List: 489 WG Chair: Lou Berger 490 492 WG Chair: Kent Watsen 493 495 Editor: Robert Wilton 496 "; 498 description 499 "This YANG module describes interface configuration for flexible 500 VLAN matches and rewrites."; 502 revision 2017-03-13 { 503 description "Latest draft revision"; 505 reference 506 "Internet-Draft draft-ietf-netmod-sub-intf-vlan-model-01"; 507 } 509 feature flexible-encapsulation-rewrites { 510 description 511 "This feature indicates whether the network element supports 512 flexible Ethernet encapsulation that allows for matching VLAN 513 ranges and performing independent tag manipulations"; 514 } 516 feature flexible-rewrites { 517 description 518 "This feature indicates whether the network element supports 519 specifying flexible rewrite operations"; 520 } 522 feature asymmetric-rewrites { 523 description 524 "This feature indicates whether the network element supports 525 specifying different rewrite operations for the ingress 526 rewrite operation and egress rewrite operation."; 527 } 529 feature tag-rewrites { 530 description 531 "This feature indicates whether the network element supports 532 the flexible rewrite functionality specifying flexible tag 533 rewrites"; 534 } 536 /* 537 * flexible-match grouping. 538 * 539 * This grouping represents a flexible match. 540 * 541 * The rules for a flexible match are: 542 * 1. default, untagged, priority tag, or a stack of tags. 543 * - Each tag in the stack of tags matches: 544 * 1. tag type (802.1Q or 802.1ad) + 545 * 2. tag value: 546 * i. single tag 547 * ii. set of tag ranges/values. 548 * iii. "any" keyword 549 */ 550 grouping flexible-match { 551 description "Flexible match"; 552 choice match-type { 553 mandatory true; 554 description "Provides a choice of how the frames may be 555 matched"; 557 case default { 558 description "Default match"; 559 leaf default { 560 type empty; 561 description 562 "Default match. Matches all traffic not matched to any 563 other peer sub-interface by a more specific 564 encapsulation."; 565 } // leaf default 567 } // case default 569 case untagged { 570 description "Match untagged Ethernet frames only"; 571 leaf untagged { 572 type empty; 573 description 574 "Untagged match. Matches all untagged traffic."; 575 } // leaf untagged 576 } // case untagged 578 case priority-tagged { 579 description "Match priority tagged Ethernet frames only"; 581 container priority-tagged { 582 description "Priority tag match"; 583 leaf tag-type { 584 type dot1q-types:dot1q-tag-type; 585 description "The 802.1Q tag type of matched priority 586 tagged packets"; 587 } 588 } 589 } 591 case vlan-tagged { 592 container vlan-tagged { 593 description "Matches VLAN tagged frames"; 594 list tag { 595 must 'index != 0 or ' + 596 'count(../tag/index) != 2 or ' + 597 'dot1q-tag/tag-type = "s-vlan"' { 598 error-message 599 "When matching two tags, the outer tag must be of 600 S-VLAN tag type"; 601 description 602 "For IEEE 802.1Q interoperability, when matching two 603 tags, it is required that the outer tag is an 604 S-VLAN, and the inner tag is a C-VLAN"; 605 } 607 must 'index != 1 or ' + 608 'count(../tag/index) != 2 or ' + 609 'dot1q-tag/tag-type = "c-vlan"' { 610 error-message 611 "When matching two tags, the inner tag must be of 612 C-VLAN tag type"; 613 description 614 "For IEEE 802.1Q interoperability, when matching two 615 tags, it is required that the outer tag is an 616 S-VLAN, and the inner tag is a C-VLAN"; 617 } 619 key "index"; 620 min-elements 1; 621 max-elements 2; 622 description "The tags to match, with the outermost tag to 623 match assigned index 0"; 624 leaf index { 625 type uint8 { 626 range "0..1"; 627 } 629 must ". = 0 or 630 count(../../tag[index = 0]/index) > 0" { 631 error-message "An inner tag can only be matched on 632 when also matching on an outer tag"; 633 description "Only allow matching on an inner tag, if 634 also matching on the outer tags at the 635 same time"; 636 } 637 description 638 "The index into the tag stack, outermost tag first"; 639 } 641 uses 642 'dot1q-types:'+ 643 'dot1q-tag-ranges-or-any-classifier-grouping'; 644 } 646 leaf match-exact-tags { 647 type empty; 648 description 649 "If set, indicates that all 802.1Q VLAN tags in the 650 Ethernet frame header must be explicitly matched, i.e. 651 the EtherType following the matched tags must not be a 652 802.1Q tag EtherType. If unset then extra 802.1Q VLAN 653 tags are allowed."; 654 } 655 } 656 } 657 } // encaps-type 658 } 660 /* 661 * Grouping for tag-rewrite that can be expressed either 662 * symmetrically, or in the ingress and/or egress directions 663 * independently. 664 */ 665 grouping tag-rewrite { 666 description "Flexible rewrite"; 667 leaf pop-tags { 668 type uint8 { 669 range 1..2; 670 } 671 description "The number of tags to pop (or translate if used in 672 conjunction with push-tags)"; 673 } 675 list push-tag { 676 must 'index != 0 or ' + 677 'count(../push-tag/index) != 2 or ' + 678 'dot1q-tag/tag-type = "s-vlan"' { 679 error-message 680 "When pushing two tags, the outer tag must be of 681 S-VLAN tag type"; 682 description 683 "For IEEE 802.1Q interoperability, when pushing two 684 tags, it is required that the outer tag is an 685 S-VLAN, and the inner tag is a C-VLAN"; 686 } 688 must 'index != 1 or ' + 689 'count(../push-tag/index) != 2 or ' + 690 'dot1q-tag/tag-type = "c-vlan"' { 691 error-message 692 "When pushing two tags, the inner tag must be of 693 C-VLAN tag type"; 694 description 695 "For IEEE 802.1Q interoperability, when pushing two 696 tags, it is required that the outer tag is an 697 S-VLAN, and the inner tag is a C-VLAN"; 698 } 700 key "index"; 701 max-elements 2; 702 description "The number of tags to push (or translate if used 703 in conjunction with pop-tags)"; 704 /* 705 * Server should order by increasing index. 706 */ 707 leaf index { 708 type uint8 { 709 range 0..1; 710 } 711 /* 712 * Only allow a push of an inner tag if an outer tag is also 713 * being pushed. 714 */ 715 must ". != 0 or 716 count(../../push-tag[index = 0]/index) > 0" { 717 error-message "An inner tag can only be pushed if an outer 718 tag is also specified"; 719 description "Only allow a push of an inner tag if an outer 720 tag is also being pushed"; 721 } 723 description "The index into the tag stack"; 724 } 726 uses dot1q-types:dot1q-tag-classifier-grouping; 727 } 728 } 730 /* 731 * Grouping for all flexible rewrites of fields in the L2 header. 732 * 733 * This currently only includes flexible tag rewrites, but is 734 * designed to be extensible to cover rewrites of other fields in 735 * the L2 header if required. 736 */ 737 grouping flexible-rewrite { 738 description "Flexible rewrite"; 740 /* 741 * Tag rewrite. 742 * 743 * All tag rewrites are formed using a combination of pop-tags 744 * and push-tags operations. 745 */ 746 container tag-rewrite { 747 if-feature tag-rewrites; 748 description "Tag rewrite. Translate operations are expressed 749 as a combination of tag push and pop operations."; 750 uses tag-rewrite; 751 } 752 } 753 augment "/if:interfaces/if:interface/if-cmn:encapsulation/" + 754 "if-cmn:encaps-type" { 755 when "../if:type = 'if-cmn:ethSubInterface' and 756 derived-from-or-self(../if-cmn:forwarding-mode, 757 'if-cmn:layer-2-forwarding')" { 758 description "Applies only to Ethernet sub-interfaces that are 759 operating at transport layer 2"; 760 } 761 description 762 "Add flexible match and rewrite for VLAN sub-interfaces"; 764 /* 765 * A flexible encapsulation allows for the matching of ranges and 766 * sets of VLAN Ids. The structure is also designed to be 767 * extended to allow for matching/rewriting other fields within 768 * the L2 frame header if required. 769 */ 770 case flexible { 771 if-feature flexible-encapsulation-rewrites; 772 description "Flexible encapsulation and rewrite"; 773 container flexible { 774 description "Flexible encapsulation and rewrite"; 776 container match { 777 description 778 "The match used to classify frames to this interface"; 779 uses flexible-match; 780 } 782 container rewrite { 783 if-feature flexible-rewrites; 784 description "L2 frame rewrite operations"; 785 choice direction { 786 description "Whether the rewrite policy is symmetrical or 787 asymmetrical"; 788 case symmetrical { 789 container symmetrical { 790 uses flexible-rewrite; 791 description 792 "Symmetrical rewrite. Expressed in the ingress 793 direction, but the reverse operation is applied 794 to egress traffic"; 795 } 796 } 798 /* 799 * Allow asymmetrical rewrites to be specified. 800 */ 801 case asymmetrical { 802 if-feature asymmetric-rewrites; 803 description "Asymmetrical rewrite"; 804 container ingress { 805 uses flexible-rewrite; 806 description "Ingress rewrite"; 808 } 809 container egress { 810 uses flexible-rewrite; 811 description "Egress rewrite"; 812 } 813 } 814 } 815 } 816 } 817 } 818 } 820 augment "/if:interfaces/if:interface" { 821 when "if:type = 'if-cmn:ethSubInterface' and 822 derived-from-or-self(if-cmn:forwarding-mode, 823 'if-cmn:layer-2-forwarding')" { 824 description "Any L2 Ethernet sub-interfaces"; 825 } 826 description "Add flexible encapsulation configuration for VLAN 827 sub-interfaces"; 829 /* 830 * All flexible encapsulation specific interface configuration 831 * (except for the actual encapsulation and rewrite) is contained 832 * by a flexible-encapsulation container on the interface. 833 */ 834 container flexible-encapsulation { 835 description 836 "All per interface flexible encapsulation related fields"; 838 /* 839 * For encapsulations that match a range of VLANs (or Any), 840 * allow configuration to specify the default VLAN tag values 841 * to use for any traffic that is locally sourced from an 842 * interface on the device. 843 */ 844 container local-traffic-default-encaps { 845 description "The VLAN tags to use by default for locally 846 sourced traffic"; 847 list tag { 848 key "index"; 849 max-elements 2; 851 description 852 "The VLAN tags to use by locally sourced traffic"; 854 leaf index { 855 type uint8 { 856 range "0..1"; 857 } 859 /* 860 * Only allow an inner tag to be specified if an outer 861 * tag has also been specified. 862 */ 863 must ". = 0 or 864 count(../../tag[index = 0]/index) > 0" { 865 error-message "An inner tag can only be specified if an 866 outer tag has also been specified"; 867 description "Ensure that an inner tag cannot be 868 specified without an outer tag'"; 869 } 871 description "The index into the tag stack, outermost tag 872 assigned index 0"; 873 } 875 uses dot1q-types:dot1q-tag-classifier-grouping; 876 } 877 } 878 } 879 } 880 } 881 883 7. Acknowledgements 885 The authors would particularly like to thank John Messenger, Glenn 886 Parsons, and Dan Romascanu for their help progressing this draft. 888 The authors would also like to thank Alex Campbell, Eric Gray, Giles 889 Heron, Marc Holness, Iftekhar Hussain, Neil Ketley, William Lupton, 890 John Messenger, Glenn Parsons, Ludwig Pauwels, and members of the 891 IEEE 802.1 WG for their helpful reviews and feedback on this draft. 893 8. ChangeLog 895 8.1. WG version -01 897 o Tweaked the abstract. 899 o Removed unnecessary feature for the L3 sub-interface module. 901 o Update the 802.1Qcp type references. 903 o Remove extra tag container for L3 sub-interfaces YANG. 905 8.2. Version -04 907 o IEEE 802.1 specific types have been removed from the draft. These 908 are now referenced from the 802.1Qcp draft YANG modules. 910 o Fixed errors in the xpath expressions. 912 8.3. Version -03 914 o Incorporates feedback received from presenting to the IEEE 802.1 915 WG. 917 o Updates the modules for double tag matches/rewrites to restrict 918 the outer tag type to S-VLAN and inner tag type to C-VLAN. 920 o Updates the introduction to indicate primary use case is for IETF 921 forwarding protocols. 923 o Updates the objectives to make IEEE 802.1Q bridge interoperability 924 a key objective. 926 9. IANA Considerations 928 This document defines several new YANG module and the authors 929 politely request that IANA assigns unique names to the YANG module 930 files contained within this draft, and also appropriate URIs in the 931 "IETF XML Registry". 933 10. Security Considerations 935 The YANG module defined in this memo is designed to be accessed via 936 the NETCONF protocol RFC 6241 [RFC6241]. The lowest NETCONF layer is 937 the secure transport layer and the mandatory to implement secure 938 transport is SSH RFC 6242 [RFC6242]. The NETCONF access control 939 model RFC 6536 [RFC6536] provides the means to restrict access for 940 particular NETCONF users to a pre-configured subset of all available 941 NETCONF protocol operations and content. 943 There are a number of data nodes defined in this YANG module which 944 are writable/creatable/deletable (i.e. config true, which is the 945 default). These data nodes may be considered sensitive or vulnerable 946 in some network environments. Write operations (e.g. edit-config) to 947 these data nodes without proper protection can have a negative effect 948 on network operations. These are the subtrees and data nodes and 949 their sensitivity/vulnerability: 951 10.1. if-l3-vlan.yang 953 The nodes in the if-l3-vlan YANG module are concerned with matching 954 particular frames received on the network device to connect them to a 955 layer 3 forwarding instance, and as such adding/modifying/deleting 956 these nodes has a high risk of causing traffic to be lost because it 957 is not being classified correctly, or is being classified to a 958 separate sub-interface. The nodes, all under the subtree 959 /interfaces/interface/encapsulation/vlan, that are sensitive to this 960 are: 962 o tag 964 o tag/index 966 o tag/index/tag-type 968 o tag/index/vlan-id 970 10.2. flexible-encapsulation.yang 972 There are many nodes in the flexible-encapsulation YANG module that 973 are concerned with matching particular frames received on the network 974 device, and as such adding/modifying/deleting these nodes has a high 975 risk of causing traffic to be lost because it is not being classified 976 correctly, or is being classified to a separate sub-interface. The 977 nodes, all under the subtree 978 /interfaces/interface/encapsulation/flexible/match, that are 979 sensitive to this are: 981 o default 983 o untagged 985 o priority-tagged 987 o priority-tagged/tag-type 989 o vlan-tagged 991 o vlan-tagged/index 993 o vlan-tagged/index/dot1q-tag/vlan-type 995 o vlan-tagged/index/dot1q-tag/vlan-id 997 o vlan-tagged/match-exact-tags 998 There are also many modes in the flexible-encapsulation YANG module 999 that are concerned with rewriting the fields in the L2 header for 1000 particular frames received on the network device, and as such 1001 adding/modifying/deleting these nodes has a high risk of causing 1002 traffic to be dropped or incorrectly processed on peer network 1003 devices, or it could cause layer 2 tunnels to go down due to a 1004 mismatch in negotiated MTU. The nodes, all under the subtree 1005 /interfaces/interface/encapsulation/flexible/rewrite, that are 1006 sensitive to this are: 1008 o symmetrical/tag-rewrite/pop-tags 1010 o symmetrical/tag-rewrite/push-tag 1012 o symmetrical/tag-rewrite/push-tag/index 1014 o symmetrical/tag-rewrite/push-tag/dot1q-tag/tag-type 1016 o symmetrical/tag-rewrite/push-tag/dot1q-tag/vlan-id 1018 o asymmetrical/ingress/tag-rewrite/pop-tags 1020 o asymmetrical/ingress/tag-rewrite/push-tag 1022 o asymmetrical/ingress/tag-rewrite/push-tag/index 1024 o asymmetrical/ingress/tag-rewrite/push-tag/dot1q-tag/tag-type 1026 o asymmetrical/ingress/tag-rewrite/push-tag/dot1q-tag/vlan-id 1028 o asymmetrical/egress/tag-rewrite/pop-tags 1030 o asymmetrical/egress/tag-rewrite/push-tag 1032 o asymmetrical/egress/tag-rewrite/push-tag/index 1034 o asymmetrical/egress/tag-rewrite/push-tag/dot1q-tag/tag-type 1036 o asymmetrical/egress/tag-rewrite/push-tag/dot1q-tag/vlan-id 1038 Nodes in the flexible-encapsulation YANG module that are concerned 1039 with the VLAN tags to use for traffic sourced from the network 1040 element could cause protocol sessions (such as CFM) to fail if they 1041 are added, modified or deleted. The nodes, all under the subtree 1042 /interfaces/interface/flexible-encapsulation/local-traffic-default- 1043 encaps that are sensitive to this are: 1045 o tag 1046 o tag/index 1048 o tag/dot1q-tag/tag-type 1050 o tag/dot1q-tag/vlan-id 1052 11. References 1054 11.1. Normative References 1056 [I-D.ietf-netmod-intf-ext-yang] 1057 Wilton, R., Ball, D., tsingh@juniper.net, t., and S. 1058 Sivaraj, "Common Interface Extension YANG Data Models", 1059 draft-ietf-netmod-intf-ext-yang-04 (work in progress), 1060 March 2017. 1062 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1063 Requirement Levels", BCP 14, RFC 2119, 1064 DOI 10.17487/RFC2119, March 1997, 1065 . 1067 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 1068 Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, 1069 . 1071 [RFC7224] Bjorklund, M., "IANA Interface Type YANG Module", 1072 RFC 7224, DOI 10.17487/RFC7224, May 2014, 1073 . 1075 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1076 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1077 . 1079 11.2. Informative References 1081 [dot1Qcp] Holness, M., "802.1Qcp Bridges and Bridged Networks - 1082 Amendment: YANG Data Model", 2016. 1084 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1085 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 1086 December 1998, . 1088 [RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, 1089 "Encapsulation Methods for Transport of Ethernet over MPLS 1090 Networks", RFC 4448, DOI 10.17487/RFC4448, April 2006, 1091 . 1093 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private 1094 LAN Service (VPLS) Using BGP for Auto-Discovery and 1095 Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, 1096 . 1098 [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private 1099 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 1100 Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, 1101 . 1103 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1104 and A. Bierman, Ed., "Network Configuration Protocol 1105 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1106 . 1108 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1109 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1110 . 1112 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 1113 Protocol (NETCONF) Access Control Model", RFC 6536, 1114 DOI 10.17487/RFC6536, March 2012, 1115 . 1117 Appendix A. Comparison with the IEEE 802.1Q Configuration Model 1119 In addition to the sub-interface based YANG model proposed here, the 1120 IEEE 802.1Q working group is also developing a YANG model for the 1121 configuration of 802.1Q VLANs. This raises the valid question as to 1122 whether the models overlap and whether it is necessary or beneficial 1123 to have two different models for superficially similar constructs. 1124 This section aims to answer that question by summarizing and 1125 comparing the two models. 1127 A.1. Sub-interface based configuration model overview 1129 The key features of the sub-interface based configuration model can 1130 be summarized as: 1132 o The model is primarily designed to enable layer 2 and layer 3 1133 services on Ethernet interfaces that can be defined in a very 1134 flexible way to meet the varied requirements of service providers. 1136 o Traffic is classified from an Ethernet-like interface to sub- 1137 interfaces based on fields in the layer 2 header. This is often 1138 based on VLAN Ids contained in the frame, but the model is 1139 extensible to other arbitrary fields in the frame header. 1141 o Sub-interfaces are just a type of if:interface and hence support 1142 any feature configuration YANG models that can be applied 1143 generally to interfaces. For example, QoS or ACL models that 1144 reference if:interface can be applied to the sub-interfaces, or 1145 the sub-interface can be used as an Access Circuit in L2VPN or 1146 L3VPN models that reference if:interface. 1148 o In the sub-interface based configuration model, the classification 1149 of traffic arriving on an interface to a given sub-interface, 1150 based on fields in the layer 2 header, is completely independent 1151 of how the traffic is forwarded. The sub-interface can be 1152 referenced (via references to if:interface) by other models that 1153 specify how traffic is forwarded; thus sub-interfaces can support 1154 multiple different forwarding paradigms, including but not limited 1155 to: layer 3 (IPv4/IPv6), layer 2 pseudowires (over MPLS or IP), 1156 VPLS instances, EVPN instance. 1158 o The model is flexible in the scope of the VLAN Identifier space. 1159 I.e. by default VLAN Ids can be scoped locally to a single 1160 Ethernet-like trunk interface, but the scope is determined by the 1161 forwarding paradigm that is used. 1163 A.2. IEEE 802.1Q Bridge Configuration Model Overview 1165 The key features of the IEEE 802.1Q bridge configuration model can be 1166 summarized as: 1168 o Each VLAN bridge component has a set of Ethernet interfaces that 1169 are members of that bridge. Sub-interfaces are not used, nor 1170 required in the 802.1Q bridge model. 1172 o Within a VLAN bridge component, the VLAN tag in the packet is 1173 used, along with the destination MAC address, to determine how to 1174 forward the packet. Other forwarding paradigms are not supported 1175 by the 802.1Q model. 1177 o Classification of traffic to a VLAN bridge component is based only 1178 on the Ethernet interface that it arrived on. 1180 o VLAN Identifiers are scoped to a VLAN bridge component. Often 1181 devices only support a single bridge component and hence VLANs are 1182 scoped globally within the device. 1184 o Feature configuration is specified in the context of the bridge, 1185 or particular VLANs on a bridge. 1187 A.3. Possible Overlap Between the Two Models 1189 Both models can be used for configuring similar basic layer 2 1190 forwarding topologies. The 802.1Q bridge configuration model is 1191 optimised for configuring Virtual LANs that span across enterprises 1192 and data centers. 1194 The sub-interface model can also be used for configuring equivalent 1195 Virtual LAN networks that span across enterprises and data centers, 1196 but often requires more configuration to be able to configure the 1197 equivalent constructs to the 802.1Q bridge model. 1199 The sub-interface model really excels when implementing flexible L2 1200 and L3 services, where those services may be handled on the same 1201 physical interface, and where the VLAN Identifier is being solely 1202 used to identify the customer or service that is being provided 1203 rather than a Virtual LAN. The sub-interface model provides more 1204 flexibility as to how traffic can be classified, how features can be 1205 applied to traffic streams, and how the traffic is to be forwarded. 1207 Conversely, the 802.1Q bridge model can also be use to implement L2 1208 services in some scenarios, but only if the forwarding paradigm being 1209 used to implement the service is the native Ethernet forwarding 1210 specified in 802.1Q - other forwarding paradigms such as pseudowires 1211 or VPLS are not supported. The 802.1Q bridge model does not 1212 implement L3 services at all, although this can be partly mitigated 1213 by using a virtual L3 interface construct that is a separate logical 1214 Ethernet-like interface which is a member of the bridge. 1216 In conclusion, it is valid for both of these models to exist since 1217 they have different deployment scenarios for which they are 1218 optimized. Devices may choose which of the models (or both) to 1219 implement depending on what functionality the device is being 1220 designed for. 1222 Authors' Addresses 1224 Robert Wilton (editor) 1225 Cisco Systems 1227 Email: rwilton@cisco.com 1229 David Ball 1230 Cisco Systems 1232 Email: daviball@cisco.com 1233 Tapraj Singh 1234 Cisco Systems 1236 Email: tapsingh@cisco.com 1238 Selvakumar Sivaraj 1239 Juniper Networks 1241 Email: ssivaraj@juniper.net