idnits 2.17.1 draft-ietf-netmod-sub-intf-vlan-model-05.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 (March 6, 2019) is 1849 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 1304, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-netmod-intf-ext-yang-07 == Outdated reference: A later version (-10) exists of draft-ietf-bess-l2vpn-yang-09 -- 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 (~~), 11 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: September 7, 2019 Cisco Systems 6 S. Sivaraj 7 Juniper Networks 8 March 6, 2019 10 Sub-interface VLAN YANG Data Models 11 draft-ietf-netmod-sub-intf-vlan-model-05 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 September 7, 2019. 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 24 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 . . . . . . . . . . . . . . . . . . . . . . . 25 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 . . . . . . . . . . . . . . . . . . . . . . . . . 28 92 12.1. Normative References . . . . . . . . . . . . . . . . . . 28 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-cmn:encapsulation/ 182 if-cmn: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-cmn:encapsulation/ 229 if-cmn: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-03-05.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-interfaces-common { 318 prefix if-cmn; 319 } 321 organization 322 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 324 contact 325 "WG Web: 326 WG List: 328 WG Chair: Lou Berger 329 331 WG Chair: Joel Jaeggli 332 334 WG Chair: Kent Watsen 335 337 Editor: Robert Wilton 338 "; 340 description 341 "This YANG module models L3 VLAN sub-interfaces"; 343 revision 2019-03-05 { 344 description "Latest draft revision"; 346 reference 347 "Internet-Draft draft-ietf-netmod-sub-intf-vlan-model-05"; 348 } 350 /* 351 * Add support for the 802.1Q VLAN encapsulation syntax on layer 3 352 * terminated VLAN sub-interfaces. 353 */ 354 augment "/if:interfaces/if:interface/if-cmn:encapsulation/" + 355 "if-cmn:encaps-type" { 356 when 357 "derived-from-or-self(../if:type, 358 'ianaift:ethernetCsmacd') or 359 derived-from-or-self(../if:type, 360 'ianaift:ieee8023adLag') or 361 derived-from-or-self(../if:type, 362 'if-cmn:ethSubInterface')" { 363 description 364 "Applies only to Ethernet-like interfaces and 365 sub-interfaces"; 366 } 368 description 369 "Augment the generic interface encapsulation with an 370 basic 802.1Q VLAN encapsulation for sub-interfaces."; 372 /* 373 * Matches a single VLAN Id, or a pair of VLAN Ids to classify 374 * traffic into an L3 service. 375 */ 376 case dot1q-vlan { 377 container dot1q-vlan { 378 must 379 'count(../../if-cmn:forwarding-mode) = 0 or ' + 380 'derived-from-or-self(../../if-cmn:forwarding-mode,' + 381 '"if-cmn:layer-3-forwarding")' { 383 error-message 384 "If the interface forwarding-mode leaf is set then it 385 must be set to an identity that derives from 386 layer-3-forwarding"; 388 description 389 "The forwarding-mode leaf on an interface can 390 optionally be used to enforce consistency of 391 configuration"; 392 } 394 description 395 "Match VLAN tagged frames with specific VLAN Ids"; 396 container outer-tag { 397 must 398 'tag-type = "dot1q-types:s-vlan" or ' + 399 'tag-type = "dot1q-types:c-vlan"' { 401 error-message 402 "Only C-VLAN and S-VLAN tags can be matched"; 404 description 405 "For IEEE 802.1Q interoperability, only C-VLAN and 406 S-VLAN tags can be matched"; 407 } 409 description 410 "Classifies traffic using the outermost VLAN tag on the 411 frame."; 413 uses dot1q-types:dot1q-tag-classifier-grouping; 414 } 416 container second-tag { 417 must 418 '../outer-tag/tag-type = "dot1q-types:s-vlan" and ' + 419 'tag-type = "dot1q-types:c-vlan"' { 421 error-message 422 "When matching two tags, the outermost tag must be 423 specified and of S-VLAN type and the second outermost 424 tag must be of C-VLAN tag type"; 426 description 427 "For IEEE 802.1Q interoperability, when matching two 428 tags, it is required that the outermost tag exists and 429 is an S-VLAN, and the second outermost tag is a 430 C-VLAN"; 431 } 433 presence "Also classify on the second outermost VLAN tag"; 435 description 436 "Classifies traffic using the second outermost VLAN tag 437 on the frame."; 439 uses dot1q-types:dot1q-tag-classifier-grouping; 440 } 441 } 442 } 443 } 444 } 445 447 6. Flexible Encapsulation YANG Module 449 This YANG module augments the encapsultion container defined in 450 Interface Extensions YANG [I-D.ietf-netmod-intf-ext-yang]. 452 This YANG module also augments the interface container defined in 453 [RFC8343]. 455 file "ietf-flexible-encapsulation@2019-03-05.yang" 456 module ietf-flexible-encapsulation { 457 yang-version 1.1; 458 namespace 459 "urn:ietf:params:xml:ns:yang:ietf-flexible-encapsulation"; 461 prefix flex; 463 import ietf-interfaces { 464 prefix if; 465 } 467 import iana-if-type { 468 prefix ianaift; 469 } 471 import ietf-interfaces-common { 472 prefix if-cmn; 473 } 475 import ieee802-dot1q-types { 476 prefix dot1q-types; 477 } 479 organization 480 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 482 contact 483 "WG Web: 484 WG List: 486 WG Chair: Lou Berger 487 489 WG Chair: Joel Jaeggli 490 492 WG Chair: Kent Watsen 493 495 Editor: Robert Wilton 496 "; 498 description 499 "This YANG module describes interface configuration for flexible 500 VLAN matches and rewrites."; 502 revision 2019-03-05 { 503 description "Latest draft revision"; 505 reference 506 "Internet-Draft draft-ietf-netmod-sub-intf-vlan-model-05"; 507 } 509 feature flexible-rewrites { 510 description 511 "This feature indicates whether the network element supports 512 specifying flexible rewrite operations"; 513 } 515 feature asymmetric-rewrites { 516 description 517 "This feature indicates whether the network element supports 518 specifying different rewrite operations for the ingress 519 rewrite operation and egress rewrite operation."; 520 } 522 feature dot1q-tag-rewrites { 523 description 524 "This feature indicates whether the network element supports 525 the flexible rewrite functionality specifying flexible 802.1Q 526 tag rewrites"; 527 } 529 /* 530 * flexible-match grouping. 531 * 532 * This grouping represents a flexible match. 533 * 534 * The rules for a flexible match are: 535 * 1. default, untagged, priority tag, or a stack of tags. 536 * - Each tag in the stack of tags matches: 537 * 1. tag type (802.1Q or 802.1ad) + 538 * 2. tag value: 539 * i. single tag 540 * ii. set of tag ranges/values. 541 * iii. "any" keyword 542 */ 543 grouping flexible-match { 544 description "Flexible match"; 545 choice match-type { 546 mandatory true; 547 description "Provides a choice of how the frames may be 548 matched"; 550 case default { 551 description "Default match"; 552 leaf default { 553 type empty; 554 description 555 "Default match. Matches all traffic not matched to any 556 other peer sub-interface by a more specific 557 encapsulation."; 558 } // leaf default 559 } // case default 561 case untagged { 562 description "Match untagged Ethernet frames only"; 563 leaf untagged { 564 type empty; 565 description 566 "Untagged match. Matches all untagged traffic."; 567 } // leaf untagged 568 } // case untagged 570 case dot1q-priority-tagged { 571 description 572 "Match 802.1Q priority tagged Ethernet frames only"; 574 container dot1q-priority-tagged { 575 description "802.1Q priority tag match"; 576 leaf tag-type { 577 type dot1q-types:dot1q-tag-type; 578 mandatory true; 579 description "The 802.1Q tag type of matched priority 580 tagged packets"; 581 } 582 } 583 } 585 case dot1q-vlan-tagged { 586 container dot1q-vlan-tagged { 587 description "Matches VLAN tagged frames"; 589 container outer-tag { 590 must 591 'tag-type = "dot1q-types:s-vlan" or ' + 592 'tag-type = "dot1q-types:c-vlan"' { 594 error-message 595 "Only C-VLAN and S-VLAN tags can be matched"; 597 description 598 "For IEEE 802.1Q interoperability, only C-VLAN and 599 S-VLAN tags can be matched"; 600 } 602 description 603 "Classifies traffic using the outermost VLAN tag on the 604 frame."; 606 uses 607 'dot1q-types:'+ 608 'dot1q-tag-ranges-or-any-classifier-grouping'; 609 } 611 container second-tag { 612 must 613 '../outer-tag/tag-type = "dot1q-types:s-vlan" and ' + 614 'tag-type = "dot1q-types:c-vlan"' { 616 error-message 617 "When matching two tags, the outermost tag must be 618 specified and of S-VLAN type and the second 619 outermost tag must be of C-VLAN tag type"; 621 description 622 "For IEEE 802.1Q interoperability, when matching two 623 tags, it is required that the outermost tag exists 624 and is an S-VLAN, and the second outermost tag is a 625 C-VLAN"; 626 } 628 presence "Also classify on the second VLAN tag"; 630 description 631 "Classifies traffic using the second outermost VLAN tag 632 on the frame."; 634 uses 635 'dot1q-types:'+ 636 'dot1q-tag-ranges-or-any-classifier-grouping'; 637 } 639 leaf match-exact-tags { 640 type empty; 641 description 642 "If set, indicates that all 802.1Q VLAN tags in the 643 Ethernet frame header must be explicitly matched, i.e. 644 the EtherType following the matched tags must not be a 645 802.1Q tag EtherType. If unset then extra 802.1Q VLAN 646 tags are allowed."; 647 } 648 } 649 } 650 } // encaps-type 651 } 653 /* 654 * Grouping for tag-rewrite that can be expressed either 655 * symmetrically, or in the ingress and/or egress directions 656 * independently. 657 */ 658 grouping dot1q-tag-rewrite { 659 description "Flexible rewrite"; 660 leaf pop-tags { 661 type uint8 { 662 range 1..2; 663 } 664 description "The number of tags to pop (or translate if used in 665 conjunction with push-tags)"; 666 } 668 container push-tags { 669 presence 670 "802.1Q tags are pushed or translated"; 671 description "The 802.1Q tags to push (or translate if used in 672 conjunction with pop-tags)"; 674 container outer-tag { 675 must 676 'tag-type = "dot1q-types:s-vlan" or ' + 677 'tag-type = "dot1q-types:c-vlan"' { 679 error-message 680 "Only C-VLAN and S-VLAN tags can be pushed"; 682 description 683 "For IEEE 802.1Q interoperability, only C-VLAN and S-VLAN 684 tags can be pushed"; 685 } 687 description 688 "The outermost VLAN tag to push onto the frame."; 689 uses dot1q-types:dot1q-tag-classifier-grouping; 690 } 692 container second-tag { 693 must 694 '../outer-tag/tag-type = "dot1q-types:s-vlan" and ' + 695 'tag-type = "dot1q-types:c-vlan"' { 697 error-message 698 "When pushing/rewriting two tags, the outermost tag must 699 be specified and of S-VLAN type and the second outermost 700 tag must be of C-VLAN tag type"; 702 description 703 "For IEEE 802.1Q interoperability, when pushing two tags, 704 it is required that the outermost tag exists and is an 705 S-VLAN, and the second outermost tag is a C-VLAN"; 706 } 708 presence 709 "In addition to the first tag, also push/rewrite a second 710 VLAN tag."; 712 description 713 "The second outermost VLAN tag to push onto the frame."; 715 uses dot1q-types:dot1q-tag-classifier-grouping; 716 } 718 } 719 } 721 /* 722 * Grouping for all flexible rewrites of fields in the L2 header. 723 * 724 * This currently only includes flexible tag rewrites, but is 725 * designed to be extensible to cover rewrites of other fields in 726 * the L2 header if required. 727 */ 728 grouping flexible-rewrite { 729 description "Flexible rewrite"; 731 /* 732 * Tag rewrite. 733 * 734 * All tag rewrites are formed using a combination of pop-tags 735 * and push-tags operations. 736 */ 737 container dot1q-tag-rewrite { 738 if-feature dot1q-tag-rewrites; 739 description "Tag rewrite. Translate operations are expressed 740 as a combination of tag push and pop operations."; 741 uses dot1q-tag-rewrite; 742 } 743 } 744 augment "/if:interfaces/if:interface/if-cmn:encapsulation/" + 745 "if-cmn:encaps-type" { 746 when 747 "derived-from-or-self(../if:type, 748 'ianaift:ethernetCsmacd') or 749 derived-from-or-self(../if:type, 750 'ianaift:ieee8023adLag') or 751 derived-from-or-self(../if:type, 752 'if-cmn:ethSubInterface')" { 753 description 754 "Applies only to Ethernet-like interfaces and 755 sub-interfaces"; 756 } 757 description 758 "Add flexible match and rewrite for VLAN sub-interfaces"; 760 /* 761 * A flexible encapsulation allows for the matching of ranges and 762 * sets of VLAN Ids. The structure is also designed to be 763 * extended to allow for matching/rewriting other fields within 764 * the L2 frame header if required. 765 */ 767 case flexible { 768 description "Flexible encapsulation and rewrite"; 769 container flexible { 770 must 771 'count(../../if-cmn:forwarding-mode) = 0 or ' + 772 'derived-from-or-self(../../if-cmn:forwarding-mode,' + 773 '"if-cmn:layer-2-forwarding")' { 774 error-message 775 "If the interface forwarding-mode leaf is set then it 776 must be set to an identity that derives from 777 layer-2-forwarding"; 779 description 780 "The forwarding-mode leaf on an interface can 781 optionally be used to enforce consistency of 782 configuration"; 783 } 785 description "Flexible encapsulation and rewrite"; 787 container match { 788 description 789 "The match used to classify frames to this interface"; 790 uses flexible-match; 791 } 793 container rewrite { 794 if-feature flexible-rewrites; 795 description "L2 frame rewrite operations"; 796 choice direction { 797 description 798 "Whether the rewrite policy is symmetrical or 799 asymmetrical"; 800 case symmetrical { 801 container symmetrical { 802 uses flexible-rewrite; 803 description 804 "Symmetrical rewrite. Expressed in the ingress 805 direction, but the reverse operation is applied to 806 egress traffic"; 807 } 808 } 810 /* 811 * Allow asymmetrical rewrites to be specified. 812 */ 813 case asymmetrical { 814 if-feature asymmetric-rewrites; 815 description "Asymmetrical rewrite"; 816 container ingress { 817 uses flexible-rewrite; 818 description "Ingress rewrite"; 819 } 820 container egress { 821 uses flexible-rewrite; 822 description "Egress rewrite"; 823 } 824 } 825 } 826 } 828 /* 829 * For encapsulations that match a range of VLANs (or Any), 830 * allow configuration to specify the default 802.1Q VLAN tag 831 * values to use for any traffic that is locally sourced from 832 * an interface on the device. 833 */ 834 container local-traffic-default-encaps { 835 presence 836 "A local traffic default encapsulation has been 837 specified"; 838 description 839 "The 802.1Q VLAN tags to use by default for locally 840 sourced traffic"; 842 container outer-tag { 843 must 844 'tag-type = "dot1q-types:s-vlan" or ' + 845 'tag-type = "dot1q-types:c-vlan"' { 847 error-message 848 "Only C-VLAN and S-VLAN tags can be matched"; 850 description 851 "For IEEE 802.1Q interoperability, only C-VLAN and 852 S-VLAN tags can be matched"; 853 } 855 description 856 "The outermost VLAN tag for locally sourced traffic"; 858 uses dot1q-types:dot1q-tag-classifier-grouping; 859 } 861 container second-tag { 862 must 863 '../outer-tag/tag-type = "dot1q-types:s-vlan" and ' + 864 'tag-type = "dot1q-types:c-vlan"' { 866 error-message 867 "When specifying two tags, the outermost tag must be 868 specified and of S-VLAN type and the second outermost 869 tag must be of C-VLAN tag type"; 871 description 872 "For IEEE 802.1Q interoperability, when specifying two 873 tags, it is required that the outermost tag exists and 874 is an S-VLAN, and the second outermost tag is a 875 C-VLAN"; 876 } 878 presence 879 "Indicates existence of a second outermost VLAN tag."; 881 description 882 "The second outermost VLAN tag for locally sourced 883 traffic"; 885 uses dot1q-types:dot1q-tag-classifier-grouping; 886 } 887 } 888 } 889 } 890 } 891 } 892 894 7. Examples 896 The following sections give examples of configuring a sub-interface 897 supporting L3 forwarding, and also a sub-interface being used in 898 conjunction with the IETF L2VPN YANG model 899 [I-D.ietf-bess-l2vpn-yang]. 901 7.1. Layer 3 sub-interfaces with IPv6 903 This example illustrates a layer 3 sub-interface configured to match 904 traffic with a S-VLAN tag of 10, and C-VLAN tag of 20. 906 907 908 913 914 eth0 915 ianaift:ethernetCsmacd 916 917 918 eth0.1 919 ianaift:l2vlan 920 eth0 921 922 924 925 dot1q-types:s-vlan 926 10 927 928 929 dot1q-types:c-vlan 930 20 931 932 933 934 935 true 936
937 2001:db8::10 938 32 939
940
941
942 943 eth0.2 944 ianaift:l2vlan 945 eth0 946 947 949 950 dot1q-types:s-vlan 951 11 952 953 954 955 956 true 957
958 2001:db8::11 959 32 960
961
962
963
964
966 7.2. Layer 2 sub-interfaces with L2VPN 968 This example illustrates a layer 2 sub-interface 'eth0.3' configured 969 to match traffic with a S-VLAN tag of 10, and C-VLAN tag of 21; and 970 both tags removed before the traffic is passed off to the L2VPN 971 service. 973 It also illustrates another sub-interface 'eth1.0' under a separate 974 physical interface configured to match traffic with a C-VLAN of 50, 975 and the tag removed before traffic is given to any service. Sub- 976 interface 'eth1.0' is not currently bound to any service and hence 977 traffic classifed to that sub-interface is dropped. 979 980 981 986 987 eth0 988 ianaift:ethernetCsmacd 989 990 991 eth0.3 992 ianaift:l2vlan 993 eth0 994 995 997 998 999 1000 dot1q-types:s-vlan 1001 10 1002 1003 1004 dot1q-types:c-vlan 1005 21 1006 1007 1008 1009 1010 1011 1012 2 1013 1014 1015 1016 1017 1018 1019 1020 eth1 1021 ianaift:ethernetCsmacd 1022 1023 1024 eth1.0 1025 ianaift:l2vlan 1026 eth0 1027 1028 1030 1031 1032 1033 dot1q-types:c-vlan 1034 50 1035 1036 1037 1038 1039 1040 1041 1 1042 1043 1044 1045 1046 1047 1048 1049 1052 1054 p2p-l2-1 1055 Point to point L2 service 1056 l2vpn:vpws-instance-type 1057 1058 l2vpn:ldp-signaling 1059 1060 1061 local 1062 1063 eth0.3 1064 1065 1066 1067 remote 1068 1069 pw1 1070 1071 1072 1073 1074 1075 1076 1078 1079 pw1 1080 1081 2001:db8::50> 1082 100 1083 1084 1085 1086 1088 8. Acknowledgements 1090 The authors would particularly like to thank John Messenger, Glenn 1091 Parsons, and Dan Romascanu for their help progressing this draft. 1093 The authors would also like to thank Alex Campbell, Eric Gray, Giles 1094 Heron, Marc Holness, Iftekhar Hussain, Neil Ketley, William Lupton, 1095 John Messenger, Glenn Parsons, Ludwig Pauwels, Joseph White, Vladimir 1096 Vassilev, and members of the IEEE 802.1 WG for their helpful reviews 1097 and feedback on this draft. 1099 9. ChangeLog 1101 XXX, RFC Editor, please delete this change log before publication. 1103 9.1. WG version -05 1105 o Incorporate feedback from IEEE 802.1 WG, John Messenger in 1106 particular. 1108 o Adding must contraints to ensure outer tags are always matched to 1109 C-VLAN and S-VLAN tags. 1111 o Fixed bug where second tag could be matched without outer tag, and 1112 where tags must not be specified. 1114 9.2. WG version -04 1116 o Added examples 1118 9.3. WG version -03 1120 o Fix namespace bug in XPath identity references, removed extraneous 1121 'dot1q-tag' containers. 1123 9.4. WG version -02 1125 o Use explicit containers for outer and inner tags rather than 1126 lists. 1128 9.5. WG version -01 1130 o Tweaked the abstract. 1132 o Removed unnecessary feature for the L3 sub-interface module. 1134 o Update the 802.1Qcp type references. 1136 o Remove extra tag container for L3 sub-interfaces YANG. 1138 9.6. Version -04 1140 o IEEE 802.1 specific types have been removed from the draft. These 1141 are now referenced from the 802.1Qcp draft YANG modules. 1143 o Fixed errors in the xpath expressions. 1145 9.7. Version -03 1147 o Incorporates feedback received from presenting to the IEEE 802.1 1148 WG. 1150 o Updates the modules for double tag matches/rewrites to restrict 1151 the outer tag type to S-VLAN and inner tag type to C-VLAN. 1153 o Updates the introduction to indicate primary use case is for IETF 1154 forwarding protocols. 1156 o Updates the objectives to make IEEE 802.1Q bridge interoperability 1157 a key objective. 1159 10. IANA Considerations 1161 This document defines two new YANG module and the authors politely 1162 request that IANA assigns unique names to the YANG module files 1163 contained within this draft, and also appropriate URIs in the "IETF 1164 XML Registry". 1166 11. Security Considerations 1168 The YANG module defined in this memo is designed to be accessed via 1169 the NETCONF protocol RFC 6241 [RFC6241]. The lowest NETCONF layer is 1170 the secure transport layer and the mandatory to implement secure 1171 transport is SSH RFC 6242 [RFC6242]. The NETCONF access control 1172 model RFC 6536 [RFC6536] provides the means to restrict access for 1173 particular NETCONF users to a pre-configured subset of all available 1174 NETCONF protocol operations and content. 1176 There are a number of data nodes defined in this YANG module which 1177 are writable/creatable/deletable (i.e. config true, which is the 1178 default). These data nodes may be considered sensitive or vulnerable 1179 in some network environments. Write operations (e.g. edit-config) to 1180 these data nodes without proper protection can have a negative effect 1181 on network operations. These are the subtrees and data nodes and 1182 their sensitivity/vulnerability: 1184 11.1. if-l3-vlan.yang 1186 The nodes in the if-l3-vlan YANG module are concerned with matching 1187 particular frames received on the network device to connect them to a 1188 layer 3 forwarding instance, and as such adding/modifying/deleting 1189 these nodes has a high risk of causing traffic to be lost because it 1190 is not being classified correctly, or is being classified to a 1191 separate sub-interface. The nodes, all under the subtree 1192 /interfaces/interface/encapsulation/dot1q-vlan, that are sensitive to 1193 this are: 1195 o outer-tag/tag-type 1197 o outer-tag/vlan-id 1199 o second-tag/tag-type 1201 o second-tag/vlan-id 1203 11.2. flexible-encapsulation.yang 1205 There are many nodes in the flexible-encapsulation YANG module that 1206 are concerned with matching particular frames received on the network 1207 device, and as such adding/modifying/deleting these nodes has a high 1208 risk of causing traffic to be lost because it is not being classified 1209 correctly, or is being classified to a separate sub-interface. The 1210 nodes, all under the subtree 1211 /interfaces/interface/encapsulation/flexible/match, that are 1212 sensitive to this are: 1214 o default 1216 o untagged 1218 o dot1q-priority-tagged 1220 o dot1q-priority-tagged/tag-type 1222 o dot1q-vlan-tagged/outer-tag/vlan-type 1224 o dot1q-vlan-tagged/outer-tag/vlan-id 1226 o dot1q-vlan-tagged/second-tag/vlan-type 1228 o dot1q-vlan-tagged/second-tag/vlan-id 1230 There are also many modes in the flexible-encapsulation YANG module 1231 that are concerned with rewriting the fields in the L2 header for 1232 particular frames received on the network device, and as such 1233 adding/modifying/deleting these nodes has a high risk of causing 1234 traffic to be dropped or incorrectly processed on peer network 1235 devices, or it could cause layer 2 tunnels to go down due to a 1236 mismatch in negotiated MTU. The nodes, all under the subtree 1237 /interfaces/interface/encapsulation/flexible/rewrite, that are 1238 sensitive to this are: 1240 o symmetrical/dot1q-tag-rewrite/pop-tags 1242 o symmetrical/dot1q-tag-rewrite/push-tags/outer-tag/tag-type 1244 o symmetrical/dot1q-tag-rewrite/push-tags/outer-tag/vlan-id 1246 o symmetrical/dot1q-tag-rewrite/push-tags/second-tag/tag-type 1248 o symmetrical/dot1q-tag-rewrite/push-tags/second-tag/vlan-id 1250 o asymmetrical/ingress/dot1q-tag-rewrite/pop-tags 1252 o asymmetrical/ingress/dot1q-tag-rewrite/push-tags/outer-tag/tag- 1253 type 1255 o asymmetrical/ingress/dot1q-tag-rewrite/push-tags/outer-tag/vlan-id 1257 o asymmetrical/ingress/dot1q-tag-rewrite/push-tags/second-tag/tag- 1258 type 1260 o asymmetrical/ingress/dot1q-tag-rewrite/push-tags/second-tag/vlan- 1261 id 1263 o asymmetrical/egress/dot1q-tag-rewrite/pop-tags 1265 o asymmetrical/egress/dot1q-tag-rewrite/push-tags/outer-tag/tag-type 1267 o asymmetrical/egress/dot1q-tag-rewrite/push-tags/outer-tag/vlan-id 1269 o asymmetrical/egress/dot1q-tag-rewrite/push-tags/second-tag/tag- 1270 type 1272 o asymmetrical/egress/dot1q-tag-rewrite/push-tags/second-tag/vlan-id 1274 Nodes in the flexible-encapsulation YANG module that are concerned 1275 with the VLAN tags to use for traffic sourced from the network 1276 element could cause protocol sessions (such as CFM) to fail if they 1277 are added, modified or deleted. The nodes, all under the subtree 1278 /interfaces/interface/flexible-encapsulation/local-traffic-default- 1279 encaps that are sensitive to this are: 1281 o outer-tag/vlan-type 1283 o outer-tag/vlan-id 1285 o second-tag/vlan-type 1287 o second-tag/vlan-id 1289 12. References 1291 12.1. Normative References 1293 [I-D.ietf-netmod-intf-ext-yang] 1294 Wilton, R., Ball, D., tsingh@juniper.net, t., and S. 1295 Sivaraj, "Common Interface Extension YANG Data Models", 1296 draft-ietf-netmod-intf-ext-yang-07 (work in progress), 1297 March 2019. 1299 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1300 Requirement Levels", BCP 14, RFC 2119, 1301 DOI 10.17487/RFC2119, March 1997, 1302 . 1304 [RFC7224] Bjorklund, M., "IANA Interface Type YANG Module", 1305 RFC 7224, DOI 10.17487/RFC7224, May 2014, 1306 . 1308 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1309 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1310 . 1312 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1313 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1314 May 2017, . 1316 [RFC8343] Bjorklund, M., "A YANG Data Model for Interface 1317 Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, 1318 . 1320 12.2. Informative References 1322 [dot1Qcp] Holness, M., "IEEE 802.1Qcp-2018 Bridges and Bridged 1323 Networks - Amendment: YANG Data Model", 2018. 1325 [I-D.ietf-bess-l2vpn-yang] 1326 Shah, H., Brissette, P., Chen, I., Hussain, I., Wen, B., 1327 and K. Tiruveedhula, "YANG Data Model for MPLS-based 1328 L2VPN", draft-ietf-bess-l2vpn-yang-09 (work in progress), 1329 October 2018. 1331 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1332 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 1333 December 1998, . 1335 [RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, 1336 "Encapsulation Methods for Transport of Ethernet over MPLS 1337 Networks", RFC 4448, DOI 10.17487/RFC4448, April 2006, 1338 . 1340 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private 1341 LAN Service (VPLS) Using BGP for Auto-Discovery and 1342 Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, 1343 . 1345 [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private 1346 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 1347 Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, 1348 . 1350 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1351 and A. Bierman, Ed., "Network Configuration Protocol 1352 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1353 . 1355 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1356 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1357 . 1359 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 1360 Protocol (NETCONF) Access Control Model", RFC 6536, 1361 DOI 10.17487/RFC6536, March 2012, 1362 . 1364 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1365 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1366 . 1368 Appendix A. Comparison with the IEEE 802.1Q Configuration Model 1370 In addition to the sub-interface based YANG model proposed here, the 1371 IEEE 802.1Q working group has developed a YANG model for the 1372 configuration of 802.1Q VLANs. This raises the valid question as to 1373 whether the models overlap and whether it is necessary or beneficial 1374 to have two different models for superficially similar constructs. 1375 This section aims to answer that question by summarizing and 1376 comparing the two models. 1378 A.1. Sub-interface based configuration model overview 1380 The key features of the sub-interface based configuration model can 1381 be summarized as: 1383 o The model is primarily designed to enable layer 2 and layer 3 1384 services on Ethernet interfaces that can be defined in a very 1385 flexible way to meet the varied requirements of service providers. 1387 o Traffic is classified from an Ethernet-like interface to sub- 1388 interfaces based on fields in the layer 2 header. This is often 1389 based on VLAN Ids contained in the frame, but the model is 1390 extensible to other arbitrary fields in the frame header. 1392 o Sub-interfaces are just a type of if:interface and hence support 1393 any feature configuration YANG models that can be applied 1394 generally to interfaces. For example, QoS or ACL models that 1395 reference if:interface can be applied to the sub-interfaces, or 1396 the sub-interface can be used as an Access Circuit in L2VPN or 1397 L3VPN models that reference if:interface. 1399 o In the sub-interface based configuration model, the classification 1400 of traffic arriving on an interface to a given sub-interface, 1401 based on fields in the layer 2 header, is completely independent 1402 of how the traffic is forwarded. The sub-interface can be 1403 referenced (via references to if:interface) by other models that 1404 specify how traffic is forwarded; thus sub-interfaces can support 1405 multiple different forwarding paradigms, including but not limited 1406 to: layer 3 (IPv4/IPv6), layer 2 pseudowires (over MPLS or IP), 1407 VPLS instances, EVPN instance. 1409 o The model is flexible in the scope of the VLAN Identifier space. 1410 I.e. by default VLAN Ids can be scoped locally to a single 1411 Ethernet-like trunk interface, but the scope is determined by the 1412 forwarding paradigm that is used. 1414 A.2. IEEE 802.1Q Bridge Configuration Model Overview 1416 The key features of the IEEE 802.1Q bridge configuration model can be 1417 summarized as: 1419 o Each VLAN bridge component has a set of Ethernet interfaces that 1420 are members of that bridge. Sub-interfaces are not used, nor 1421 required in the 802.1Q bridge model. 1423 o Within a VLAN bridge component, the VLAN tag in the packet is 1424 used, along with the destination MAC address, to determine how to 1425 forward the packet. Other forwarding paradigms are not supported 1426 by the 802.1Q model. 1428 o Classification of traffic to a VLAN bridge component is based only 1429 on the Ethernet interface that it arrived on. 1431 o VLAN Identifiers are scoped to a VLAN bridge component. Often 1432 devices only support a single bridge component and hence VLANs are 1433 scoped globally within the device. 1435 o Feature configuration is specified in the context of the bridge, 1436 or particular VLANs on a bridge. 1438 A.3. Possible Overlap Between the Two Models 1440 Both models can be used for configuring similar basic layer 2 1441 forwarding topologies. The 802.1Q bridge configuration model is 1442 optimised for configuring Virtual LANs that span across enterprises 1443 and data centers. 1445 The sub-interface model can also be used for configuring equivalent 1446 Virtual LAN networks that span across enterprises and data centers, 1447 but often requires more configuration to be able to configure the 1448 equivalent constructs to the 802.1Q bridge model. 1450 The sub-interface model really excels when implementing flexible L2 1451 and L3 services, where those services may be handled on the same 1452 physical interface, and where the VLAN Identifier is being solely 1453 used to identify the customer or service that is being provided 1454 rather than a Virtual LAN. The sub-interface model provides more 1455 flexibility as to how traffic can be classified, how features can be 1456 applied to traffic streams, and how the traffic is to be forwarded. 1458 Conversely, the 802.1Q bridge model can also be use to implement L2 1459 services in some scenarios, but only if the forwarding paradigm being 1460 used to implement the service is the native Ethernet forwarding 1461 specified in 802.1Q - other forwarding paradigms such as pseudowires 1462 or VPLS are not supported. The 802.1Q bridge model does not 1463 implement L3 services at all, although this can be partly mitigated 1464 by using a virtual L3 interface construct that is a separate logical 1465 Ethernet-like interface which is a member of the bridge. 1467 In conclusion, it is valid for both of these models to exist since 1468 they have different deployment scenarios for which they are 1469 optimized. Devices may choose which of the models (or both) to 1470 implement depending on what functionality the device is being 1471 designed for. 1473 Authors' Addresses 1475 Robert Wilton (editor) 1476 Cisco Systems 1478 Email: rwilton@cisco.com 1479 David Ball 1480 Cisco Systems 1482 Email: daviball@cisco.com 1484 Tapraj Singh 1485 Cisco Systems 1487 Email: tapsingh@cisco.com 1489 Selvakumar Sivaraj 1490 Juniper Networks 1492 Email: ssivaraj@juniper.net