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