idnits 2.17.00 (12 Aug 2021) /tmp/idnits23892/draft-ietf-netmod-sub-intf-vlan-model-07.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 191 has weird spacing: '...ag-type dot...' == Line 194 has weird spacing: '...ag-type dot...' == Line 258 has weird spacing: '...ag-type dot...' == Line 262 has weird spacing: '...ag-type dot...' == Line 265 has weird spacing: '...ag-type dot...' == (8 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 13, 2020) is 670 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCXXXX' is mentioned on line 1294, but not defined == Outdated reference: A later version (-10) exists of draft-ietf-netmod-intf-ext-yang-08 -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE802.1Qcp-2018' -- 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: 0 errors (**), 0 flaws (~~), 10 warnings (==), 4 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: Standards Track T. Singh 5 Expires: January 14, 2021 Cisco Systems 6 S. Sivaraj 7 Juniper Networks 8 July 13, 2020 10 Sub-interface VLAN YANG Data Models 11 draft-ietf-netmod-sub-intf-vlan-model-07 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. L2VPN 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. 25 The model differs from an IEEE 802.1Q bridge model in that the 26 configuration is interface/sub-interface based as opposed to being 27 based on membership of an 802.1Q VLAN bridge. 29 The YANG data models in this document conforms to the Network 30 Management Datastore Architecture (NMDA) defined in RFC 8342. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on January 14, 2021. 49 Copyright Notice 51 Copyright (c) 2020 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 2.1. Interoperability with IEEE 802.1Q compliant bridges . . . 4 71 3. Interface VLAN Encapsulation Model . . . . . . . . . . . . . 4 72 4. Interface Flexible Encapsulation Model . . . . . . . . . . . 5 73 5. VLAN Encapsulation YANG Module . . . . . . . . . . . . . . . 7 74 6. Flexible Encapsulation YANG Module . . . . . . . . . . . . . 11 75 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 21 76 7.1. Layer 3 sub-interfaces with IPv6 . . . . . . . . . . . . 22 77 7.2. Layer 2 sub-interfaces with L2VPN . . . . . . . . . . . . 23 78 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 79 9. ChangeLog . . . . . . . . . . . . . . . . . . . . . . . . . . 26 80 9.1. WG version -07 and -06 . . . . . . . . . . . . . . . . . 26 81 9.2. WG version -05 . . . . . . . . . . . . . . . . . . . . . 26 82 9.3. WG version -04 . . . . . . . . . . . . . . . . . . . . . 26 83 9.4. WG version -03 . . . . . . . . . . . . . . . . . . . . . 27 84 9.5. WG version -02 . . . . . . . . . . . . . . . . . . . . . 27 85 9.6. WG version -01 . . . . . . . . . . . . . . . . . . . . . 27 86 9.7. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 27 87 9.8. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 27 88 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 89 10.1. YANG Module Registrations . . . . . . . . . . . . . . . 27 90 11. Security Considerations . . . . . . . . . . . . . . . . . . . 28 91 11.1. ietf-if-vlan-encapsulation.yang . . . . . . . . . . . . 29 92 11.2. ietf-if-flexible-encapsulation.yang . . . . . . . . . . 29 93 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 94 12.1. Normative References . . . . . . . . . . . . . . . . . . 31 95 12.2. Informative References . . . . . . . . . . . . . . . . . 32 96 Appendix A. Comparison with the IEEE 802.1Q Configuration Model 33 97 A.1. Sub-interface based configuration model overview . . . . 33 98 A.2. IEEE 802.1Q Bridge Configuration Model Overview . . . . . 34 99 A.3. Possible Overlap Between the Two Models . . . . . . . . . 34 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 102 1. Introduction 104 This document defines two YANG [RFC7950] modules that augment the 105 encapsulation choice YANG element defined in Interface Extensions 106 YANG [I-D.ietf-netmod-intf-ext-yang] and the generic interfaces data 107 model defined in [RFC8343]. The two modules provide configuration 108 nodes to support classification of Ethernet/VLAN traffic to sub- 109 interfaces, that can have interface based feature and service 110 configuration applied to them. 112 The purpose of these models is to allow IETF defined forwarding 113 protocols, for example, IPv6 [RFC2460], Ethernet Pseudo Wires 114 [RFC4448] and VPLS [RFC4761] [RFC4762], when configured via 115 appropriate YANG data models [RFC8344] [I-D.ietf-bess-l2vpn-yang], to 116 interoperate with VLAN tagged traffic received from an IEEE 802.1Q 117 compliant bridge. 119 In the case of layer 2 Ethernet services, the flexible encapsulation 120 module also supports flexible rewriting of the VLAN tags contained in 121 the frame header. 123 For reference, a comparison between the sub-interface based YANG 124 model documented in this draft and an IEEE 802.1Q bridge model is 125 described in Appendix A. 127 In summary, the YANG modules defined in this internet draft are: 129 ietf-if-vlan-encapsulation.yang - Defines the model for basic 130 classification of VLAN tagged traffic, normally to L3 packet 131 forwarding services 133 ietf-if-flexible-encapsulation.yang - Defines the model for 134 flexible classification of Ethernet/VLAN traffic, normally to L2 135 frame forwarding services 137 1.1. Terminology 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 141 "OPTIONAL" in this document are to be interpreted as described in BCP 142 14 RFC 2119 [RFC2119] RFC 8174 [RFC8174] when, and only when, they 143 appear in all capitals, as shown here. 145 The term 'sub-interface' is defined in section 2.6 of Interface 146 Extensions YANG [I-D.ietf-netmod-intf-ext-yang]. 148 1.2. Tree Diagrams 150 Tree diagrams used in this document follow the notation defined in 151 [RFC8340]. 153 2. Objectives 155 The primary aim of the YANG modules contained in this draft is to 156 provide the core model that is required to implement VLAN transport 157 services on router based devices that is fully compatible with IEEE 158 802.1Q compliant bridges. 160 A secondary aim is for the modules to be structured in such a way 161 that they can be cleanly extended in future. 163 2.1. Interoperability with IEEE 802.1Q compliant bridges 165 The modules defined in this document are designed to fully 166 interoperate with IEEE 802.1Q compliant bridges. In particular, the 167 models are restricted to only matching, adding, or rewriting the 168 802.1Q VLAN tags in frames in ways that are compatible with IEEE 169 802.1Q compliant bridges. 171 3. Interface VLAN Encapsulation Model 173 The Interface VLAN encapsulation model provides appropriate leaves 174 for termination of an 802.1Q VLAN tagged segment to a sub-interface 175 (or interface) based L3 service, such as IP. It allows for 176 termination of traffic with one or two 802.1Q VLAN tags. 178 The L3 service must be configured via a separate YANG data model, 179 e.g., [RFC8344]. A short example of configuring 802.1Q VLAN sub- 180 interfaces with IP using YANG is provided in Section 7.1. 182 The "ietf-if-vlan-encapsulation" YANG module has the following 183 structure: 185 module: ietf-if-vlan-encapsulation 186 augment /if:interfaces/if:interface/if-ext:encapsulation 187 /if-ext:encaps-type: 188 +--:(dot1q-vlan) 189 +--rw dot1q-vlan 190 +--rw outer-tag 191 | +--rw tag-type dot1q-tag-type 192 | +--rw vlan-id vlanid 193 +--rw second-tag! 194 +--rw tag-type dot1q-tag-type 195 +--rw vlan-id vlanid 197 4. Interface Flexible Encapsulation Model 199 The Interface Flexible Encapsulation model is designed to allow for 200 the flexible provisioning of layer 2 services. It provides the 201 capability to classify and demultiplex Ethernet/VLAN frames received 202 on an Ethernet trunk interface to sub-interfaces based on the fields 203 available in the layer 2 headers. Once classified to sub-interfaces, 204 it provides the capability to selectively modify fields within the 205 layer 2 frame header before the frame is handed off to the 206 appropriate forwarding code for further handling. The forwarding 207 instance, e.g., L2VPN, VPLS, etc., is configured using a separate 208 YANG configuration model defined elsewhere, e.g., 209 [I-D.ietf-bess-l2vpn-yang]. 211 The model supports a common core set of layer 2 header matches based 212 on the 802.1Q tag type and VLAN Ids contained within the header up to 213 a tag stack depth of two tags. 215 The model supports flexible rewrites of the layer 2 frame header for 216 data frames as they are processed on the interface. It defines a set 217 of standard tag manipulations that allow for the insertion, removal, 218 or rewrite of one or two 802.1Q VLAN tags. The expectation is that 219 manipulations are generally implemented in a symmetrical fashion, 220 i.e. if a manipulation is performed on ingress traffic on an 221 interface then the reverse manipulation is always performed on egress 222 traffic out of the same interface. However, the model also allows 223 for asymmetrical rewrites, which may be required to implement some 224 forwarding models (such as E-Tree). 226 The model also allows a flexible encapsulation and rewrite to be 227 configured directly on an Ethernet or LAG interface without 228 configuring seperate child sub-interfaces. Ingress frames that do 229 not match the encapsulation are dropped. Egress frames MUST conform 230 to the encapsulation. 232 The final aim for the model design is for it to be cleanly extensible 233 to add in additional match and rewrite criteria of the layer 2 234 header, such as matching on the source or destination MAC address, 235 PCP or DEI fields in the 802.1Q tags, or the EtherType of the frame 236 payload. Rewrites can also be extended to allow for modification of 237 other fields within the layer 2 frame header. 239 A short example of configuring 802.1Q VLAN sub-interfaces with L2VPN 240 using YANG is provided in Section 7.2. 242 The "ietf-if-flexible-encapsulation" YANG module has the following 243 structure: 245 module: ietf-if-flexible-encapsulation 246 augment /if:interfaces/if:interface/if-ext:encapsulation 247 /if-ext:encaps-type: 248 +--:(flexible) 249 +--rw flexible 250 +--rw match 251 | +--rw (match-type) 252 | +--:(default) 253 | | +--rw default? empty 254 | +--:(untagged) 255 | | +--rw untagged? empty 256 | +--:(dot1q-priority-tagged) 257 | | +--rw dot1q-priority-tagged 258 | | +--rw tag-type dot1q-types:dot1q-tag-type 259 | +--:(dot1q-vlan-tagged) 260 | +--rw dot1q-vlan-tagged 261 | +--rw outer-tag 262 | | +--rw tag-type dot1q-tag-type 263 | | +--rw vlan-id union 264 | +--rw second-tag! 265 | | +--rw tag-type dot1q-tag-type 266 | | +--rw vlan-id union 267 | +--rw match-exact-tags? empty 268 +--rw rewrite {flexible-rewrites}? 269 | +--rw (direction)? 270 | +--:(symmetrical) 271 | | +--rw symmetrical 272 | | +--rw dot1q-tag-rewrite {dot1q-tag-rewrites}? 273 | | +--rw pop-tags? uint8 274 | | +--rw push-tags! 275 | | +--rw outer-tag 276 | | | +--rw tag-type dot1q-tag-type 277 | | | +--rw vlan-id vlanid 278 | | +--rw second-tag! 279 | | +--rw tag-type dot1q-tag-type 280 | | +--rw vlan-id vlanid 281 | +--:(asymmetrical) {asymmetric-rewrites}? 282 | +--rw ingress 283 | | +--rw dot1q-tag-rewrite {dot1q-tag-rewrites}? 284 | | +--rw pop-tags? uint8 285 | | +--rw push-tags! 286 | | +--rw outer-tag 287 | | | +--rw tag-type dot1q-tag-type 288 | | | +--rw vlan-id vlanid 289 | | +--rw second-tag! 290 | | +--rw tag-type dot1q-tag-type 291 | | +--rw vlan-id vlanid 292 | +--rw egress 293 | +--rw dot1q-tag-rewrite {dot1q-tag-rewrites}? 294 | +--rw pop-tags? uint8 295 | +--rw push-tags! 296 | +--rw outer-tag 297 | | +--rw tag-type dot1q-tag-type 298 | | +--rw vlan-id vlanid 299 | +--rw second-tag! 300 | +--rw tag-type dot1q-tag-type 301 | +--rw vlan-id vlanid 302 +--rw local-traffic-default-encaps! 303 +--rw outer-tag 304 | +--rw tag-type dot1q-tag-type 305 | +--rw vlan-id vlanid 306 +--rw second-tag! 307 +--rw tag-type dot1q-tag-type 308 +--rw vlan-id vlanid 310 5. VLAN Encapsulation YANG Module 312 This YANG module augments the 'encapsulation' container defined in 313 ietf-if-extensions.yang [I-D.ietf-netmod-intf-ext-yang]. It also 314 contains references to [RFC8343], [RFC7224], and [IEEE802.1Qcp-2018]. 316 file "ietf-if-vlan-encapsulation@2020-07-13.yang" 317 module ietf-if-vlan-encapsulation { 318 yang-version 1.1; 319 namespace "urn:ietf:params:xml:ns:yang:ietf-if-vlan-encapsulation"; 320 prefix if-vlan; 321 import ietf-interfaces { 322 prefix if; 323 reference 324 "RFC 8343: A YANG Data Model For Interface Management"; 325 } 327 import iana-if-type { 328 prefix ianaift; 329 reference 330 "RFC 7224: IANA Interface Type YANG Module"; 331 } 333 import ieee802-dot1q-types { 334 prefix dot1q-types; 335 reference 336 "IEEE Std 802.1Qcp-2018: IEEE Standard for Local and 337 metropolitan area networks -- Bridges and Bridged Networks -- 338 Amendment 30: YANG Data Model"; 339 } 341 import ietf-if-extensions { 342 prefix if-ext; 343 reference 344 "RFC XXXX: Common Interface Extension YANG Data Models"; 345 } 347 organization 348 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 350 contact 351 "WG Web: 352 WG List: 354 Editor: Robert Wilton 355 "; 357 description 358 "This YANG module models configuration to classify IEEE 802.1Q 359 VLAN tagged Ethernet traffic by exactly matching the tag type 360 and VLAN identifier of one or two 802.1Q VLAN tags in the frame. 362 Copyright (c) 2020 IETF Trust and the persons identified as 363 authors of the code. All rights reserved. 365 Redistribution and use in source and binary forms, with or 366 without modification, is permitted pursuant to, and subject to 367 the license terms contained in, the Simplified BSD License set 368 forth in Section 4.c of the IETF Trust's Legal Provisions 369 Relating to IETF Documents 370 (https://trustee.ietf.org/license-info). 372 This version of this YANG module is part of RFC XXXX 373 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 374 for full legal notices. 376 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 377 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 378 'MAY', and 'OPTIONAL' in this document are to be interpreted as 379 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 380 they appear in all capitals, as shown here."; 382 revision 2020-07-13 { 383 description 384 "Latest draft revision"; 385 reference 386 "RFC XXXX: Sub-interface VLAN YANG Data Models"; 387 } 389 augment "/if:interfaces/if:interface/if-ext:encapsulation/" 390 + "if-ext:encaps-type" { 391 when "derived-from-or-self(../if:type, 392 'ianaift:ethernetCsmacd') or 393 derived-from-or-self(../if:type, 394 'ianaift:ieee8023adLag') or 395 derived-from-or-self(../if:type, 'ianaift:l2vlan') or 396 derived-from-or-self(../if:type, 397 'if-ext:ethSubInterface')" { 398 description 399 "Applies only to Ethernet-like interfaces and 400 sub-interfaces."; 401 } 403 description 404 "Augment the generic interface encapsulation with basic 802.1Q 405 VLAN tag classifications"; 407 case dot1q-vlan { 408 container dot1q-vlan { 410 description 411 "Classifies 802.1Q VLAN tagged Ethernet frames to a 412 sub-interface (or interface) by exactly matching the 413 number of tags, tag type(s) and VLAN identifier(s). 415 Only frames matching the classification configured on a 416 sub-interface/interface are processed on that 417 sub-interface/interface. 419 Frames that do not match any sub-interface are processed 420 directly on the parent interface, if it is associated with 421 a forwarding instance, otherwise they are dropped."; 423 container outer-tag { 424 must 'tag-type = "dot1q-types:s-vlan" or ' 425 + 'tag-type = "dot1q-types:c-vlan"' { 427 error-message 428 "Only C-VLAN and S-VLAN tags can be matched."; 430 description 431 "For IEEE 802.1Q interoperability, only C-VLAN and 432 S-VLAN tags are matched."; 433 } 435 description 436 "Specifies the VLAN tag values to match against the 437 outermost (first) 802.1Q VLAN tag in the frame."; 439 uses dot1q-types:dot1q-tag-classifier-grouping; 440 } 442 container second-tag { 443 must '../outer-tag/tag-type = "dot1q-types:s-vlan" and ' 444 + 'tag-type = "dot1q-types:c-vlan"' { 446 error-message 447 "When matching two 802.1Q VLAN tags, the outermost 448 (first) tag in the frame MUST be specified and be of 449 S-VLAN type and the second tag in the frame must be of 450 C-VLAN tag type."; 452 description 453 "For IEEE 802.1Q interoperability, when matching two 454 802.1Q VLAN tags, it is REQUIRED that the outermost 455 tag exists and is an S-VLAN, and the second tag is a 456 C-VLAN."; 457 } 459 presence "Classify frames that have two 802.1Q VLAN tags."; 461 description 462 "Specifies the VLAN tag values to match against the 463 second outermost 802.1Q VLAN tag in the frame."; 465 uses dot1q-types:dot1q-tag-classifier-grouping; 466 } 467 } 468 } 469 } 470 } 471 473 6. Flexible Encapsulation YANG Module 475 This YANG module augments the 'encapsulation' container defined in 476 ietf-if-extensions.yang [I-D.ietf-netmod-intf-ext-yang]. This YANG 477 module also augments the 'interface' list entry defined in [RFC8343]. 478 It also contains references to [RFC7224], and [IEEE802.1Qcp-2018]. 480 file "ietf-if-flexible-encapsulation@2020-07-13.yang" 481 module ietf-if-flexible-encapsulation { 482 yang-version 1.1; 483 namespace 484 "urn:ietf:params:xml:ns:yang:ietf-if-flexible-encapsulation"; 485 prefix if-flex; 487 import ietf-interfaces { 488 prefix if; 489 reference 490 "RFC 8343: A YANG Data Model For Interface Management"; 491 } 493 import iana-if-type { 494 prefix ianaift; 495 reference 496 "RFC 7224: IANA Interface Type YANG Module"; 497 } 499 import ieee802-dot1q-types { 500 prefix dot1q-types; 501 reference 502 "IEEE Std 802.1Qcp-2018: IEEE Standard for Local and 503 metropolitan area networks -- Bridges and Bridged Networks -- 504 Amendment 30: YANG Data Model"; 505 } 507 import ietf-if-extensions { 508 prefix if-ext; 509 reference 510 "RFC XXXX: Common Interface Extension YANG Data Models"; 512 } 514 organization 515 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 517 contact 518 "WG Web: 519 WG List: 521 Editor: Robert Wilton 522 "; 524 description 525 "This YANG module describes interface configuration for flexible 526 classification and rewrites of IEEE 802.1Q VLAN tagged Ethernet 527 traffic. 529 Copyright (c) 2020 IETF Trust and the persons identified as 530 authors of the code. All rights reserved. 532 Redistribution and use in source and binary forms, with or 533 without modification, is permitted pursuant to, and subject to 534 the license terms contained in, the Simplified BSD License set 535 forth in Section 4.c of the IETF Trust's Legal Provisions 536 Relating to IETF Documents 537 (https://trustee.ietf.org/license-info). 539 This version of this YANG module is part of RFC XXXX 540 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 541 for full legal notices. 543 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 544 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 545 'MAY', and 'OPTIONAL' in this document are to be interpreted as 546 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 547 they appear in all capitals, as shown here."; 549 revision 2020-07-13 { 550 description 551 "Latest draft revision"; 552 reference 553 "RFC XXXX: Sub-interface VLAN YANG Data Models"; 554 } 556 feature flexible-rewrites { 557 description 558 "This feature indicates that the network element supports 559 specifying flexible rewrite operations."; 561 } 563 feature asymmetric-rewrites { 564 description 565 "This feature indicates that the network element supports 566 specifying different rewrite operations for the ingress 567 rewrite operation and egress rewrite operation."; 568 } 570 feature dot1q-tag-rewrites { 571 description 572 "This feature indicates that the network element supports the 573 flexible rewrite functionality specifying 802.1Q tag 574 rewrites."; 575 } 577 grouping flexible-match { 578 description 579 "Represents a flexible frame classification: 581 The rules for a flexible match are: 582 1. Match-type: default, untagged, priority tag, or tag 583 stack. 584 2. Each tag in the stack of tags matches: 585 a. tag type (802.1Q or 802.1ad) + 586 b. tag value: 587 i. single tag 588 ii. set of tag ranges/values. 589 iii. 'any' keyword"; 591 choice match-type { 592 mandatory true; 594 description 595 "Provides a choice of how the frames may be 596 matched"; 598 case default { 599 description 600 "Default match"; 602 leaf default { 603 type empty; 605 description 606 "Default match. Matches all traffic not matched to any 607 other peer sub-interface by a more specific 608 encapsulation."; 610 } 611 } 613 case untagged { 614 description 615 "Match untagged Ethernet frames only"; 617 leaf untagged { 618 type empty; 620 description 621 "Untagged match. Matches all untagged traffic."; 622 } 623 } 625 case dot1q-priority-tagged { 626 description 627 "Match 802.1Q priority tagged Ethernet frames only"; 629 container dot1q-priority-tagged { 630 description 631 "802.1Q priority tag match"; 633 leaf tag-type { 634 type dot1q-types:dot1q-tag-type; 635 mandatory true; 637 description 638 "The 802.1Q tag type of matched priority 639 tagged packets"; 640 } 641 } 642 } 644 case dot1q-vlan-tagged { 645 container dot1q-vlan-tagged { 646 description 647 "Matches VLAN tagged frames"; 649 container outer-tag { 650 must 'tag-type = "dot1q-types:s-vlan" or ' 651 + 'tag-type = "dot1q-types:c-vlan"' { 653 error-message 654 "Only C-VLAN and S-VLAN tags can be matched."; 656 description 657 "For IEEE 802.1Q interoperability, only C-VLAN and 658 S-VLAN tags can be matched."; 659 } 661 description 662 "Classifies traffic using the outermost (first) VLAN 663 tag on the frame."; 665 uses "dot1q-types:" 666 + "dot1q-tag-ranges-or-any-classifier-grouping"; 667 } 669 container second-tag { 670 must 671 '../outer-tag/tag-type = "dot1q-types:s-vlan" and ' 672 + 'tag-type = "dot1q-types:c-vlan"' { 674 error-message 675 "When matching two tags, the outermost (first) tag 676 must be specified and of S-VLAN type and the second 677 outermost tag must be of C-VLAN tag type."; 679 description 680 "For IEEE 802.1Q interoperability, when matching two 681 tags, it is required that the outermost (first) tag 682 exists and is an S-VLAN, and the second outermost 683 tag is a C-VLAN."; 684 } 686 presence "Also classify on the second VLAN tag."; 688 description 689 "Classifies traffic using the second outermost VLAN tag 690 on the frame."; 692 uses "dot1q-types:" 693 + "dot1q-tag-ranges-or-any-classifier-grouping"; 694 } 696 leaf match-exact-tags { 697 type empty; 698 description 699 "If set, indicates that all 802.1Q VLAN tags in the 700 Ethernet frame header must be explicitly matched, i.e. 701 the EtherType following the matched tags must not be a 702 802.1Q tag EtherType. If unset then extra 802.1Q VLAN 703 tags are allowed."; 704 } 705 } 707 } 708 } 709 } 711 grouping dot1q-tag-rewrite { 712 description 713 "Flexible rewrite grouping. Can be either be expressed 714 symmetrically, or independently in the ingress and/or egress 715 directions."; 717 leaf pop-tags { 718 type uint8 { 719 range "1..2"; 720 } 722 description 723 "The number of 802.1Q VLAN tags to pop, or translate if used 724 in conjunction with push-tags. 726 Popped tags are the outermost tags on the frame."; 727 } 729 container push-tags { 730 presence "802.1Q tags are pushed or translated"; 732 description 733 "The 802.1Q tags to push on the front of the frame, or 734 translate if configured in conjunction with pop-tags."; 736 container outer-tag { 737 must 'tag-type = "dot1q-types:s-vlan" or ' 738 + 'tag-type = "dot1q-types:c-vlan"' { 740 error-message "Only C-VLAN and S-VLAN tags can be pushed."; 742 description 743 "For IEEE 802.1Q interoperability, only C-VLAN and S-VLAN 744 tags can be pushed."; 745 } 747 description 748 "The outermost (first) VLAN tag to push onto the frame."; 750 uses dot1q-types:dot1q-tag-classifier-grouping; 751 } 753 container second-tag { 754 must '../outer-tag/tag-type = "dot1q-types:s-vlan" and ' 755 + 'tag-type = "dot1q-types:c-vlan"' { 757 error-message 758 "When pushing/rewriting two tags, the outermost tag must 759 be specified and of S-VLAN type and the second outermost 760 tag must be of C-VLAN tag type."; 762 description 763 "For IEEE 802.1Q interoperability, when pushing two tags, 764 it is required that the outermost tag exists and is an 765 S-VLAN, and the second outermost tag is a C-VLAN."; 766 } 768 presence 769 "In addition to the first tag, also push/rewrite a second 770 VLAN tag."; 772 description 773 "The second outermost VLAN tag to push onto the frame."; 775 uses dot1q-types:dot1q-tag-classifier-grouping; 776 } 777 } 778 } 780 grouping flexible-rewrite { 781 description 782 "Grouping for flexible rewrites of fields in the L2 header. 784 Restricted to flexible 802.1Q VLAN tag rewrites, but could be 785 extended to cover rewrites of other fields in the L2 header in 786 future."; 788 container dot1q-tag-rewrite { 789 if-feature "dot1q-tag-rewrites"; 791 description 792 "802.1Q VLAN tag rewrite. 794 Translate operations are expressed as a combination of tag 795 push and pop operations. E.g., translating the outer tag is 796 expressed as popping a single tag, and pushing a single tag. 797 802.1Q tags that are translated SHOULD preserve the PCP and 798 DEI fields unless if a different QoS behavior has been 799 specified."; 800 uses dot1q-tag-rewrite; 801 } 802 } 803 augment "/if:interfaces/if:interface/if-ext:encapsulation/" 804 + "if-ext:encaps-type" { 805 when "derived-from-or-self(../if:type, 806 'ianaift:ethernetCsmacd') or 807 derived-from-or-self(../if:type, 808 'ianaift:ieee8023adLag') or 809 derived-from-or-self(../if:type, 'ianaift:l2vlan') or 810 derived-from-or-self(../if:type, 811 'if-ext:ethSubInterface')" { 813 description 814 "Applies only to Ethernet-like interfaces and 815 sub-interfaces."; 816 } 818 description 819 "Augment the generic interface encapsulation with flexible 820 match and rewrite for VLAN sub-interfaces."; 822 case flexible { 823 description 824 "Flexible encapsulation and rewrite"; 826 container flexible { 827 description 828 "Flexible encapsulation allows for the matching of ranges 829 and sets of 802.1Q VLAN Tags and performing rewrite 830 operations on the VLAN tags. 832 The structure is also designed to be extended to allow for 833 matching/rewriting other fields within the L2 frame header 834 if required."; 836 container match { 837 description 838 "Flexibly classifies Ethernet frames to a sub-interface 839 (or interface) based on the L2 header fields. 841 Only frames matching the classification configured on a 842 sub-interface/interface are processed on that 843 sub-interface/interface. 845 Frames that do not match any sub-interface are processed 846 directly on the parent interface, if it is associated 847 with a forwarding instance, otherwise they are dropped. 849 If a frame could be classified to multiple 850 sub-interfaces then they get classified to the 851 sub-interface with the most specific match. E.g., 852 matching two VLAN tags in the frame is more specific 853 than matching the outermost VLAN tag, which is more 854 specific than the catch all 'default' match."; 856 uses flexible-match; 857 } 859 container rewrite { 860 if-feature "flexible-rewrites"; 862 description 863 "L2 frame rewrite operations. 865 Rewrites allows for modifications to the L2 frame header 866 as it transits the interface/sub-interface. Examples 867 include adding a VLAN tag, removing a VLAN tag, or 868 rewriting the VLAN Id carried in a VLAN tag."; 870 choice direction { 871 description 872 "Whether the rewrite policy is symmetrical or 873 asymmetrical."; 875 case symmetrical { 876 container symmetrical { 877 uses flexible-rewrite; 879 description 880 "Symmetrical rewrite. Expressed in the ingress 881 direction, but the reverse operation is applied to 882 egress traffic. 884 E.g., if a tag is pushed on ingress traffic, then 885 the reverse operation is a 'pop 1', that is 886 performed on traffic egressing the interface, so 887 a peer device sees a consistent L2 encapsulation 888 for both ingress and egress traffic."; 889 } 890 } 892 case asymmetrical { 893 if-feature "asymmetric-rewrites"; 895 description 896 "Asymmetrical rewrite. 898 Rewrite operations may be specified in only a single 899 direction, or different rewrite operations may be 900 specified in each direction."; 902 container ingress { 903 uses flexible-rewrite; 905 description 906 "A rewrite operation that only applies to ingress 907 traffic. 909 Ingress rewrite operations are performed before 910 the frame is subsequently processed by the 911 forwarding operation."; 912 } 914 container egress { 915 uses flexible-rewrite; 917 description 918 "A rewrite operation that only applies to egress 919 traffic."; 920 } 921 } 922 } 923 } 925 container local-traffic-default-encaps { 926 presence "A local traffic default encapsulation has been 927 specified."; 929 description 930 "Specifies the 802.1Q VLAN tags to use by default for 931 locally sourced traffic from the interface. 933 Used for encapsulations that match a range of VLANs (or 934 'any'), where the source VLAN Ids are otherwise 935 ambiguous."; 937 container outer-tag { 938 must 'tag-type = "dot1q-types:s-vlan" or ' 939 + 'tag-type = "dot1q-types:c-vlan"' { 941 error-message 942 "Only C-VLAN and S-VLAN tags can be matched."; 944 description 945 "For IEEE 802.1Q interoperability, only C-VLAN and 946 S-VLAN tags can be matched."; 948 } 950 description 951 "The outermost (first) VLAN tag for locally sourced 952 traffic."; 954 uses dot1q-types:dot1q-tag-classifier-grouping; 955 } 957 container second-tag { 958 must 959 '../outer-tag/tag-type = "dot1q-types:s-vlan" and ' 960 + 'tag-type = "dot1q-types:c-vlan"' { 962 error-message 963 "When specifying two tags, the outermost (first) tag 964 must be specified and of S-VLAN type and the second 965 outermost tag must be of C-VLAN tag type."; 967 description 968 "For IEEE 802.1Q interoperability, when specifying 969 two tags, it is required that the outermost (first) 970 tag exists and is an S-VLAN, and the second 971 outermost tag is a C-VLAN."; 972 } 974 presence 975 "Indicates existence of a second outermost VLAN tag."; 977 description 978 "The second outermost VLAN tag for locally sourced 979 traffic."; 981 uses dot1q-types:dot1q-tag-classifier-grouping; 982 } 983 } 984 } 985 } 986 } 987 } 988 990 7. Examples 992 The following sections give examples of configuring a sub-interface 993 supporting L3 forwarding, and a sub-interface being used in 994 conjunction with the IETF L2VPN YANG model 995 [I-D.ietf-bess-l2vpn-yang]. 997 7.1. Layer 3 sub-interfaces with IPv6 999 This example illustrates two layer sub-interfaces, 'eth0.1' and 1000 'eth0.2', both are child interfaces of the Ethernet interface 'eth0'. 1002 'eth0.1' is configured to match traffic with two VLAN tags: an outer 1003 S-VLAN of 10 and an inner C-VLAN of 20. 1005 'eth0.2' is configured to match traffic with a single S-VLAN tag, 1006 with VLAN Id 11. 1008 1009 1010 1015 1016 eth0 1017 ianaift:ethernetCsmacd 1018 1019 1020 eth0.1 1021 ianaift:l2vlan 1022 eth0 1023 1024 1027 1028 dot1q-types:s-vlan 1029 10 1030 1031 1032 dot1q-types:c-vlan 1033 20 1034 1035 1036 1037 1038 true 1039
1040 2001:db8:10::1 1041 48 1042
1043
1044
1045 1046 eth0.2 1047 ianaift:l2vlan 1048 eth0 1049 1050 1053 1054 dot1q-types:s-vlan 1055 11 1056 1057 1058 1059 1060 true 1061
1062 2001:db8:11::1 1063 48 1064
1065
1066
1067
1068
1070 7.2. Layer 2 sub-interfaces with L2VPN 1072 This example illustrates a layer 2 sub-interface 'eth0.3' configured 1073 to match traffic with a S-VLAN tag of 10, and C-VLAN tag of 21; and 1074 remov the outer tag (S-VLAN 10) before the traffic is passed off to 1075 the L2VPN service. 1077 It also illustrates another sub-interface 'eth1.0' under a separate 1078 physical interface configured to match traffic with a C-VLAN of 50, 1079 with the tag removed before traffic is given to any service. Sub- 1080 interface 'eth1.0' is not currently bound to any service and hence 1081 traffic classifed to that sub-interface is dropped. 1083 1084 1085 1090 1091 eth0 1092 ianaift:ethernetCsmacd 1093 1094 1095 eth0.3 1096 ianaift:l2vlan 1097 eth0 1098 1099 1101 1102 1103 1104 dot1q-types:s-vlan 1105 10 1106 1107 1108 dot1q-types:c-vlan 1109 21 1110 1111 1112 1113 1114 1115 1116 1 1117 1118 1119 1120 1121 1122 1123 1124 eth1 1125 ianaift:ethernetCsmacd 1126 1127 1128 eth1.0 1129 ianaift:l2vlan 1130 eth0 1131 1132 1134 1135 1136 1137 dot1q-types:c-vlan 1138 50 1139 1140 1141 1142 1143 1144 1145 1 1146 1147 1148 1149 1150 1151 1152 1153 1155 1157 p2p-l2-1 1158 Point to point L2 service 1159 l2vpn:vpws-instance-type 1160 1161 l2vpn:ldp-signaling 1162 1163 1164 local 1165 1166 eth0.3 1167 1168 1169 1170 remote 1171 1172 pw1 1173 1174 1175 1176 1177 1178 1179 1181 1182 pw1 1183 1184 2001:db8::50> 1185 100 1186 1187 1188 1189 1191 8. Acknowledgements 1193 The authors would particularly like to thank Benoit Claise, John 1194 Messenger, Glenn Parsons, and Dan Romascanu for their help 1195 progressing this draft. 1197 The authors would also like to thank Martin Bjorklund, Alex Campbell, 1198 Don Fedyk, Eric Gray, Giles Heron, Marc Holness, Iftekhar Hussain, 1199 Neil Ketley, William Lupton, John Messenger, Glenn Parsons, Ludwig 1200 Pauwels, Joseph White, Vladimir Vassilev, and members of the IEEE 1201 802.1 WG for their helpful reviews and feedback on this draft. 1203 9. ChangeLog 1205 XXX, RFC Editor, please delete this change log before publication. 1207 9.1. WG version -07 and -06 1209 o Apply markups from WG last call. 1211 9.2. WG version -05 1213 o Incorporate feedback from IEEE 802.1 WG, John Messenger in 1214 particular. 1216 o Adding must contraints to ensure outer tags are always matched to 1217 C-VLAN and S-VLAN tags. 1219 o Fixed bug where second tag could be matched without outer tag, and 1220 where tags must not be specified. 1222 9.3. WG version -04 1224 o Added examples 1226 9.4. WG version -03 1228 o Fix namespace bug in XPath identity references, removed extraneous 1229 'dot1q-tag' containers. 1231 9.5. WG version -02 1233 o Use explicit containers for outer and inner tags rather than 1234 lists. 1236 9.6. WG version -01 1238 o Tweaked the abstract. 1240 o Removed unnecessary feature for the L3 sub-interface module. 1242 o Update the 802.1Qcp type references. 1244 o Remove extra tag container for L3 sub-interfaces YANG. 1246 9.7. Version -04 1248 o IEEE 802.1 specific types have been removed from the draft. These 1249 are now referenced from the 802.1Qcp draft YANG modules. 1251 o Fixed errors in the xpath expressions. 1253 9.8. Version -03 1255 o Incorporates feedback received from presenting to the IEEE 802.1 1256 WG. 1258 o Updates the modules for double tag matches/rewrites to restrict 1259 the outer tag type to S-VLAN and inner tag type to C-VLAN. 1261 o Updates the introduction to indicate primary use case is for IETF 1262 forwarding protocols. 1264 o Updates the objectives to make IEEE 802.1Q bridge interoperability 1265 a key objective. 1267 10. IANA Considerations 1269 10.1. YANG Module Registrations 1271 The following YANG modules are requested to be registred in the IANA 1272 "YANG Module Names" [RFC6020] registry: 1274 The ietf-if-vlan-encapsulation module: 1276 Name: ietf-if-vlan-encapsulation 1278 XML Namespace: urn:ietf:params:xml:ns:yang:ietf-if-vlan- 1279 encapsulation 1281 Prefix: if-vlan 1283 Reference: [RFCXXXX] 1285 The ietf-if-flexible-encapsulation module: 1287 Name: ietf-if-flexible-encapsulation 1289 XML Namespace: urn:ietf:params:xml:ns:yang:ietf-if-flexible- 1290 encapsulation 1292 Prefix: if-flex 1294 Reference: [RFCXXXX] 1296 This document registers two URIs in the "IETF XML Registry" 1297 [RFC3688]. Following the format in RFC 3688, the following 1298 registrations have been made. 1300 URI: urn:ietf:params:xml:ns:yang:ietf-if-vlan-encapsulation 1302 Registrant Contact: The IESG. 1304 XML: N/A, the requested URI is an XML namespace. 1306 URI: urn:ietf:params:xml:ns:yang:ietf-if-flexible-encapsulation 1308 Registrant Contact: The IESG. 1310 XML: N/A, the requested URI is an XML namespace. 1312 11. Security Considerations 1314 The YANG module defined in this memo is designed to be accessed via 1315 the NETCONF protocol RFC 6241 [RFC6241]. The lowest NETCONF layer is 1316 the secure transport layer and the mandatory to implement secure 1317 transport is SSH RFC 6242 [RFC6242]. The NETCONF access control 1318 model RFC 6536 [RFC6536] provides the means to restrict access for 1319 particular NETCONF users to a pre-configured subset of all available 1320 NETCONF protocol operations and content. 1322 There are a number of data nodes defined in this YANG module which 1323 are writable/creatable/deletable (i.e. config true, which is the 1324 default). These data nodes may be considered sensitive or vulnerable 1325 in some network environments. Write operations (e.g. edit-config) to 1326 these data nodes without proper protection can have a negative effect 1327 on network operations. These are the subtrees and data nodes and 1328 their sensitivity/vulnerability: 1330 11.1. ietf-if-vlan-encapsulation.yang 1332 The nodes in the vlan encapsulation YANG module are concerned with 1333 matching particular frames received on the network device to connect 1334 them to a layer 3 forwarding instance, and as such adding/modifying/ 1335 deleting these nodes has a high risk of causing traffic to be lost 1336 because it is not being classified correctly, or is being classified 1337 to a separate sub-interface. The nodes, all under the subtree 1338 /interfaces/interface/encapsulation/dot1q-vlan, that are sensitive to 1339 this are: 1341 o outer-tag/tag-type 1343 o outer-tag/vlan-id 1345 o second-tag/tag-type 1347 o second-tag/vlan-id 1349 11.2. ietf-if-flexible-encapsulation.yang 1351 There are many nodes in the flexible encapsulation YANG module that 1352 are concerned with matching particular frames received on the network 1353 device, and as such adding/modifying/deleting these nodes has a high 1354 risk of causing traffic to be lost because it is not being classified 1355 correctly, or is being classified to a separate sub-interface. The 1356 nodes, all under the subtree 1357 /interfaces/interface/encapsulation/flexible/match, that are 1358 sensitive to this are: 1360 o default 1362 o untagged 1364 o dot1q-priority-tagged 1366 o dot1q-priority-tagged/tag-type 1368 o dot1q-vlan-tagged/outer-tag/vlan-type 1369 o dot1q-vlan-tagged/outer-tag/vlan-id 1371 o dot1q-vlan-tagged/second-tag/vlan-type 1373 o dot1q-vlan-tagged/second-tag/vlan-id 1375 There are also many modes in the flexible encapsulation YANG module 1376 that are concerned with rewriting the fields in the L2 header for 1377 particular frames received on the network device, and as such 1378 adding/modifying/deleting these nodes has a high risk of causing 1379 traffic to be dropped or incorrectly processed on peer network 1380 devices, or it could cause layer 2 tunnels to go down due to a 1381 mismatch in negotiated MTU. The nodes, all under the subtree 1382 /interfaces/interface/encapsulation/flexible/rewrite, that are 1383 sensitive to this are: 1385 o symmetrical/dot1q-tag-rewrite/pop-tags 1387 o symmetrical/dot1q-tag-rewrite/push-tags/outer-tag/tag-type 1389 o symmetrical/dot1q-tag-rewrite/push-tags/outer-tag/vlan-id 1391 o symmetrical/dot1q-tag-rewrite/push-tags/second-tag/tag-type 1393 o symmetrical/dot1q-tag-rewrite/push-tags/second-tag/vlan-id 1395 o asymmetrical/ingress/dot1q-tag-rewrite/pop-tags 1397 o asymmetrical/ingress/dot1q-tag-rewrite/push-tags/outer-tag/tag- 1398 type 1400 o asymmetrical/ingress/dot1q-tag-rewrite/push-tags/outer-tag/vlan-id 1402 o asymmetrical/ingress/dot1q-tag-rewrite/push-tags/second-tag/tag- 1403 type 1405 o asymmetrical/ingress/dot1q-tag-rewrite/push-tags/second-tag/vlan- 1406 id 1408 o asymmetrical/egress/dot1q-tag-rewrite/pop-tags 1410 o asymmetrical/egress/dot1q-tag-rewrite/push-tags/outer-tag/tag-type 1412 o asymmetrical/egress/dot1q-tag-rewrite/push-tags/outer-tag/vlan-id 1414 o asymmetrical/egress/dot1q-tag-rewrite/push-tags/second-tag/tag- 1415 type 1417 o asymmetrical/egress/dot1q-tag-rewrite/push-tags/second-tag/vlan-id 1419 Nodes in the flexible-encapsulation YANG module that are concerned 1420 with the VLAN tags to use for traffic sourced from the network 1421 element could cause protocol sessions (such as CFM) to fail if they 1422 are added, modified or deleted. The nodes, all under the subtree 1423 /interfaces/interface/flexible-encapsulation/local-traffic-default- 1424 encaps that are sensitive to this are: 1426 o outer-tag/vlan-type 1428 o outer-tag/vlan-id 1430 o second-tag/vlan-type 1432 o second-tag/vlan-id 1434 12. References 1436 12.1. Normative References 1438 [I-D.ietf-netmod-intf-ext-yang] 1439 Wilton, R., Ball, D., tapsingh@cisco.com, t., and S. 1440 Sivaraj, "Common Interface Extension YANG Data Models", 1441 draft-ietf-netmod-intf-ext-yang-08 (work in progress), 1442 November 2019. 1444 [IEEE802.1Qcp-2018] 1445 Holness, M., "IEEE Std 802.1Qcp-2018: IEEE Standard for 1446 Local and metropolitan area networks -- Bridges and 1447 Bridged Networks -- Amendment 30: YANG Data Model", 2018. 1449 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1450 Requirement Levels", BCP 14, RFC 2119, 1451 DOI 10.17487/RFC2119, March 1997, 1452 . 1454 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1455 DOI 10.17487/RFC3688, January 2004, 1456 . 1458 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1459 the Network Configuration Protocol (NETCONF)", RFC 6020, 1460 DOI 10.17487/RFC6020, October 2010, 1461 . 1463 [RFC7224] Bjorklund, M., "IANA Interface Type YANG Module", 1464 RFC 7224, DOI 10.17487/RFC7224, May 2014, 1465 . 1467 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1468 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1469 . 1471 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1472 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1473 May 2017, . 1475 [RFC8343] Bjorklund, M., "A YANG Data Model for Interface 1476 Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, 1477 . 1479 [RFC8344] Bjorklund, M., "A YANG Data Model for IP Management", 1480 RFC 8344, DOI 10.17487/RFC8344, March 2018, 1481 . 1483 12.2. Informative References 1485 [I-D.ietf-bess-l2vpn-yang] 1486 Shah, H., Brissette, P., Chen, I., Hussain, I., Wen, B., 1487 and K. Tiruveedhula, "YANG Data Model for MPLS-based 1488 L2VPN", draft-ietf-bess-l2vpn-yang-10 (work in progress), 1489 July 2019. 1491 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1492 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 1493 December 1998, . 1495 [RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, 1496 "Encapsulation Methods for Transport of Ethernet over MPLS 1497 Networks", RFC 4448, DOI 10.17487/RFC4448, April 2006, 1498 . 1500 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private 1501 LAN Service (VPLS) Using BGP for Auto-Discovery and 1502 Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, 1503 . 1505 [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private 1506 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 1507 Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, 1508 . 1510 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1511 and A. Bierman, Ed., "Network Configuration Protocol 1512 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1513 . 1515 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1516 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1517 . 1519 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 1520 Protocol (NETCONF) Access Control Model", RFC 6536, 1521 DOI 10.17487/RFC6536, March 2012, 1522 . 1524 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1525 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1526 . 1528 Appendix A. Comparison with the IEEE 802.1Q Configuration Model 1530 In addition to the sub-interface based YANG model proposed here, the 1531 IEEE 802.1Q working group has developed a YANG model for the 1532 configuration of 802.1Q VLANs. This raises the valid question as to 1533 whether the models overlap and whether it is necessary or beneficial 1534 to have two different models for superficially similar constructs. 1535 This section aims to answer that question by summarizing and 1536 comparing the two models. 1538 A.1. Sub-interface based configuration model overview 1540 The key features of the sub-interface based configuration model can 1541 be summarized as: 1543 o The model is primarily designed to enable layer 2 and layer 3 1544 services on Ethernet interfaces that can be defined in a very 1545 flexible way to meet the varied requirements of service providers. 1547 o Traffic is classified from an Ethernet-like interface to sub- 1548 interfaces based on fields in the layer 2 header. This is often 1549 based on VLAN Ids contained in the frame, but the model is 1550 extensible to other arbitrary fields in the frame header. 1552 o Sub-interfaces are just a type of if:interface and hence support 1553 any feature configuration YANG models that can be applied 1554 generally to interfaces. For example, QoS or ACL models that 1555 reference if:interface can be applied to the sub-interfaces, or 1556 the sub-interface can be used as an Access Circuit in L2VPN or 1557 L3VPN models that reference if:interface. 1559 o In the sub-interface based configuration model, the classification 1560 of traffic arriving on an interface to a given sub-interface, 1561 based on fields in the layer 2 header, is completely independent 1562 of how the traffic is forwarded. The sub-interface can be 1563 referenced (via references to if:interface) by other models that 1564 specify how traffic is forwarded; thus sub-interfaces can support 1565 multiple different forwarding paradigms, including but not limited 1566 to: layer 3 (IPv4/IPv6), layer 2 pseudowires (over MPLS or IP), 1567 VPLS instances, EVPN instance. 1569 o The model is flexible in the scope of the VLAN Identifier space. 1570 I.e. by default VLAN Ids can be scoped locally to a single 1571 Ethernet-like trunk interface, but the scope is determined by the 1572 forwarding paradigm that is used. 1574 A.2. IEEE 802.1Q Bridge Configuration Model Overview 1576 The key features of the IEEE 802.1Q bridge configuration model can be 1577 summarized as: 1579 o Each VLAN bridge component has a set of Ethernet interfaces that 1580 are members of that bridge. Sub-interfaces are not used, nor 1581 required in the 802.1Q bridge model. 1583 o Within a VLAN bridge component, the VLAN tag in the packet is 1584 used, along with the destination MAC address, to determine how to 1585 forward the packet. Other forwarding paradigms are not supported 1586 by the 802.1Q model. 1588 o Classification of traffic to a VLAN bridge component is based only 1589 on the Ethernet interface that it arrived on. 1591 o VLAN Identifiers are scoped to a VLAN bridge component. Often 1592 devices only support a single bridge component and hence VLANs are 1593 scoped globally within the device. 1595 o Feature configuration is specified in the context of the bridge, 1596 or particular VLANs on a bridge. 1598 A.3. Possible Overlap Between the Two Models 1600 Both models can be used for configuring similar basic layer 2 1601 forwarding topologies. The 802.1Q bridge configuration model is 1602 optimised for configuring Virtual LANs that span across enterprises 1603 and data centers. 1605 The sub-interface model can also be used for configuring equivalent 1606 Virtual LAN networks that span across enterprises and data centers, 1607 but often requires more configuration to be able to configure the 1608 equivalent constructs to the 802.1Q bridge model. 1610 The sub-interface model really excels when implementing flexible L2 1611 and L3 services, where those services may be handled on the same 1612 physical interface, and where the VLAN Identifier is being solely 1613 used to identify the customer or service that is being provided 1614 rather than a Virtual LAN. The sub-interface model provides more 1615 flexibility as to how traffic can be classified, how features can be 1616 applied to traffic streams, and how the traffic is to be forwarded. 1618 Conversely, the 802.1Q bridge model can also be use to implement L2 1619 services in some scenarios, but only if the forwarding paradigm being 1620 used to implement the service is the native Ethernet forwarding 1621 specified in 802.1Q - other forwarding paradigms such as pseudowires 1622 or VPLS are not supported. The 802.1Q bridge model does not 1623 implement L3 services at all, although this can be partly mitigated 1624 by using a virtual L3 interface construct that is a separate logical 1625 Ethernet-like interface which is a member of the bridge. 1627 In conclusion, it is valid for both of these models to exist since 1628 they have different deployment scenarios for which they are 1629 optimized. Devices may choose which of the models (or both) to 1630 implement depending on what functionality the device is being 1631 designed for. 1633 Authors' Addresses 1635 Robert Wilton (editor) 1636 Cisco Systems 1638 Email: rwilton@cisco.com 1640 David Ball 1641 Cisco Systems 1643 Email: daviball@cisco.com 1645 Tapraj Singh 1646 Cisco Systems 1648 Email: tapsingh@cisco.com 1649 Selvakumar Sivaraj 1650 Juniper Networks 1652 Email: ssivaraj@juniper.net