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