idnits 2.17.1 draft-ietf-netmod-sub-intf-vlan-model-02.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 211 has weird spacing: '...ag-type dot...' == Line 215 has weird spacing: '...ag-type dot...' == Line 276 has weird spacing: '...ag-type dot...' == Line 280 has weird spacing: '...ag-type dot...' == Line 292 has weird spacing: '...ag-type dot...' == (7 more instances...) == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 3, 2017) is 2486 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC7224' is defined on line 1107, 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: January 4, 2018 Cisco Systems 6 S. Sivaraj 7 Juniper Networks 8 July 3, 2017 10 Sub-interface VLAN YANG Data Models 11 draft-ietf-netmod-sub-intf-vlan-model-02 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 January 4, 2018. 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 . . . . . . . . . . . . . . . . 8 76 6. Flexible Encapsulation YANG Module . . . . . . . . . . . . . 11 77 7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 19 78 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 79 9. ChangeLog . . . . . . . . . . . . . . . . . . . . . . . . . . 20 80 9.1. WG version -02 . . . . . . . . . . . . . . . . . . . . . 20 81 9.2. WG version -01 . . . . . . . . . . . . . . . . . . . . . 20 82 9.3. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 20 83 9.4. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 20 84 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 85 11. Security Considerations . . . . . . . . . . . . . . . . . . . 21 86 11.1. if-l3-vlan.yang . . . . . . . . . . . . . . . . . . . . 21 87 11.2. flexible-encapsulation.yang . . . . . . . . . . . . . . 22 88 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 89 12.1. Normative References . . . . . . . . . . . . . . . . . . 24 90 12.2. Informative References . . . . . . . . . . . . . . . . . 24 91 Appendix A. Comparison with the IEEE 802.1Q Configuration Model 25 92 A.1. Sub-interface based configuration model overview . . . . 25 93 A.2. IEEE 802.1Q Bridge Configuration Model Overview . . . . . 26 94 A.3. Possible Overlap Between the Two Models . . . . . . . . . 26 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 97 1. Introduction 99 This document defines two YANG [RFC7950] modules that augment the 100 encapsulation choice YANG element defined in Interface Extensions 101 YANG [I-D.ietf-netmod-intf-ext-yang] and the generic interfaces data 102 model defined in [RFC7223]. The two modules provide configuration 103 nodes to support classification of Ethernet/VLAN traffic to sub- 104 interfaces, that can have interface based feature and service 105 configuration applied to them. 107 The purpose of these models is to allow IETF defined forwarding 108 protocols, such as IPv6 [RFC2460], Ethernet Pseudo Wires [RFC4448] 109 and VPLS [RFC4761] [RFC4762] to be configurable via YANG when 110 interoperating with VLAN tagged traffic received from an IEEE 802.1Q 111 compliant bridge. 113 In the case of layer 2 Ethernet services, the flexible encapsulation 114 module also supports flexible rewriting of the VLAN tags contained 115 the in frame header. 117 For reference, a comparison between the sub-interface based YANG 118 model documented in this draft and an IEEE 802.1Q bridge model is 119 described in Appendix A. 121 In summary, the YANG modules defined in this internet draft are: 123 if-l3-vlan.yang - Defines the model for basic classification of 124 VLAN tagged traffic to L3 transport services 126 flexible-encapsulation.yang - Defines the model for flexible 127 classification of Ethernet/VLAN traffic to L2 transport services 129 1.1. Terminology 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in RFC 2119 [RFC2119]. 135 Sub-interface: A sub-interface is a small augmentation of a regular 136 interface in the standard YANG module for Interface Management that 137 represents a subset of the traffic handled by its parent interface. 138 As such, it supports both configuration and operational data using 139 any other YANG models that augment or reference interfaces in the 140 normal way. It is defined in Interface Extensions YANG 141 [I-D.ietf-netmod-intf-ext-yang]. 143 1.2. Tree Diagrams 145 A simplified graphical representation of the data model is used in 146 this document. The meaning of the symbols in these diagrams is as 147 follows: 149 o Brackets "[" and "]" enclose list keys. 151 o Abbreviations before data node names: "rw" means configuration 152 (read-write), and "ro" means state data (read-only). 154 o Symbols after data node names: "?" means an optional node, "!" 155 means a presence container, and "*" denotes a list or leaf-list. 157 o Parentheses enclose choice and case nodes, and case nodes are also 158 marked with a colon (":"). 160 o Ellipsis ("...") stands for contents of subtrees that are not 161 shown. 163 2. Objectives 165 The primary aim of the YANG modules contained in this draft is to 166 provide the core model that is required to implement VLAN transport 167 services on router based devices that is fully compatible with IEEE 168 802.1Q compliant bridges. 170 A secondary aim is for the modules to be structured in such a way 171 that they can be cleanly extended in future. 173 2.1. Interoperability with IEEE 802.1Q compliant bridges 175 The modules defined in this document are designed to fully 176 interoperate with IEEE 802.1Q compliant bridges. In particular, the 177 models are restricted to only matching, adding, or rewriting the 178 802.1Q VLAN tags in frames in ways that are compatible with IEEE 179 802.1Q compliant bridges. 181 2.2. Extensibility 183 The modules are structured in such a way that they can be sensibly 184 extended. In particular: 186 The tag stack is represented as a list to allow a tag stack of 187 more than two tags to be supported if necessary in future. 189 The tag stack list elements allow other models, or vendors, to 190 include additional forms of tag matching and rewriting. The 191 intention, however, is that it should not be necessary to have any 192 vendor specific extensions to any of the YANG models defined in 193 this document to implement standard Ethernet and VLAN services. 195 3. L3 Interface VLAN Model 197 The L3 Interface VLAN model provides appropriate leaves for 198 termination of an 802.1Q VLAN tagged segment to a sub-interface based 199 L3 service. It allows for termination of traffic with up to two 200 802.1Q VLAN tags. 202 The "if-l3-vlan" YANG module has the following structure: 204 module: ietf-if-l3-vlan 205 augment /if:interfaces/if:interface/if-cmn:encapsulation/ 206 if-cmn:encaps-type: 207 +--:(dot1q-vlan) 208 +--rw dot1q-vlan 209 +--rw outer-tag! 210 | +--rw dot1q-tag 211 | +--rw tag-type dot1q-tag-type 212 | +--rw vlan-id ieee:vlanid 213 +--rw second-tag! 214 +--rw dot1q-tag 215 +--rw tag-type dot1q-tag-type 216 +--rw vlan-id ieee:vlanid 218 4. Flexible Encapsulation Model 220 The Flexible Encapsulation model is designed to allow for the 221 flexible provisioning of layer 2 services. It provides the 222 capability to classify Ethernet/VLAN frames received on an Ethernet 223 trunk interface to sub-interfaces based on the fields available in 224 the layer 2 headers. Once classified to sub-interfaces, it provides 225 the capability to selectively modify fields within the layer 2 226 headers before the frame is handed off to the appropriate forwarding 227 code for further handling. 229 The model supports a common core set of layer 2 header matches based 230 on the 802.1Q tag type and VLAN Ids contained within the header up to 231 a tag stack depth of two tags. 233 The model supports flexible rewrites of the layer 2 frame header for 234 data frames as they are processed on the interface. It defines a set 235 of standard tag manipulations that allow for the insertion, removal, 236 or rewrite of one or two 802.1Q VLAN tags. The expectation is that 237 manipulations are generally implemented in a symmetrical fashion, 238 i.e. if a manipulation is performed on ingress traffic on an 239 interface then the reverse manipulation is always performed on egress 240 traffic out of the same interface. However, the model also allows 241 for asymmetrical rewrites, which may be required to implement some 242 forwarding models (such as E-Tree). 244 The structure of the model is currently limited to matching or 245 rewriting a maximum of two 802.1Q tags in the frame header but has 246 been designed to be easily extensible to matching/rewriting three or 247 more VLAN tags in future, if required. 249 The final aim for the model design is for it to be cleanly extensible 250 to add in additional match and rewrite criteria of the layer 2 251 header, such as matching on the source or destination MAC address, 252 PCP or DEI fields in the 802.1Q tags, or the EtherType of the frame 253 payload. Rewrites can also be extended to allow for modification of 254 other fields within the layer 2 frame header. 256 The "flexible-encapsulation" YANG module has the following structure: 258 module: ietf-flexible-encapsulation 259 augment /if:interfaces/if:interface/if-cmn:encapsulation/ 260 if-cmn:encaps-type: 261 +--:(flexible) 262 +--rw flexible 263 +--rw match 264 | +--rw (match-type) 265 | +--:(default) 266 | | +--rw default? empty 267 | +--:(untagged) 268 | | +--rw untagged? empty 269 | +--:(dot1q-priority-tagged) 270 | | +--rw dot1q-priority-tagged 271 | | +--rw tag-type? dot1q-types:dot1q-tag-type 272 | +--:(dot1q-vlan-tagged) 273 | +--rw dot1q-vlan-tagged 274 | +--rw outer-tag! 275 | | +--rw dot1q-tag 276 | | +--rw tag-type dot1q-tag-type 277 | | +--rw vlan-id union 278 | +--rw second-tag! 279 | | +--rw dot1q-tag 280 | | +--rw tag-type dot1q-tag-type 281 | | +--rw vlan-id union 282 | +--rw match-exact-tags? empty 283 +--rw rewrite {flexible-rewrites}? 284 | +--rw (direction)? 285 | +--:(symmetrical) 286 | | +--rw symmetrical 287 | | +--rw dot1q-tag-rewrite {dot1q-tag-rewrites}? 288 | | +--rw pop-tags? uint8 289 | | +--rw push-tags 290 | | +--rw outer-tag! 291 | | | +--rw dot1q-tag 292 | | | +--rw tag-type dot1q-tag-type 293 | | | +--rw vlan-id ieee:vlanid 294 | | +--rw second-tag! 295 | | +--rw dot1q-tag 296 | | +--rw tag-type dot1q-tag-type 297 | | +--rw vlan-id ieee:vlanid 298 | +--:(asymmetrical) {asymmetric-rewrites}? 299 | +--rw ingress 300 | | +--rw dot1q-tag-rewrite {dot1q-tag-rewrites}? 301 | | +--rw pop-tags? uint8 302 | | +--rw push-tags 303 | | +--rw outer-tag! 304 | | | +--rw dot1q-tag 305 | | | +--rw tag-type dot1q-tag-type 306 | | | +--rw vlan-id ieee:vlanid 307 | | +--rw second-tag! 308 | | +--rw dot1q-tag 309 | | +--rw tag-type dot1q-tag-type 310 | | +--rw vlan-id ieee:vlanid 311 | +--rw egress 312 | +--rw dot1q-tag-rewrite {dot1q-tag-rewrites}? 313 | +--rw pop-tags? uint8 314 | +--rw push-tags 315 | +--rw outer-tag! 316 | | +--rw dot1q-tag 317 | | +--rw tag-type dot1q-tag-type 318 | | +--rw vlan-id ieee:vlanid 319 | +--rw second-tag! 320 | +--rw dot1q-tag 321 | +--rw tag-type dot1q-tag-type 322 | +--rw vlan-id ieee:vlanid 323 +--rw local-traffic-default-encaps! 324 +--rw outer-tag! 325 | +--rw dot1q-tag 326 | +--rw tag-type dot1q-tag-type 327 | +--rw vlan-id ieee:vlanid 328 +--rw second-tag! 329 +--rw dot1q-tag 330 +--rw tag-type dot1q-tag-type 331 +--rw vlan-id ieee:vlanid 333 5. L3 Interface VLAN YANG Module 335 This YANG module augments the encapsultion container defined in 336 Interface Extensions YANG [I-D.ietf-netmod-intf-ext-yang]. 338 file "ietf-if-l3-vlan@2017-07-03.yang" 339 module ietf-if-l3-vlan { 340 yang-version 1.1; 342 namespace "urn:ietf:params:xml:ns:yang:ietf-if-l3-vlan"; 344 prefix if-l3-vlan; 346 import ietf-interfaces { 347 prefix if; 348 } 350 import iana-if-type { 351 prefix ianaift; 352 } 354 import ieee802-dot1q-types { 355 prefix dot1q-types; 356 } 358 import ietf-interfaces-common { 359 prefix if-cmn; 360 } 362 organization 363 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 365 contact 366 "WG Web: 367 WG List: 369 WG Chair: Lou Berger 370 372 WG Chair: Kent Watsen 373 375 Editor: Robert Wilton 376 "; 378 description 379 "This YANG module models L3 VLAN sub-interfaces"; 381 revision 2017-07-03 { 382 description "Latest draft revision"; 384 reference 385 "Internet-Draft draft-ietf-netmod-sub-intf-vlan-model-02"; 386 } 388 /* 389 * Add support for the 802.1Q VLAN encapsulation syntax on layer 3 390 * terminated VLAN sub-interfaces. 391 */ 392 augment "/if:interfaces/if:interface/if-cmn:encapsulation/" + 393 "if-cmn:encaps-type" { 394 when 395 "derived-from-or-self(../if:type, 396 'ianaift:ethernetCsmacd') or 397 derived-from-or-self(../if:type, 398 'ianaift:ieee8023adLag') or 399 derived-from-or-self(../if:type, 400 'if-cmn:ethSubInterface')" { 401 description 402 "Applies only to Ethernet-like interfaces and 403 sub-interfaces"; 404 } 406 description 407 "Augment the generic interface encapsulation with an 408 basic 802.1Q VLAN encapsulation for sub-interfaces."; 410 /* 411 * Matches a single VLAN Id, or pair of VLAN Ids to classify 412 * traffic into an L3 service. 413 */ 414 case dot1q-vlan { 415 container dot1q-vlan { 416 must 417 'count(../../if-cmn:forwarding-mode) = 0 or ' + 418 'derived-from-or-self(../../if-cmn:forwarding-mode,' + 419 '"if-cmn:layer-3-forwarding")' { 420 error-message 421 "If the interface forwarding-mode leaf is set then it 422 must be set to an identity that derives from 423 layer-3-forwarding"; 425 description 426 "The forwarding-mode leaf on an interface can 427 optionally be used to enforce consistency of 428 configuration"; 430 } 432 description 433 "Match VLAN tagged frames with specific VLAN Ids"; 434 container outer-tag { 435 presence "The outermost VLAN tag exists"; 437 description 438 "Classifies traffic using the outermost VLAN tag on the 439 frame."; 441 uses dot1q-types:dot1q-tag-classifier-grouping; 442 } 444 container second-tag { 445 must 446 '../outer-tag/dot1q-tag/tag-type = "s-vlan" and ' + 447 'dot1q-tag/tag-type = "c-vlan"' { 449 error-message 450 "When matching two tags, the outermost tag must be 451 specified and of S-VLAN type and the second outermost 452 tag must be of C-VLAN tag type"; 454 description 455 "For IEEE 802.1Q interoperability, when matching two 456 tags, it is required that the outermost tag exists and 457 is an S-VLAN, and the second outermost tag is a 458 C-VLAN"; 459 } 461 presence "The second outermost VLAN tag exists"; 463 description 464 "Classifies traffic using the second outermost VLAN tag 465 on the frame."; 467 uses dot1q-types:dot1q-tag-classifier-grouping; 468 } 469 } 470 } 471 } 472 } 473 475 6. Flexible Encapsulation YANG Module 477 This YANG module augments the encapsultion container defined in 478 Interface Extensions YANG [I-D.ietf-netmod-intf-ext-yang]. 480 This YANG module also augments the interface container defined in 481 [RFC7223]. 483 file "ietf-flexible-encapsulation@2017-07-03.yang" 484 module ietf-flexible-encapsulation { 485 yang-version 1.1; 487 namespace 488 "urn:ietf:params:xml:ns:yang:ietf-flexible-encapsulation"; 490 prefix flex; 492 import ietf-interfaces { 493 prefix if; 494 } 496 import iana-if-type { 497 prefix ianaift; 498 } 500 import ietf-interfaces-common { 501 prefix if-cmn; 502 } 504 import ieee802-dot1q-types { 505 prefix dot1q-types; 506 } 508 organization 509 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 511 contact 512 "WG Web: 513 WG List: 515 WG Chair: Lou Berger 516 518 WG Chair: Kent Watsen 519 521 Editor: Robert Wilton 522 "; 524 description 525 "This YANG module describes interface configuration for flexible 526 VLAN matches and rewrites."; 528 revision 2017-07-03 { 529 description "Latest draft revision"; 531 reference 532 "Internet-Draft draft-ietf-netmod-sub-intf-vlan-model-02"; 533 } 535 feature flexible-rewrites { 536 description 537 "This feature indicates whether the network element supports 538 specifying flexible rewrite operations"; 539 } 541 feature asymmetric-rewrites { 542 description 543 "This feature indicates whether the network element supports 544 specifying different rewrite operations for the ingress 545 rewrite operation and egress rewrite operation."; 546 } 548 feature dot1q-tag-rewrites { 549 description 550 "This feature indicates whether the network element supports 551 the flexible rewrite functionality specifying flexible 802.1Q 552 tag rewrites"; 553 } 555 /* 556 * flexible-match grouping. 557 * 558 * This grouping represents a flexible match. 559 * 560 * The rules for a flexible match are: 561 * 1. default, untagged, priority tag, or a stack of tags. 562 * - Each tag in the stack of tags matches: 563 * 1. tag type (802.1Q or 802.1ad) + 564 * 2. tag value: 565 * i. single tag 566 * ii. set of tag ranges/values. 567 * iii. "any" keyword 568 */ 569 grouping flexible-match { 570 description "Flexible match"; 571 choice match-type { 572 mandatory true; 573 description "Provides a choice of how the frames may be 574 matched"; 576 case default { 577 description "Default match"; 578 leaf default { 579 type empty; 580 description 581 "Default match. Matches all traffic not matched to any 582 other peer sub-interface by a more specific 583 encapsulation."; 584 } // leaf default 585 } // case default 587 case untagged { 588 description "Match untagged Ethernet frames only"; 589 leaf untagged { 590 type empty; 591 description 592 "Untagged match. Matches all untagged traffic."; 593 } // leaf untagged 594 } // case untagged 596 case dot1q-priority-tagged { 597 description 598 "Match 802.1Q priority tagged Ethernet frames only"; 600 container dot1q-priority-tagged { 601 description "802.1Q priority tag match"; 602 leaf tag-type { 603 type dot1q-types:dot1q-tag-type; 604 description "The 802.1Q tag type of matched priority 605 tagged packets"; 606 } 607 } 608 } 610 case dot1q-vlan-tagged { 611 container dot1q-vlan-tagged { 612 description "Matches VLAN tagged frames"; 614 container outer-tag { 615 presence "The outermost VLAN tag exists"; 617 description 618 "Classifies traffic using the outermost VLAN tag on the 619 frame."; 621 uses 622 'dot1q-types:'+ 623 'dot1q-tag-ranges-or-any-classifier-grouping'; 624 } 626 container second-tag { 627 must 628 '../outer-tag/dot1q-tag/tag-type = "s-vlan" and ' + 629 'dot1q-tag/tag-type = "c-vlan"' { 631 error-message 632 "When matching two tags, the outermost tag must be 633 specified and of S-VLAN type and the second 634 outermost tag must be of C-VLAN tag type"; 636 description 637 "For IEEE 802.1Q interoperability, when matching two 638 tags, it is required that the outermost tag exists 639 and is an S-VLAN, and the second outermost tag is a 640 C-VLAN"; 641 } 643 presence "The second outermost VLAN tag exists"; 645 description 646 "Classifies traffic using the second outermost VLAN tag 647 on the frame."; 649 uses 650 'dot1q-types:'+ 651 'dot1q-tag-ranges-or-any-classifier-grouping'; 652 } 654 leaf match-exact-tags { 655 type empty; 656 description 657 "If set, indicates that all 802.1Q VLAN tags in the 658 Ethernet frame header must be explicitly matched, i.e. 659 the EtherType following the matched tags must not be a 660 802.1Q tag EtherType. If unset then extra 802.1Q VLAN 661 tags are allowed."; 662 } 663 } 664 } 665 } // encaps-type 667 } 669 /* 670 * Grouping for tag-rewrite that can be expressed either 671 * symmetrically, or in the ingress and/or egress directions 672 * independently. 673 */ 674 grouping dot1q-tag-rewrite { 675 description "Flexible rewrite"; 676 leaf pop-tags { 677 type uint8 { 678 range 1..2; 679 } 680 description "The number of tags to pop (or translate if used in 681 conjunction with push-tags)"; 682 } 684 container push-tags { 685 description "The 802.1Q tags to push (or translate if used in 686 conjunction with pop-tags)"; 688 container outer-tag { 689 presence 690 "Indicates existence of the outermost VLAN tag to 691 push/rewrite"; 693 description 694 "The outermost VLAN tag to push onto the frame."; 696 uses dot1q-types:dot1q-tag-classifier-grouping; 697 } 699 container second-tag { 700 must 701 '../outer-tag/dot1q-tag/tag-type = "s-vlan" and ' + 702 'dot1q-tag/tag-type = "c-vlan"' { 704 error-message 705 "When pushing/rewriting two tags, the outermost tag must be 706 specified and of S-VLAN type and the second outermost tag 707 must be of C-VLAN tag type"; 709 description 710 "For IEEE 802.1Q interoperability, when pushing two tags, 711 it is required that the outermost tag exists and is an 712 S-VLAN, and the second outermost tag is a C-VLAN"; 713 } 714 presence 715 "Indicates existence of a second outermost VLAN tag to 716 push/rewrite."; 718 description 719 "The second outermost VLAN tag to push onto the frame."; 721 uses dot1q-types:dot1q-tag-classifier-grouping; 722 } 723 } 724 } 726 /* 727 * Grouping for all flexible rewrites of fields in the L2 header. 728 * 729 * This currently only includes flexible tag rewrites, but is 730 * designed to be extensible to cover rewrites of other fields in 731 * the L2 header if required. 732 */ 733 grouping flexible-rewrite { 734 description "Flexible rewrite"; 736 /* 737 * Tag rewrite. 738 * 739 * All tag rewrites are formed using a combination of pop-tags 740 * and push-tags operations. 741 */ 742 container dot1q-tag-rewrite { 743 if-feature dot1q-tag-rewrites; 744 description "Tag rewrite. Translate operations are expressed 745 as a combination of tag push and pop operations."; 746 uses dot1q-tag-rewrite; 747 } 748 } 749 augment "/if:interfaces/if:interface/if-cmn:encapsulation/" + 750 "if-cmn:encaps-type" { 751 when 752 "derived-from-or-self(../if:type, 753 'ianaift:ethernetCsmacd') or 754 derived-from-or-self(../if:type, 755 'ianaift:ieee8023adLag') or 756 derived-from-or-self(../if:type, 757 'if-cmn:ethSubInterface')" { 758 description 759 "Applies only to Ethernet-like interfaces and 760 sub-interfaces"; 761 } 762 description 763 "Add flexible match and rewrite for VLAN sub-interfaces"; 765 /* 766 * A flexible encapsulation allows for the matching of ranges and 767 * sets of VLAN Ids. The structure is also designed to be 768 * extended to allow for matching/rewriting other fields within 769 * the L2 frame header if required. 770 */ 771 case flexible { 772 description "Flexible encapsulation and rewrite"; 773 container flexible { 774 must 775 'count(../../if-cmn:forwarding-mode) = 0 or ' + 776 'derived-from-or-self(../../if-cmn:forwarding-mode,' + 777 '"if-cmn:layer-2-forwarding")' { 778 error-message 779 "If the interface forwarding-mode leaf is set then it 780 must be set to an identity that derives from 781 layer-2-forwarding"; 783 description 784 "The forwarding-mode leaf on an interface can 785 optionally be used to enforce consistency of 786 configuration"; 787 } 789 description "Flexible encapsulation and rewrite"; 791 container match { 792 description 793 "The match used to classify frames to this interface"; 794 uses flexible-match; 795 } 797 container rewrite { 798 if-feature flexible-rewrites; 799 description "L2 frame rewrite operations"; 800 choice direction { 801 description 802 "Whether the rewrite policy is symmetrical or 803 asymmetrical"; 804 case symmetrical { 805 container symmetrical { 806 uses flexible-rewrite; 807 description 808 "Symmetrical rewrite. Expressed in the ingress 809 direction, but the reverse operation is applied to 810 egress traffic"; 811 } 812 } 814 /* 815 * Allow asymmetrical rewrites to be specified. 816 */ 817 case asymmetrical { 818 if-feature asymmetric-rewrites; 819 description "Asymmetrical rewrite"; 820 container ingress { 821 uses flexible-rewrite; 822 description "Ingress rewrite"; 823 } 824 container egress { 825 uses flexible-rewrite; 826 description "Egress rewrite"; 827 } 828 } 829 } 830 } 832 /* 833 * For encapsulations that match a range of VLANs (or Any), 834 * allow configuration to specify the default 802.1Q VLAN tag 835 * values to use for any traffic that is locally sourced from 836 * an interface on the device. 837 */ 838 container local-traffic-default-encaps { 839 presence 840 "A local traffic default encapsulation has been 841 specified"; 842 description 843 "The 802.1Q VLAN tags to use by default for locally 844 sourced traffic"; 846 container outer-tag { 847 presence 848 "Indicates existence of the outermost VLAN tag"; 850 description 851 "The outermost VLAN tag for locally sourced traffic"; 853 uses dot1q-types:dot1q-tag-classifier-grouping; 854 } 856 container second-tag { 857 must 858 '../outer-tag/dot1q-tag/tag-type = "s-vlan" and ' + 859 'dot1q-tag/tag-type = "c-vlan"' { 861 error-message 862 "When specifying two tags, the outermost tag must be 863 specified and of S-VLAN type and the second outermost 864 tag must be of C-VLAN tag type"; 866 description 867 "For IEEE 802.1Q interoperability, when specifying two 868 tags, it is required that the outermost tag exists and 869 is an S-VLAN, and the second outermost tag is a 870 C-VLAN"; 871 } 873 presence 874 "Indicates existence of a second outermost VLAN tag."; 876 description 877 "The second outermost VLAN tag for locally sourced 878 traffic"; 880 uses dot1q-types:dot1q-tag-classifier-grouping; 881 } 882 } 883 } 884 } 885 } 886 } 887 889 7. Open Issues 891 Open issues: 893 1. Consider whether to use interface property identities (as per 894 draft-wilton-netmod-interface-properties). 896 2. Provide configuration examples? 898 3. Remove extra 'dot1q-tag' container (required update to IEEE YANG 899 file. 901 8. Acknowledgements 903 The authors would particularly like to thank John Messenger, Glenn 904 Parsons, and Dan Romascanu for their help progressing this draft. 906 The authors would also like to thank Alex Campbell, Eric Gray, Giles 907 Heron, Marc Holness, Iftekhar Hussain, Neil Ketley, William Lupton, 908 John Messenger, Glenn Parsons, Ludwig Pauwels, Joseph White, and 909 members of the IEEE 802.1 WG for their helpful reviews and feedback 910 on this draft. 912 9. ChangeLog 914 9.1. WG version -02 916 o Use explicit containers for outer and inner tags rather than 917 lists. 919 9.2. WG version -01 921 o Tweaked the abstract. 923 o Removed unnecessary feature for the L3 sub-interface module. 925 o Update the 802.1Qcp type references. 927 o Remove extra tag container for L3 sub-interfaces YANG. 929 9.3. Version -04 931 o IEEE 802.1 specific types have been removed from the draft. These 932 are now referenced from the 802.1Qcp draft YANG modules. 934 o Fixed errors in the xpath expressions. 936 9.4. Version -03 938 o Incorporates feedback received from presenting to the IEEE 802.1 939 WG. 941 o Updates the modules for double tag matches/rewrites to restrict 942 the outer tag type to S-VLAN and inner tag type to C-VLAN. 944 o Updates the introduction to indicate primary use case is for IETF 945 forwarding protocols. 947 o Updates the objectives to make IEEE 802.1Q bridge interoperability 948 a key objective. 950 10. IANA Considerations 952 This document defines several new YANG module and the authors 953 politely request that IANA assigns unique names to the YANG module 954 files contained within this draft, and also appropriate URIs in the 955 "IETF XML Registry". 957 11. Security Considerations 959 The YANG module defined in this memo is designed to be accessed via 960 the NETCONF protocol RFC 6241 [RFC6241]. The lowest NETCONF layer is 961 the secure transport layer and the mandatory to implement secure 962 transport is SSH RFC 6242 [RFC6242]. The NETCONF access control 963 model RFC 6536 [RFC6536] provides the means to restrict access for 964 particular NETCONF users to a pre-configured subset of all available 965 NETCONF protocol operations and content. 967 There are a number of data nodes defined in this YANG module which 968 are writable/creatable/deletable (i.e. config true, which is the 969 default). These data nodes may be considered sensitive or vulnerable 970 in some network environments. Write operations (e.g. edit-config) to 971 these data nodes without proper protection can have a negative effect 972 on network operations. These are the subtrees and data nodes and 973 their sensitivity/vulnerability: 975 11.1. if-l3-vlan.yang 977 The nodes in the if-l3-vlan YANG module are concerned with matching 978 particular frames received on the network device to connect them to a 979 layer 3 forwarding instance, and as such adding/modifying/deleting 980 these nodes has a high risk of causing traffic to be lost because it 981 is not being classified correctly, or is being classified to a 982 separate sub-interface. The nodes, all under the subtree 983 /interfaces/interface/encapsulation/dot1q-vlan, that are sensitive to 984 this are: 986 o outer-tag/dot1q-tag/tag-type 988 o outer-tag/dot1q-tag/vlan-id 990 o second-tag/dot1q-tag/tag-type 992 o second-tag/dot1q-tag/vlan-id 994 11.2. flexible-encapsulation.yang 996 There are many nodes in the flexible-encapsulation YANG module that 997 are concerned with matching particular frames received on the network 998 device, and as such adding/modifying/deleting these nodes has a high 999 risk of causing traffic to be lost because it is not being classified 1000 correctly, or is being classified to a separate sub-interface. The 1001 nodes, all under the subtree 1002 /interfaces/interface/encapsulation/flexible/match, that are 1003 sensitive to this are: 1005 o default 1007 o untagged 1009 o dot1q-priority-tagged 1011 o dot1q-priority-tagged/tag-type 1013 o dot1q-vlan-tagged/outer-tag/dot1q-tag/vlan-type 1015 o dot1q-vlan-tagged/outer-tag/dot1q-tag/vlan-id 1017 o dot1q-vlan-tagged/second-tag/dot1q-tag/vlan-type 1019 o dot1q-vlan-tagged/second-tag/dot1q-tag/vlan-id 1021 There are also many modes in the flexible-encapsulation YANG module 1022 that are concerned with rewriting the fields in the L2 header for 1023 particular frames received on the network device, and as such 1024 adding/modifying/deleting these nodes has a high risk of causing 1025 traffic to be dropped or incorrectly processed on peer network 1026 devices, or it could cause layer 2 tunnels to go down due to a 1027 mismatch in negotiated MTU. The nodes, all under the subtree 1028 /interfaces/interface/encapsulation/flexible/rewrite, that are 1029 sensitive to this are: 1031 o symmetrical/dot1q-tag-rewrite/pop-tags 1033 o symmetrical/dot1q-tag-rewrite/push-tags/outer-tag/dot1q-tag/tag- 1034 type 1036 o symmetrical/dot1q-tag-rewrite/push-tags/outer-tag/dot1q-tag/vlan- 1037 id 1039 o symmetrical/dot1q-tag-rewrite/push-tags/second-tag/dot1q-tag/tag- 1040 type 1042 o symmetrical/dot1q-tag-rewrite/push-tags/second-tag/dot1q-tag/vlan- 1043 id 1045 o asymmetrical/ingress/dot1q-tag-rewrite/pop-tags 1047 o asymmetrical/ingress/dot1q-tag-rewrite/push-tags/outer-tag/dot1q- 1048 tag/tag-type 1050 o asymmetrical/ingress/dot1q-tag-rewrite/push-tags/outer-tag/dot1q- 1051 tag/vlan-id 1053 o asymmetrical/ingress/dot1q-tag-rewrite/push-tags/second-tag/dot1q- 1054 tag/tag-type 1056 o asymmetrical/ingress/dot1q-tag-rewrite/push-tags/second-tag/dot1q- 1057 tag/vlan-id 1059 o asymmetrical/egress/dot1q-tag-rewrite/pop-tags 1061 o asymmetrical/egress/dot1q-tag-rewrite/push-tags/outer-tag/dot1q- 1062 tag/tag-type 1064 o asymmetrical/egress/dot1q-tag-rewrite/push-tags/outer-tag/dot1q- 1065 tag/vlan-id 1067 o asymmetrical/egress/dot1q-tag-rewrite/push-tags/second-tag/dot1q- 1068 tag/tag-type 1070 o asymmetrical/egress/dot1q-tag-rewrite/push-tags/second-tag/dot1q- 1071 tag/vlan-id 1073 Nodes in the flexible-encapsulation YANG module that are concerned 1074 with the VLAN tags to use for traffic sourced from the network 1075 element could cause protocol sessions (such as CFM) to fail if they 1076 are added, modified or deleted. The nodes, all under the subtree 1077 /interfaces/interface/flexible-encapsulation/local-traffic-default- 1078 encaps that are sensitive to this are: 1080 o outer-tag/dot1q-tag/vlan-type 1082 o outer-tag/dot1q-tag/vlan-id 1084 o second-tag/dot1q-tag/vlan-type 1086 o second-tag/dot1q-tag/vlan-id 1088 12. References 1090 12.1. Normative References 1092 [I-D.ietf-netmod-intf-ext-yang] 1093 Wilton, R., Ball, D., tsingh@juniper.net, t., and S. 1094 Sivaraj, "Common Interface Extension YANG Data Models", 1095 draft-ietf-netmod-intf-ext-yang-04 (work in progress), 1096 March 2017. 1098 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1099 Requirement Levels", BCP 14, RFC 2119, 1100 DOI 10.17487/RFC2119, March 1997, 1101 . 1103 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 1104 Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, 1105 . 1107 [RFC7224] Bjorklund, M., "IANA Interface Type YANG Module", 1108 RFC 7224, DOI 10.17487/RFC7224, May 2014, 1109 . 1111 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1112 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1113 . 1115 12.2. Informative References 1117 [dot1Qcp] Holness, M., "802.1Qcp Bridges and Bridged Networks - 1118 Amendment: YANG Data Model", 2016. 1120 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1121 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 1122 December 1998, . 1124 [RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, 1125 "Encapsulation Methods for Transport of Ethernet over MPLS 1126 Networks", RFC 4448, DOI 10.17487/RFC4448, April 2006, 1127 . 1129 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private 1130 LAN Service (VPLS) Using BGP for Auto-Discovery and 1131 Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, 1132 . 1134 [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private 1135 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 1136 Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, 1137 . 1139 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1140 and A. Bierman, Ed., "Network Configuration Protocol 1141 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1142 . 1144 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1145 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1146 . 1148 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 1149 Protocol (NETCONF) Access Control Model", RFC 6536, 1150 DOI 10.17487/RFC6536, March 2012, 1151 . 1153 Appendix A. Comparison with the IEEE 802.1Q Configuration Model 1155 In addition to the sub-interface based YANG model proposed here, the 1156 IEEE 802.1Q working group is also developing a YANG model for the 1157 configuration of 802.1Q VLANs. This raises the valid question as to 1158 whether the models overlap and whether it is necessary or beneficial 1159 to have two different models for superficially similar constructs. 1160 This section aims to answer that question by summarizing and 1161 comparing the two models. 1163 A.1. Sub-interface based configuration model overview 1165 The key features of the sub-interface based configuration model can 1166 be summarized as: 1168 o The model is primarily designed to enable layer 2 and layer 3 1169 services on Ethernet interfaces that can be defined in a very 1170 flexible way to meet the varied requirements of service providers. 1172 o Traffic is classified from an Ethernet-like interface to sub- 1173 interfaces based on fields in the layer 2 header. This is often 1174 based on VLAN Ids contained in the frame, but the model is 1175 extensible to other arbitrary fields in the frame header. 1177 o Sub-interfaces are just a type of if:interface and hence support 1178 any feature configuration YANG models that can be applied 1179 generally to interfaces. For example, QoS or ACL models that 1180 reference if:interface can be applied to the sub-interfaces, or 1181 the sub-interface can be used as an Access Circuit in L2VPN or 1182 L3VPN models that reference if:interface. 1184 o In the sub-interface based configuration model, the classification 1185 of traffic arriving on an interface to a given sub-interface, 1186 based on fields in the layer 2 header, is completely independent 1187 of how the traffic is forwarded. The sub-interface can be 1188 referenced (via references to if:interface) by other models that 1189 specify how traffic is forwarded; thus sub-interfaces can support 1190 multiple different forwarding paradigms, including but not limited 1191 to: layer 3 (IPv4/IPv6), layer 2 pseudowires (over MPLS or IP), 1192 VPLS instances, EVPN instance. 1194 o The model is flexible in the scope of the VLAN Identifier space. 1195 I.e. by default VLAN Ids can be scoped locally to a single 1196 Ethernet-like trunk interface, but the scope is determined by the 1197 forwarding paradigm that is used. 1199 A.2. IEEE 802.1Q Bridge Configuration Model Overview 1201 The key features of the IEEE 802.1Q bridge configuration model can be 1202 summarized as: 1204 o Each VLAN bridge component has a set of Ethernet interfaces that 1205 are members of that bridge. Sub-interfaces are not used, nor 1206 required in the 802.1Q bridge model. 1208 o Within a VLAN bridge component, the VLAN tag in the packet is 1209 used, along with the destination MAC address, to determine how to 1210 forward the packet. Other forwarding paradigms are not supported 1211 by the 802.1Q model. 1213 o Classification of traffic to a VLAN bridge component is based only 1214 on the Ethernet interface that it arrived on. 1216 o VLAN Identifiers are scoped to a VLAN bridge component. Often 1217 devices only support a single bridge component and hence VLANs are 1218 scoped globally within the device. 1220 o Feature configuration is specified in the context of the bridge, 1221 or particular VLANs on a bridge. 1223 A.3. Possible Overlap Between the Two Models 1225 Both models can be used for configuring similar basic layer 2 1226 forwarding topologies. The 802.1Q bridge configuration model is 1227 optimised for configuring Virtual LANs that span across enterprises 1228 and data centers. 1230 The sub-interface model can also be used for configuring equivalent 1231 Virtual LAN networks that span across enterprises and data centers, 1232 but often requires more configuration to be able to configure the 1233 equivalent constructs to the 802.1Q bridge model. 1235 The sub-interface model really excels when implementing flexible L2 1236 and L3 services, where those services may be handled on the same 1237 physical interface, and where the VLAN Identifier is being solely 1238 used to identify the customer or service that is being provided 1239 rather than a Virtual LAN. The sub-interface model provides more 1240 flexibility as to how traffic can be classified, how features can be 1241 applied to traffic streams, and how the traffic is to be forwarded. 1243 Conversely, the 802.1Q bridge model can also be use to implement L2 1244 services in some scenarios, but only if the forwarding paradigm being 1245 used to implement the service is the native Ethernet forwarding 1246 specified in 802.1Q - other forwarding paradigms such as pseudowires 1247 or VPLS are not supported. The 802.1Q bridge model does not 1248 implement L3 services at all, although this can be partly mitigated 1249 by using a virtual L3 interface construct that is a separate logical 1250 Ethernet-like interface which is a member of the bridge. 1252 In conclusion, it is valid for both of these models to exist since 1253 they have different deployment scenarios for which they are 1254 optimized. Devices may choose which of the models (or both) to 1255 implement depending on what functionality the device is being 1256 designed for. 1258 Authors' Addresses 1260 Robert Wilton (editor) 1261 Cisco Systems 1263 Email: rwilton@cisco.com 1265 David Ball 1266 Cisco Systems 1268 Email: daviball@cisco.com 1270 Tapraj Singh 1271 Cisco Systems 1273 Email: tapsingh@cisco.com 1274 Selvakumar Sivaraj 1275 Juniper Networks 1277 Email: ssivaraj@juniper.net