idnits 2.17.1 draft-ietf-netmod-sub-intf-vlan-model-06.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 186 has weird spacing: '...ag-type dot...' == Line 189 has weird spacing: '...ag-type dot...' == Line 240 has weird spacing: '...ag-type dot...' == Line 244 has weird spacing: '...ag-type dot...' == Line 247 has weird spacing: '...ag-type dot...' == (8 more instances...) == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (November 4, 2019) is 1635 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) == Unused Reference: 'RFC7224' is defined on line 1290, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-netmod-intf-ext-yang-07 -- 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 (==), 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: Standards Track T. Singh 5 Expires: May 7, 2020 Cisco Systems 6 S. Sivaraj 7 Juniper Networks 8 November 4, 2019 10 Sub-interface VLAN YANG Data Models 11 draft-ietf-netmod-sub-intf-vlan-model-06 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. 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 May 7, 2020. 49 Copyright Notice 51 Copyright (c) 2019 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. L3 Interface VLAN Model . . . . . . . . . . . . . . . . . . . 4 72 4. Flexible Encapsulation Model . . . . . . . . . . . . . . . . 5 73 5. L3 Interface VLAN YANG Module . . . . . . . . . . . . . . . . 7 74 6. Flexible Encapsulation YANG Module . . . . . . . . . . . . . 10 75 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 19 76 7.1. Layer 3 sub-interfaces with IPv6 . . . . . . . . . . . . 19 77 7.2. Layer 2 sub-interfaces with L2VPN . . . . . . . . . . . . 21 78 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 79 9. ChangeLog . . . . . . . . . . . . . . . . . . . . . . . . . . 23 80 9.1. WG version -05 . . . . . . . . . . . . . . . . . . . . . 24 81 9.2. WG version -04 . . . . . . . . . . . . . . . . . . . . . 24 82 9.3. WG version -03 . . . . . . . . . . . . . . . . . . . . . 24 83 9.4. WG version -02 . . . . . . . . . . . . . . . . . . . . . 24 84 9.5. WG version -01 . . . . . . . . . . . . . . . . . . . . . 24 85 9.6. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 24 86 9.7. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 24 87 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 88 11. Security Considerations . . . . . . . . . . . . . . . . . . . 25 89 11.1. if-l3-vlan.yang . . . . . . . . . . . . . . . . . . . . 25 90 11.2. flexible-encapsulation.yang . . . . . . . . . . . . . . 26 91 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 92 12.1. Normative References . . . . . . . . . . . . . . . . . . 27 93 12.2. Informative References . . . . . . . . . . . . . . . . . 28 94 Appendix A. Comparison with the IEEE 802.1Q Configuration Model 29 95 A.1. Sub-interface based configuration model overview . . . . 29 96 A.2. IEEE 802.1Q Bridge Configuration Model Overview . . . . . 30 97 A.3. Possible Overlap Between the Two Models . . . . . . . . . 31 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 100 1. Introduction 102 This document defines two YANG [RFC7950] modules that augment the 103 encapsulation choice YANG element defined in Interface Extensions 104 YANG [I-D.ietf-netmod-intf-ext-yang] and the generic interfaces data 105 model defined in [RFC8343]. The two modules provide configuration 106 nodes to support classification of Ethernet/VLAN traffic to sub- 107 interfaces, that can have interface based feature and service 108 configuration applied to them. 110 The purpose of these models is to allow IETF defined forwarding 111 protocols, such as IPv6 [RFC2460], Ethernet Pseudo Wires [RFC4448] 112 and VPLS [RFC4761] [RFC4762] to be configurable via YANG when 113 interoperating with VLAN tagged traffic received from an IEEE 802.1Q 114 compliant bridge. 116 In the case of layer 2 Ethernet services, the flexible encapsulation 117 module also supports flexible rewriting of the VLAN tags contained 118 the in frame header. 120 For reference, a comparison between the sub-interface based YANG 121 model documented in this draft and an IEEE 802.1Q bridge model is 122 described in Appendix A. 124 In summary, the YANG modules defined in this internet draft are: 126 if-l3-vlan.yang - Defines the model for basic classification of 127 VLAN tagged traffic to L3 transport services 129 flexible-encapsulation.yang - Defines the model for flexible 130 classification of Ethernet/VLAN traffic to L2 transport services 132 1.1. Terminology 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 136 "OPTIONAL" in this document are to be interpreted as described in BCP 137 14 RFC 2119 [RFC2119] RFC 8174 [RFC8174] when, and only when, they 138 appear in all capitals, as shown here. 140 Sub-interface: A sub-interface is a small augmentation of a regular 141 interface in the standard YANG module for Interface Management that 142 represents a subset of the traffic handled by its parent interface. 143 As such, it supports both configuration and operational data using 144 any other YANG models that augment or reference interfaces in the 145 normal way. It is defined in Interface Extensions YANG 146 [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. L3 Interface VLAN Model 173 The L3 Interface VLAN model provides appropriate leaves for 174 termination of an 802.1Q VLAN tagged segment to a sub-interface based 175 L3 service. It allows for termination of traffic with up to two 176 802.1Q VLAN tags. 178 The "if-l3-vlan" YANG module has the following structure: 180 module: ietf-if-l3-vlan 181 augment /if:interfaces/if:interface/if-ext:encapsulation 182 /if-ext:encaps-type: 183 +--:(dot1q-vlan) 184 +--rw dot1q-vlan 185 +--rw outer-tag 186 | +--rw tag-type dot1q-tag-type 187 | +--rw vlan-id vlanid 188 +--rw second-tag! 189 +--rw tag-type dot1q-tag-type 190 +--rw vlan-id vlanid 192 4. Flexible Encapsulation Model 194 The Flexible Encapsulation model is designed to allow for the 195 flexible provisioning of layer 2 services. It provides the 196 capability to classify Ethernet/VLAN frames received on an Ethernet 197 trunk interface to sub-interfaces based on the fields available in 198 the layer 2 headers. Once classified to sub-interfaces, it provides 199 the capability to selectively modify fields within the layer 2 200 headers before the frame is handed off to the appropriate forwarding 201 code for further handling. 203 The model supports a common core set of layer 2 header matches based 204 on the 802.1Q tag type and VLAN Ids contained within the header up to 205 a tag stack depth of two tags. 207 The model supports flexible rewrites of the layer 2 frame header for 208 data frames as they are processed on the interface. It defines a set 209 of standard tag manipulations that allow for the insertion, removal, 210 or rewrite of one or two 802.1Q VLAN tags. The expectation is that 211 manipulations are generally implemented in a symmetrical fashion, 212 i.e. if a manipulation is performed on ingress traffic on an 213 interface then the reverse manipulation is always performed on egress 214 traffic out of the same interface. However, the model also allows 215 for asymmetrical rewrites, which may be required to implement some 216 forwarding models (such as E-Tree). 218 The final aim for the model design is for it to be cleanly extensible 219 to add in additional match and rewrite criteria of the layer 2 220 header, such as matching on the source or destination MAC address, 221 PCP or DEI fields in the 802.1Q tags, or the EtherType of the frame 222 payload. Rewrites can also be extended to allow for modification of 223 other fields within the layer 2 frame header. 225 The "flexible-encapsulation" YANG module has the following structure: 227 module: ietf-flexible-encapsulation 228 augment /if:interfaces/if:interface/if-ext:encapsulation 229 /if-ext:encaps-type: 230 +--:(flexible) 231 +--rw flexible 232 +--rw match 233 | +--rw (match-type) 234 | +--:(default) 235 | | +--rw default? empty 236 | +--:(untagged) 237 | | +--rw untagged? empty 238 | +--:(dot1q-priority-tagged) 239 | | +--rw dot1q-priority-tagged 240 | | +--rw tag-type dot1q-types:dot1q-tag-type 241 | +--:(dot1q-vlan-tagged) 242 | +--rw dot1q-vlan-tagged 243 | +--rw outer-tag 244 | | +--rw tag-type dot1q-tag-type 245 | | +--rw vlan-id union 246 | +--rw second-tag! 247 | | +--rw tag-type dot1q-tag-type 248 | | +--rw vlan-id union 249 | +--rw match-exact-tags? empty 250 +--rw rewrite {flexible-rewrites}? 251 | +--rw (direction)? 252 | +--:(symmetrical) 253 | | +--rw symmetrical 254 | | +--rw dot1q-tag-rewrite {dot1q-tag-rewrites}? 255 | | +--rw pop-tags? uint8 256 | | +--rw push-tags! 257 | | +--rw outer-tag 258 | | | +--rw tag-type dot1q-tag-type 259 | | | +--rw vlan-id vlanid 260 | | +--rw second-tag! 261 | | +--rw tag-type dot1q-tag-type 262 | | +--rw vlan-id vlanid 263 | +--:(asymmetrical) {asymmetric-rewrites}? 264 | +--rw ingress 265 | | +--rw dot1q-tag-rewrite {dot1q-tag-rewrites}? 266 | | +--rw pop-tags? uint8 267 | | +--rw push-tags! 268 | | +--rw outer-tag 269 | | | +--rw tag-type dot1q-tag-type 270 | | | +--rw vlan-id vlanid 271 | | +--rw second-tag! 272 | | +--rw tag-type dot1q-tag-type 273 | | +--rw vlan-id vlanid 274 | +--rw egress 275 | +--rw dot1q-tag-rewrite {dot1q-tag-rewrites}? 276 | +--rw pop-tags? uint8 277 | +--rw push-tags! 278 | +--rw outer-tag 279 | | +--rw tag-type dot1q-tag-type 280 | | +--rw vlan-id vlanid 281 | +--rw second-tag! 282 | +--rw tag-type dot1q-tag-type 283 | +--rw vlan-id vlanid 284 +--rw local-traffic-default-encaps! 285 +--rw outer-tag 286 | +--rw tag-type dot1q-tag-type 287 | +--rw vlan-id vlanid 288 +--rw second-tag! 289 +--rw tag-type dot1q-tag-type 290 +--rw vlan-id vlanid 292 5. L3 Interface VLAN YANG Module 294 This YANG module augments the encapsultion container defined in 295 Interface Extensions YANG [I-D.ietf-netmod-intf-ext-yang]. 297 file "ietf-if-l3-vlan@2019-11-04.yang" 298 module ietf-if-l3-vlan { 299 yang-version 1.1; 301 namespace "urn:ietf:params:xml:ns:yang:ietf-if-l3-vlan"; 303 prefix if-l3-vlan; 305 import ietf-interfaces { 306 prefix if; 307 } 309 import iana-if-type { 310 prefix ianaift; 311 } 313 import ieee802-dot1q-types { 314 prefix dot1q-types; 315 } 317 import ietf-if-extensions { 318 prefix if-ext; 319 } 321 organization 322 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 324 contact 325 "WG Web: 326 WG List: 328 Editor: Robert Wilton 329 "; 331 description 332 "This YANG module models L3 VLAN sub-interfaces 333 Copyright (c) 2019 IETF Trust and the persons identified as 334 authors of the code. All rights reserved. 336 Redistribution and use in source and binary forms, with or 337 without modification, is permitted pursuant to, and subject to 338 the license terms contained in, the Simplified BSD License set 339 forth in Section 4.c of the IETF Trust's Legal Provisions 340 Relating to IETF Documents 341 (https://trustee.ietf.org/license-info). 343 This version of this YANG module is part of RFC XXXX 344 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 345 for full legal notices."; 347 revision 2019-11-04 { 348 description "Latest draft revision"; 350 reference 351 "Internet-Draft draft-ietf-netmod-sub-intf-vlan-model-06"; 352 } 354 /* 355 * Add support for the 802.1Q VLAN encapsulation syntax on layer 3 356 * terminated VLAN sub-interfaces. 357 */ 358 augment "/if:interfaces/if:interface/if-ext:encapsulation/" + 359 "if-ext:encaps-type" { 360 when 361 "derived-from-or-self(../if:type, 362 'ianaift:ethernetCsmacd') or 363 derived-from-or-self(../if:type, 364 'ianaift:ieee8023adLag') or 365 derived-from-or-self(../if:type, 366 'if-ext:ethSubInterface')" { 367 description 368 "Applies only to Ethernet-like interfaces and 369 sub-interfaces"; 370 } 372 description 373 "Augment the generic interface encapsulation with an 374 basic 802.1Q VLAN encapsulation for sub-interfaces."; 376 /* 377 * Matches a single VLAN Id, or a pair of VLAN Ids to classify 378 * traffic into an L3 service. 379 */ 380 case dot1q-vlan { 381 container dot1q-vlan { 382 must 383 'count(../../if-ext:forwarding-mode) = 0 or ' + 384 'derived-from-or-self(../../if-ext:forwarding-mode,' + 385 '"if-ext:layer-3-forwarding")' { 386 error-message 387 "If the interface forwarding-mode leaf is set then it 388 must be set to an identity that derives from 389 layer-3-forwarding"; 391 description 392 "The forwarding-mode leaf on an interface can 393 optionally be used to enforce consistency of 394 configuration"; 395 } 397 description 398 "Match VLAN tagged frames with specific VLAN Ids"; 399 container outer-tag { 400 must 401 'tag-type = "dot1q-types:s-vlan" or ' + 402 'tag-type = "dot1q-types:c-vlan"' { 404 error-message 405 "Only C-VLAN and S-VLAN tags can be matched"; 407 description 408 "For IEEE 802.1Q interoperability, only C-VLAN and 409 S-VLAN tags can be matched"; 410 } 412 description 413 "Classifies traffic using the outermost VLAN tag on the 414 frame."; 416 uses dot1q-types:dot1q-tag-classifier-grouping; 417 } 419 container second-tag { 420 must 421 '../outer-tag/tag-type = "dot1q-types:s-vlan" and ' + 422 'tag-type = "dot1q-types:c-vlan"' { 424 error-message 425 "When matching two tags, the outermost tag must be 426 specified and of S-VLAN type and the second outermost 427 tag must be of C-VLAN tag type"; 429 description 430 "For IEEE 802.1Q interoperability, when matching two 431 tags, it is required that the outermost tag exists and 432 is an S-VLAN, and the second outermost tag is a 433 C-VLAN"; 434 } 436 presence "Also classify on the second outermost VLAN tag"; 438 description 439 "Classifies traffic using the second outermost VLAN tag 440 on the frame."; 442 uses dot1q-types:dot1q-tag-classifier-grouping; 443 } 444 } 445 } 446 } 447 } 448 450 6. Flexible Encapsulation YANG Module 452 This YANG module augments the encapsultion container defined in 453 Interface Extensions YANG [I-D.ietf-netmod-intf-ext-yang]. 455 This YANG module also augments the interface container defined in 456 [RFC8343]. 458 file "ietf-flexible-encapsulation@2019-11-04.yang" 459 module ietf-flexible-encapsulation { 460 yang-version 1.1; 461 namespace 462 "urn:ietf:params:xml:ns:yang:ietf-flexible-encapsulation"; 464 prefix flex; 466 import ietf-interfaces { 467 prefix if; 468 } 470 import iana-if-type { 471 prefix ianaift; 472 } 474 import ietf-if-extensions { 475 prefix if-ext; 476 } 478 import ieee802-dot1q-types { 479 prefix dot1q-types; 480 } 482 organization 483 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 485 contact 486 "WG Web: 487 WG List: 489 Editor: Robert Wilton 490 "; 492 description 493 "This YANG module describes interface configuration for flexible 494 VLAN matches and rewrites. 496 Copyright (c) 2019 IETF Trust and the persons identified as 497 authors of the code. All rights reserved. 499 Redistribution and use in source and binary forms, with or 500 without modification, is permitted pursuant to, and subject to 501 the license terms contained in, the Simplified BSD License set 502 forth in Section 4.c of the IETF Trust's Legal Provisions 503 Relating to IETF Documents 504 (https://trustee.ietf.org/license-info). 506 This version of this YANG module is part of RFC XXXX 507 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 508 for full legal notices."; 510 revision 2019-11-04 { 511 description "Latest draft revision"; 513 reference 514 "Internet-Draft draft-ietf-netmod-sub-intf-vlan-model-06"; 515 } 517 feature flexible-rewrites { 518 description 519 "This feature indicates whether the network element supports 520 specifying flexible rewrite operations"; 521 } 522 feature asymmetric-rewrites { 523 description 524 "This feature indicates whether the network element supports 525 specifying different rewrite operations for the ingress 526 rewrite operation and egress rewrite operation."; 527 } 529 feature dot1q-tag-rewrites { 530 description 531 "This feature indicates whether the network element supports 532 the flexible rewrite functionality specifying flexible 802.1Q 533 tag rewrites"; 534 } 536 /* 537 * flexible-match grouping. 538 * 539 * This grouping represents a flexible match. 540 * 541 * The rules for a flexible match are: 542 * 1. default, untagged, priority tag, or a stack of tags. 543 * - Each tag in the stack of tags matches: 544 * 1. tag type (802.1Q or 802.1ad) + 545 * 2. tag value: 546 * i. single tag 547 * ii. set of tag ranges/values. 548 * iii. "any" keyword 549 */ 550 grouping flexible-match { 551 description "Flexible match"; 552 choice match-type { 553 mandatory true; 554 description "Provides a choice of how the frames may be 555 matched"; 557 case default { 558 description "Default match"; 559 leaf default { 560 type empty; 561 description 562 "Default match. Matches all traffic not matched to any 563 other peer sub-interface by a more specific 564 encapsulation."; 565 } // leaf default 566 } // case default 568 case untagged { 569 description "Match untagged Ethernet frames only"; 570 leaf untagged { 571 type empty; 572 description 573 "Untagged match. Matches all untagged traffic."; 574 } // leaf untagged 575 } // case untagged 577 case dot1q-priority-tagged { 578 description 579 "Match 802.1Q priority tagged Ethernet frames only"; 581 container dot1q-priority-tagged { 582 description "802.1Q priority tag match"; 583 leaf tag-type { 584 type dot1q-types:dot1q-tag-type; 585 mandatory true; 586 description "The 802.1Q tag type of matched priority 587 tagged packets"; 588 } 589 } 590 } 592 case dot1q-vlan-tagged { 593 container dot1q-vlan-tagged { 594 description "Matches VLAN tagged frames"; 596 container outer-tag { 597 must 598 'tag-type = "dot1q-types:s-vlan" or ' + 599 'tag-type = "dot1q-types:c-vlan"' { 601 error-message 602 "Only C-VLAN and S-VLAN tags can be matched"; 604 description 605 "For IEEE 802.1Q interoperability, only C-VLAN and 606 S-VLAN tags can be matched"; 607 } 609 description 610 "Classifies traffic using the outermost VLAN tag on the 611 frame."; 613 uses 614 'dot1q-types:'+ 615 'dot1q-tag-ranges-or-any-classifier-grouping'; 616 } 617 container second-tag { 618 must 619 '../outer-tag/tag-type = "dot1q-types:s-vlan" and ' + 620 'tag-type = "dot1q-types:c-vlan"' { 622 error-message 623 "When matching two tags, the outermost tag must be 624 specified and of S-VLAN type and the second 625 outermost tag must be of C-VLAN tag type"; 627 description 628 "For IEEE 802.1Q interoperability, when matching two 629 tags, it is required that the outermost tag exists 630 and is an S-VLAN, and the second outermost tag is a 631 C-VLAN"; 632 } 634 presence "Also classify on the second VLAN tag"; 636 description 637 "Classifies traffic using the second outermost VLAN tag 638 on the frame."; 640 uses 641 'dot1q-types:'+ 642 'dot1q-tag-ranges-or-any-classifier-grouping'; 643 } 645 leaf match-exact-tags { 646 type empty; 647 description 648 "If set, indicates that all 802.1Q VLAN tags in the 649 Ethernet frame header must be explicitly matched, i.e. 650 the EtherType following the matched tags must not be a 651 802.1Q tag EtherType. If unset then extra 802.1Q VLAN 652 tags are allowed."; 653 } 654 } 655 } 656 } // encaps-type 657 } 659 /* 660 * Grouping for tag-rewrite that can be expressed either 661 * symmetrically, or in the ingress and/or egress directions 662 * independently. 663 */ 664 grouping dot1q-tag-rewrite { 665 description "Flexible rewrite"; 666 leaf pop-tags { 667 type uint8 { 668 range 1..2; 669 } 670 description "The number of tags to pop (or translate if used in 671 conjunction with push-tags)"; 672 } 674 container push-tags { 675 presence 676 "802.1Q tags are pushed or translated"; 677 description "The 802.1Q tags to push (or translate if used in 678 conjunction with pop-tags)"; 680 container outer-tag { 681 must 682 'tag-type = "dot1q-types:s-vlan" or ' + 683 'tag-type = "dot1q-types:c-vlan"' { 685 error-message 686 "Only C-VLAN and S-VLAN tags can be pushed"; 688 description 689 "For IEEE 802.1Q interoperability, only C-VLAN and S-VLAN 690 tags can be pushed"; 691 } 693 description 694 "The outermost VLAN tag to push onto the frame."; 695 uses dot1q-types:dot1q-tag-classifier-grouping; 696 } 698 container second-tag { 699 must 700 '../outer-tag/tag-type = "dot1q-types:s-vlan" and ' + 701 'tag-type = "dot1q-types:c-vlan"' { 703 error-message 704 "When pushing/rewriting two tags, the outermost tag must 705 be specified and of S-VLAN type and the second outermost 706 tag must be of C-VLAN tag type"; 708 description 709 "For IEEE 802.1Q interoperability, when pushing two tags, 710 it is required that the outermost tag exists and is an 711 S-VLAN, and the second outermost tag is a C-VLAN"; 712 } 713 presence 714 "In addition to the first tag, also push/rewrite a second 715 VLAN tag."; 717 description 718 "The second outermost VLAN tag to push onto the frame."; 720 uses dot1q-types:dot1q-tag-classifier-grouping; 721 } 722 } 723 } 725 /* 726 * Grouping for all flexible rewrites of fields in the L2 header. 727 * 728 * This currently only includes flexible tag rewrites, but is 729 * designed to be extensible to cover rewrites of other fields in 730 * the L2 header if required. 731 */ 732 grouping flexible-rewrite { 733 description "Flexible rewrite"; 735 /* 736 * Tag rewrite. 737 * 738 * All tag rewrites are formed using a combination of pop-tags 739 * and push-tags operations. 740 */ 741 container dot1q-tag-rewrite { 742 if-feature dot1q-tag-rewrites; 743 description "Tag rewrite. Translate operations are expressed 744 as a combination of tag push and pop operations."; 745 uses dot1q-tag-rewrite; 746 } 747 } 748 augment "/if:interfaces/if:interface/if-ext:encapsulation/" + 749 "if-ext:encaps-type" { 750 when 751 "derived-from-or-self(../if:type, 752 'ianaift:ethernetCsmacd') or 753 derived-from-or-self(../if:type, 754 'ianaift:ieee8023adLag') or 755 derived-from-or-self(../if:type, 756 'if-ext:ethSubInterface')" { 757 description 758 "Applies only to Ethernet-like interfaces and 759 sub-interfaces"; 760 } 761 description 762 "Add flexible match and rewrite for VLAN sub-interfaces"; 764 /* 765 * A flexible encapsulation allows for the matching of ranges and 766 * sets of VLAN Ids. The structure is also designed to be 767 * extended to allow for matching/rewriting other fields within 768 * the L2 frame header if required. 769 */ 770 case flexible { 771 description "Flexible encapsulation and rewrite"; 772 container flexible { 773 description "Flexible encapsulation and rewrite"; 775 container match { 776 description 777 "The match used to classify frames to this interface"; 778 uses flexible-match; 779 } 781 container rewrite { 782 if-feature flexible-rewrites; 783 description "L2 frame rewrite operations"; 784 choice direction { 785 description 786 "Whether the rewrite policy is symmetrical or 787 asymmetrical"; 788 case symmetrical { 789 container symmetrical { 790 uses flexible-rewrite; 791 description 792 "Symmetrical rewrite. Expressed in the ingress 793 direction, but the reverse operation is applied to 794 egress traffic"; 795 } 796 } 798 /* 799 * Allow asymmetrical rewrites to be specified. 800 */ 801 case asymmetrical { 802 if-feature asymmetric-rewrites; 803 description "Asymmetrical rewrite"; 804 container ingress { 805 uses flexible-rewrite; 806 description "Ingress rewrite"; 807 } 808 container egress { 809 uses flexible-rewrite; 810 description "Egress rewrite"; 811 } 812 } 813 } 814 } 816 /* 817 * For encapsulations that match a range of VLANs (or Any), 818 * allow configuration to specify the default 802.1Q VLAN tag 819 * values to use for any traffic that is locally sourced from 820 * an interface on the device. 821 */ 822 container local-traffic-default-encaps { 823 presence 824 "A local traffic default encapsulation has been 825 specified"; 826 description 827 "The 802.1Q VLAN tags to use by default for locally 828 sourced traffic"; 830 container outer-tag { 831 must 832 'tag-type = "dot1q-types:s-vlan" or ' + 833 'tag-type = "dot1q-types:c-vlan"' { 835 error-message 836 "Only C-VLAN and S-VLAN tags can be matched"; 838 description 839 "For IEEE 802.1Q interoperability, only C-VLAN and 840 S-VLAN tags can be matched"; 841 } 843 description 844 "The outermost VLAN tag for locally sourced traffic"; 846 uses dot1q-types:dot1q-tag-classifier-grouping; 847 } 849 container second-tag { 850 must 851 '../outer-tag/tag-type = "dot1q-types:s-vlan" and ' + 852 'tag-type = "dot1q-types:c-vlan"' { 854 error-message 855 "When specifying two tags, the outermost tag must be 856 specified and of S-VLAN type and the second outermost 857 tag must be of C-VLAN tag type"; 859 description 860 "For IEEE 802.1Q interoperability, when specifying two 861 tags, it is required that the outermost tag exists and 862 is an S-VLAN, and the second outermost tag is a 863 C-VLAN"; 864 } 866 presence 867 "Indicates existence of a second outermost VLAN tag."; 869 description 870 "The second outermost VLAN tag for locally sourced 871 traffic"; 873 uses dot1q-types:dot1q-tag-classifier-grouping; 874 } 875 } 876 } 877 } 878 } 879 } 880 882 7. Examples 884 The following sections give examples of configuring a sub-interface 885 supporting L3 forwarding, and also a sub-interface being used in 886 conjunction with the IETF L2VPN YANG model 887 [I-D.ietf-bess-l2vpn-yang]. 889 7.1. Layer 3 sub-interfaces with IPv6 891 This example illustrates a layer 3 sub-interface configured to match 892 traffic with a S-VLAN tag of 10, and C-VLAN tag of 20. 894 895 896 901 902 eth0 903 ianaift:ethernetCsmacd 904 905 906 eth0.1 907 ianaift:l2vlan 908 eth0 909 910 912 913 dot1q-types:s-vlan 914 10 915 916 917 dot1q-types:c-vlan 918 20 919 920 921 922 923 true 924
925 2001:db8::10 926 32 927
928 929 930 931 eth0.2 932 ianaift:l2vlan 933 eth0 934 935 937 938 dot1q-types:s-vlan 939 11 940 941 942 943 944 true 945
946 2001:db8::11 947 32 948
949 950 952 953 955 7.2. Layer 2 sub-interfaces with L2VPN 957 This example illustrates a layer 2 sub-interface 'eth0.3' configured 958 to match traffic with a S-VLAN tag of 10, and C-VLAN tag of 21; and 959 both tags removed before the traffic is passed off to the L2VPN 960 service. 962 It also illustrates another sub-interface 'eth1.0' under a separate 963 physical interface configured to match traffic with a C-VLAN of 50, 964 and the tag removed before traffic is given to any service. Sub- 965 interface 'eth1.0' is not currently bound to any service and hence 966 traffic classifed to that sub-interface is dropped. 968 969 970 975 976 eth0 977 ianaift:ethernetCsmacd 978 979 980 eth0.3 981 ianaift:l2vlan 982 eth0 983 984 986 987 988 989 dot1q-types:s-vlan 990 10 991 992 993 dot1q-types:c-vlan 994 21 995 996 997 998 999 1000 1001 2 1002 1003 1004 1005 1006 1007 1008 1009 eth1 1010 ianaift:ethernetCsmacd 1011 1012 1013 eth1.0 1014 ianaift:l2vlan 1015 eth0 1016 1017 1019 1020 1021 1022 dot1q-types:c-vlan 1023 50 1024 1025 1026 1027 1028 1029 1030 1 1031 1032 1033 1034 1035 1036 1037 1038 1040 1042 p2p-l2-1 1043 Point to point L2 service 1044 l2vpn:vpws-instance-type 1045 1046 l2vpn:ldp-signaling 1047 1048 1049 local 1050 1051 eth0.3 1052 1053 1054 1055 remote 1056 1057 pw1 1058 1059 1060 1061 1062 1063 1064 1066 1067 pw1 1068 1069 2001:db8::50> 1070 100 1071 1072 1073 1074 1076 8. Acknowledgements 1078 The authors would particularly like to thank John Messenger, Glenn 1079 Parsons, and Dan Romascanu for their help progressing this draft. 1081 The authors would also like to thank Alex Campbell, Eric Gray, Giles 1082 Heron, Marc Holness, Iftekhar Hussain, Neil Ketley, William Lupton, 1083 John Messenger, Glenn Parsons, Ludwig Pauwels, Joseph White, Vladimir 1084 Vassilev, and members of the IEEE 802.1 WG for their helpful reviews 1085 and feedback on this draft. 1087 9. ChangeLog 1089 XXX, RFC Editor, please delete this change log before publication. 1091 9.1. WG version -05 1093 o Incorporate feedback from IEEE 802.1 WG, John Messenger in 1094 particular. 1096 o Adding must contraints to ensure outer tags are always matched to 1097 C-VLAN and S-VLAN tags. 1099 o Fixed bug where second tag could be matched without outer tag, and 1100 where tags must not be specified. 1102 9.2. WG version -04 1104 o Added examples 1106 9.3. WG version -03 1108 o Fix namespace bug in XPath identity references, removed extraneous 1109 'dot1q-tag' containers. 1111 9.4. WG version -02 1113 o Use explicit containers for outer and inner tags rather than 1114 lists. 1116 9.5. WG version -01 1118 o Tweaked the abstract. 1120 o Removed unnecessary feature for the L3 sub-interface module. 1122 o Update the 802.1Qcp type references. 1124 o Remove extra tag container for L3 sub-interfaces YANG. 1126 9.6. Version -04 1128 o IEEE 802.1 specific types have been removed from the draft. These 1129 are now referenced from the 802.1Qcp draft YANG modules. 1131 o Fixed errors in the xpath expressions. 1133 9.7. Version -03 1135 o Incorporates feedback received from presenting to the IEEE 802.1 1136 WG. 1138 o Updates the modules for double tag matches/rewrites to restrict 1139 the outer tag type to S-VLAN and inner tag type to C-VLAN. 1141 o Updates the introduction to indicate primary use case is for IETF 1142 forwarding protocols. 1144 o Updates the objectives to make IEEE 802.1Q bridge interoperability 1145 a key objective. 1147 10. IANA Considerations 1149 This document defines two new YANG module and the authors politely 1150 request that IANA assigns unique names to the YANG module files 1151 contained within this draft, and also appropriate URIs in the "IETF 1152 XML Registry". 1154 11. Security Considerations 1156 The YANG module defined in this memo is designed to be accessed via 1157 the NETCONF protocol RFC 6241 [RFC6241]. The lowest NETCONF layer is 1158 the secure transport layer and the mandatory to implement secure 1159 transport is SSH RFC 6242 [RFC6242]. The NETCONF access control 1160 model RFC 6536 [RFC6536] provides the means to restrict access for 1161 particular NETCONF users to a pre-configured subset of all available 1162 NETCONF protocol operations and content. 1164 There are a number of data nodes defined in this YANG module which 1165 are writable/creatable/deletable (i.e. config true, which is the 1166 default). These data nodes may be considered sensitive or vulnerable 1167 in some network environments. Write operations (e.g. edit-config) to 1168 these data nodes without proper protection can have a negative effect 1169 on network operations. These are the subtrees and data nodes and 1170 their sensitivity/vulnerability: 1172 11.1. if-l3-vlan.yang 1174 The nodes in the if-l3-vlan YANG module are concerned with matching 1175 particular frames received on the network device to connect them to a 1176 layer 3 forwarding instance, and as such adding/modifying/deleting 1177 these nodes has a high risk of causing traffic to be lost because it 1178 is not being classified correctly, or is being classified to a 1179 separate sub-interface. The nodes, all under the subtree 1180 /interfaces/interface/encapsulation/dot1q-vlan, that are sensitive to 1181 this are: 1183 o outer-tag/tag-type 1185 o outer-tag/vlan-id 1186 o second-tag/tag-type 1188 o second-tag/vlan-id 1190 11.2. flexible-encapsulation.yang 1192 There are many nodes in the flexible-encapsulation YANG module that 1193 are concerned with matching particular frames received on the network 1194 device, and as such adding/modifying/deleting these nodes has a high 1195 risk of causing traffic to be lost because it is not being classified 1196 correctly, or is being classified to a separate sub-interface. The 1197 nodes, all under the subtree 1198 /interfaces/interface/encapsulation/flexible/match, that are 1199 sensitive to this are: 1201 o default 1203 o untagged 1205 o dot1q-priority-tagged 1207 o dot1q-priority-tagged/tag-type 1209 o dot1q-vlan-tagged/outer-tag/vlan-type 1211 o dot1q-vlan-tagged/outer-tag/vlan-id 1213 o dot1q-vlan-tagged/second-tag/vlan-type 1215 o dot1q-vlan-tagged/second-tag/vlan-id 1217 There are also many modes in the flexible-encapsulation YANG module 1218 that are concerned with rewriting the fields in the L2 header for 1219 particular frames received on the network device, and as such 1220 adding/modifying/deleting these nodes has a high risk of causing 1221 traffic to be dropped or incorrectly processed on peer network 1222 devices, or it could cause layer 2 tunnels to go down due to a 1223 mismatch in negotiated MTU. The nodes, all under the subtree 1224 /interfaces/interface/encapsulation/flexible/rewrite, that are 1225 sensitive to this are: 1227 o symmetrical/dot1q-tag-rewrite/pop-tags 1229 o symmetrical/dot1q-tag-rewrite/push-tags/outer-tag/tag-type 1231 o symmetrical/dot1q-tag-rewrite/push-tags/outer-tag/vlan-id 1233 o symmetrical/dot1q-tag-rewrite/push-tags/second-tag/tag-type 1234 o symmetrical/dot1q-tag-rewrite/push-tags/second-tag/vlan-id 1236 o asymmetrical/ingress/dot1q-tag-rewrite/pop-tags 1238 o asymmetrical/ingress/dot1q-tag-rewrite/push-tags/outer-tag/tag- 1239 type 1241 o asymmetrical/ingress/dot1q-tag-rewrite/push-tags/outer-tag/vlan-id 1243 o asymmetrical/ingress/dot1q-tag-rewrite/push-tags/second-tag/tag- 1244 type 1246 o asymmetrical/ingress/dot1q-tag-rewrite/push-tags/second-tag/vlan- 1247 id 1249 o asymmetrical/egress/dot1q-tag-rewrite/pop-tags 1251 o asymmetrical/egress/dot1q-tag-rewrite/push-tags/outer-tag/tag-type 1253 o asymmetrical/egress/dot1q-tag-rewrite/push-tags/outer-tag/vlan-id 1255 o asymmetrical/egress/dot1q-tag-rewrite/push-tags/second-tag/tag- 1256 type 1258 o asymmetrical/egress/dot1q-tag-rewrite/push-tags/second-tag/vlan-id 1260 Nodes in the flexible-encapsulation YANG module that are concerned 1261 with the VLAN tags to use for traffic sourced from the network 1262 element could cause protocol sessions (such as CFM) to fail if they 1263 are added, modified or deleted. The nodes, all under the subtree 1264 /interfaces/interface/flexible-encapsulation/local-traffic-default- 1265 encaps that are sensitive to this are: 1267 o outer-tag/vlan-type 1269 o outer-tag/vlan-id 1271 o second-tag/vlan-type 1273 o second-tag/vlan-id 1275 12. References 1277 12.1. Normative References 1279 [I-D.ietf-netmod-intf-ext-yang] 1280 Wilton, R., Ball, D., tsingh@juniper.net, t., and S. 1281 Sivaraj, "Common Interface Extension YANG Data Models", 1282 draft-ietf-netmod-intf-ext-yang-07 (work in progress), 1283 March 2019. 1285 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1286 Requirement Levels", BCP 14, RFC 2119, 1287 DOI 10.17487/RFC2119, March 1997, 1288 . 1290 [RFC7224] Bjorklund, M., "IANA Interface Type YANG Module", 1291 RFC 7224, DOI 10.17487/RFC7224, May 2014, 1292 . 1294 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1295 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1296 . 1298 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1299 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1300 May 2017, . 1302 [RFC8343] Bjorklund, M., "A YANG Data Model for Interface 1303 Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, 1304 . 1306 12.2. Informative References 1308 [dot1Qcp] Holness, M., "IEEE 802.1Qcp-2018 Bridges and Bridged 1309 Networks - Amendment: YANG Data Model", 2018. 1311 [I-D.ietf-bess-l2vpn-yang] 1312 Shah, H., Brissette, P., Chen, I., Hussain, I., Wen, B., 1313 and K. Tiruveedhula, "YANG Data Model for MPLS-based 1314 L2VPN", draft-ietf-bess-l2vpn-yang-10 (work in progress), 1315 July 2019. 1317 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1318 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 1319 December 1998, . 1321 [RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, 1322 "Encapsulation Methods for Transport of Ethernet over MPLS 1323 Networks", RFC 4448, DOI 10.17487/RFC4448, April 2006, 1324 . 1326 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private 1327 LAN Service (VPLS) Using BGP for Auto-Discovery and 1328 Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, 1329 . 1331 [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private 1332 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 1333 Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, 1334 . 1336 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1337 and A. Bierman, Ed., "Network Configuration Protocol 1338 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1339 . 1341 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1342 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1343 . 1345 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 1346 Protocol (NETCONF) Access Control Model", RFC 6536, 1347 DOI 10.17487/RFC6536, March 2012, 1348 . 1350 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1351 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1352 . 1354 Appendix A. Comparison with the IEEE 802.1Q Configuration Model 1356 In addition to the sub-interface based YANG model proposed here, the 1357 IEEE 802.1Q working group has developed a YANG model for the 1358 configuration of 802.1Q VLANs. This raises the valid question as to 1359 whether the models overlap and whether it is necessary or beneficial 1360 to have two different models for superficially similar constructs. 1361 This section aims to answer that question by summarizing and 1362 comparing the two models. 1364 A.1. Sub-interface based configuration model overview 1366 The key features of the sub-interface based configuration model can 1367 be summarized as: 1369 o The model is primarily designed to enable layer 2 and layer 3 1370 services on Ethernet interfaces that can be defined in a very 1371 flexible way to meet the varied requirements of service providers. 1373 o Traffic is classified from an Ethernet-like interface to sub- 1374 interfaces based on fields in the layer 2 header. This is often 1375 based on VLAN Ids contained in the frame, but the model is 1376 extensible to other arbitrary fields in the frame header. 1378 o Sub-interfaces are just a type of if:interface and hence support 1379 any feature configuration YANG models that can be applied 1380 generally to interfaces. For example, QoS or ACL models that 1381 reference if:interface can be applied to the sub-interfaces, or 1382 the sub-interface can be used as an Access Circuit in L2VPN or 1383 L3VPN models that reference if:interface. 1385 o In the sub-interface based configuration model, the classification 1386 of traffic arriving on an interface to a given sub-interface, 1387 based on fields in the layer 2 header, is completely independent 1388 of how the traffic is forwarded. The sub-interface can be 1389 referenced (via references to if:interface) by other models that 1390 specify how traffic is forwarded; thus sub-interfaces can support 1391 multiple different forwarding paradigms, including but not limited 1392 to: layer 3 (IPv4/IPv6), layer 2 pseudowires (over MPLS or IP), 1393 VPLS instances, EVPN instance. 1395 o The model is flexible in the scope of the VLAN Identifier space. 1396 I.e. by default VLAN Ids can be scoped locally to a single 1397 Ethernet-like trunk interface, but the scope is determined by the 1398 forwarding paradigm that is used. 1400 A.2. IEEE 802.1Q Bridge Configuration Model Overview 1402 The key features of the IEEE 802.1Q bridge configuration model can be 1403 summarized as: 1405 o Each VLAN bridge component has a set of Ethernet interfaces that 1406 are members of that bridge. Sub-interfaces are not used, nor 1407 required in the 802.1Q bridge model. 1409 o Within a VLAN bridge component, the VLAN tag in the packet is 1410 used, along with the destination MAC address, to determine how to 1411 forward the packet. Other forwarding paradigms are not supported 1412 by the 802.1Q model. 1414 o Classification of traffic to a VLAN bridge component is based only 1415 on the Ethernet interface that it arrived on. 1417 o VLAN Identifiers are scoped to a VLAN bridge component. Often 1418 devices only support a single bridge component and hence VLANs are 1419 scoped globally within the device. 1421 o Feature configuration is specified in the context of the bridge, 1422 or particular VLANs on a bridge. 1424 A.3. Possible Overlap Between the Two Models 1426 Both models can be used for configuring similar basic layer 2 1427 forwarding topologies. The 802.1Q bridge configuration model is 1428 optimised for configuring Virtual LANs that span across enterprises 1429 and data centers. 1431 The sub-interface model can also be used for configuring equivalent 1432 Virtual LAN networks that span across enterprises and data centers, 1433 but often requires more configuration to be able to configure the 1434 equivalent constructs to the 802.1Q bridge model. 1436 The sub-interface model really excels when implementing flexible L2 1437 and L3 services, where those services may be handled on the same 1438 physical interface, and where the VLAN Identifier is being solely 1439 used to identify the customer or service that is being provided 1440 rather than a Virtual LAN. The sub-interface model provides more 1441 flexibility as to how traffic can be classified, how features can be 1442 applied to traffic streams, and how the traffic is to be forwarded. 1444 Conversely, the 802.1Q bridge model can also be use to implement L2 1445 services in some scenarios, but only if the forwarding paradigm being 1446 used to implement the service is the native Ethernet forwarding 1447 specified in 802.1Q - other forwarding paradigms such as pseudowires 1448 or VPLS are not supported. The 802.1Q bridge model does not 1449 implement L3 services at all, although this can be partly mitigated 1450 by using a virtual L3 interface construct that is a separate logical 1451 Ethernet-like interface which is a member of the bridge. 1453 In conclusion, it is valid for both of these models to exist since 1454 they have different deployment scenarios for which they are 1455 optimized. Devices may choose which of the models (or both) to 1456 implement depending on what functionality the device is being 1457 designed for. 1459 Authors' Addresses 1461 Robert Wilton (editor) 1462 Cisco Systems 1464 Email: rwilton@cisco.com 1465 David Ball 1466 Cisco Systems 1468 Email: daviball@cisco.com 1470 Tapraj Singh 1471 Cisco Systems 1473 Email: tapsingh@cisco.com 1475 Selvakumar Sivaraj 1476 Juniper Networks 1478 Email: ssivaraj@juniper.net