draft-ietf-netmod-sub-intf-vlan-model.xml

<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" consensus="true" docName="draft-ietf-netmod-sub-intf-vlan-model-08" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.15.0 -->
  <!-- category values: std, bcp, info, exp, and historic
     ipr values: full3667, noModification3667, noDerivatives3667
     you can add the attributes updates="NNNN" and obsoletes="NNNN" 
     they will automatically be output with "(if approved)" -->
    <!-- ***** FRONT MATTER ***** -->
    <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the 
         full title is longer than 39 characters -->
        <title abbrev="Sub-interface VLAN YANG">Sub-interface VLAN YANG Data Models</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-netmod-sub-intf-vlan-model-08"/>
    <!-- add 'role="editor"' below for the editors if appropriate -->
        <!-- Another author who claims to be an editor -->
      <author fullname="Robert Wilton" initials="R.G." role="editor" surname="Wilton">
      <organization>Cisco Systems</organization>
      <address>
        <email>rwilton@cisco.com</email>
      </address>
    </author>
    <author fullname="Scott Mansfield" initials="S" role="editor" surname="Mansfield">
      <organization>Ericsson</organization>
      <address>
        <email>scott.mansfield@ericsson.com</email>
      </address>
    </author>
    <!-- uri and facsimile elements may also be added -->
      <date year="2023"/>
    <!-- If the month and year are both specified and are the current ones, xml2rfc will fill 
         in the current day for you. If only the current year is specified, xml2rfc will fill 
	 in the current day and month for you. If the year is not the current one, it is 
	 necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the 
	 purpose of calculating the expiry date).  With drafts it is normally sufficient to 
	 specify just the year. -->
        <!-- Meta-data Declarations -->
      <area>General</area>
    <workgroup>Internet Engineering Task Force</workgroup>
    <!-- WG name at the upperleft corner of the doc,
         IETF is fine for individual submissions.  
	 If this element is not present, the default is "Network Working Group",
         which is used by the RFC Editor as a nod to the history of the IETF. -->
      <keyword>template</keyword>
    <!-- Keywords will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff
         output. If you submit your draft to the RFC Editor, the
         keywords will be used for the search engine. -->
      <abstract>
      <t>This document defines YANG modules to add support for classifying
        traffic received on interfaces as Ethernet/VLAN framed packets to
        sub-interfaces based on the fields available in the Ethernet/VLAN frame
        headers. These modules allow configuration of Layer 3 and Layer 2
        sub-interfaces (e.g. L2VPN attachment circuits) that can interoperate
        with IETF based forwarding protocols; such as IP and L3VPN services; or
        L2VPN services like VPWS, VPLS, and EVPN.  The sub-interfaces also
        interoperate with VLAN tagged traffic orignating from an IEEE 802.1Q
        compliant bridge.</t>
      <t>The model differs from an IEEE 802.1Q bridge model in that the
        configuration is interface/sub-interface based as opposed to being based
        on membership of an 802.1Q VLAN bridge.</t>
      <t>The YANG data models in this document conforms to the Network
	Management Datastore Architecture (NMDA) defined in RFC 8342.</t>
    </abstract>
  </front>
  <middle>
    <section numbered="true" toc="default">
      <name>Introduction</name>
      <t>This document defines two YANG <xref target="RFC7950" format="default"/> modules that
        augment the encapsulation choice YANG element defined in <xref target="I-D.ietf-netmod-intf-ext-yang" format="default">Interface Extensions YANG</xref>
        and the generic interfaces data model defined in <xref target="RFC8343" format="default"/>.  The two modules provide configuration nodes to
        support classification of Ethernet/VLAN traffic to sub-interfaces, that
        can have interface based feature and service configuration applied to
        them.</t>
      <t>The purpose of these models is to allow IETF defined forwarding
        protocols, for example, IPv6 <xref target="RFC2460" format="default"/>, Ethernet Pseudo Wires
        <xref target="RFC4448" format="default"/> and VPLS <xref target="RFC4761" format="default"/> <xref target="RFC4762" format="default"/>, when configured via appropriate YANG data models <xref target="RFC8344" format="default"/> <xref target="I-D.ietf-bess-l2vpn-yang" format="default"/>, to
        interoperate with VLAN tagged traffic received from an IEEE 802.1Q
        compliant bridge.</t>
      <t>In the case of layer 2 Ethernet services, the flexible
        encapsulation module also supports flexible rewriting of the
        VLAN tags contained in the frame header.</t>
      <t>For reference, a comparison between the sub-interface based YANG
        model documented in this draft and an IEEE 802.1Q bridge model is
        described in <xref target="comparison" format="default"/>.</t>
      <t>In summary, the YANG modules defined in this internet draft are:
      </t>
      <ul empty="true" spacing="normal">
        <li>ietf-if-vlan-encapsulation.yang - Defines the model for
            basic classification of VLAN tagged traffic, normally to
            L3 packet forwarding services</li>
        <li>ietf-if-flexible-encapsulation.yang - Defines the model
            for flexible classification of Ethernet/VLAN traffic,
            normally to L2 frame forwarding services</li>
      </ul>
      <!--      <section title="Requirements Language">

      </section>-->
        <section numbered="true" toc="default">
        <name>Terminology</name>
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
          "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
          "OPTIONAL" in this document are to be interpreted as described in BCP
          14 <xref target="RFC2119" format="default">RFC 2119</xref> <xref target="RFC8174" format="default">RFC
          8174</xref> when, and only when, they appear in all capitals, as shown
          here.</t>
        <t>The term 'sub-interface' is defined in section 2.6 of <xref target="I-D.ietf-netmod-intf-ext-yang" format="default">Interface Extensions
          YANG</xref>.</t>
      </section>
      <section numbered="true" toc="default">
        <name>Tree Diagrams</name>
        <t>Tree diagrams used in this document follow the notation defined in
	   <xref target="RFC8340" format="default"/>.</t>
      </section>
    </section>
    <section numbered="true" toc="default">
      <name>Objectives</name>
      <t>The primary aim of the YANG modules contained in this draft is to
       provide the core model that is required to implement VLAN transport
       services on router based devices that is fully compatible with IEEE
       802.1Q compliant bridges.</t>
      <t>A secondary aim is for the modules to be structured in such a way that
       they can be cleanly extended in future.</t>
      <section numbered="true" toc="default">
        <name>Interoperability with IEEE 802.1Q compliant bridges</name>
        <t>The modules defined in this document are designed to fully
         interoperate with IEEE 802.1Q compliant bridges.  In particular, the
         models are restricted to only matching, adding, or rewriting the 802.1Q
         VLAN tags in frames in ways that are compatible with IEEE 802.1Q
         compliant bridges.</t>
      </section>
    </section>
    <section numbered="true" toc="default">
      <name>Interface VLAN Encapsulation Model</name>
      <t>The Interface VLAN encapsulation model provides appropriate leaves for
       termination of an 802.1Q VLAN tagged segment to a sub-interface (or
       interface) based L3 service, such as IP.  It allows for termination of
       traffic with one or two 802.1Q VLAN tags.</t>
      <t>The L3 service must be configured via a separate YANG data model,
       e.g., <xref target="RFC8344" format="default"/>.  A short example of configuring
       802.1Q VLAN sub-interfaces with IP using YANG is provided in <xref target="example1" format="default"/>.</t>
      <t keepWithNext="true">The "ietf-if-vlan-encapsulation" YANG module has the following structure:</t>
      <artwork name="" type="" align="left" alt=""><![CDATA[
                    
module: ietf-if-vlan-encapsulation
  augment /if:interfaces/if:interface/if-ext:encapsulation
            /if-ext:encaps-type:
    +--:(dot1q-vlan)
       +--rw dot1q-vlan
          +--rw outer-tag
          |  +--rw tag-type    dot1q-tag-type
          |  +--rw vlan-id     vlanid
          +--rw second-tag!
             +--rw tag-type    dot1q-tag-type
             +--rw vlan-id     vlanid
            
          ]]></artwork>
    </section>
    <section numbered="true" toc="default">
      <name>Interface Flexible Encapsulation Model</name>
      <t>The Interface Flexible Encapsulation model is designed to allow for
        the flexible provisioning of layer 2 services. It provides the
        capability to classify and demultiplex Ethernet/VLAN frames received on
        an Ethernet trunk interface to sub-interfaces based on the fields
        available in the layer 2 headers.  Once classified to sub-interfaces, it
        provides the capability to selectively modify fields within the layer 2
        frame header before the frame is handed off to the appropriate
        forwarding code for further handling.  The forwarding instance, e.g.,
        L2VPN, VPLS, etc., is configured using a separate YANG configuration
        model defined elsewhere, e.g., <xref target="I-D.ietf-bess-l2vpn-yang" format="default"/>.</t>
      <t>The model supports a common core set of layer 2 header matches based
        on the 802.1Q tag type and VLAN Ids contained within the header up to a
        tag stack depth of two tags.</t>
      <t>The model supports flexible rewrites of the layer 2 frame header for
        data frames as they are processed on the interface. It defines a set of
        standard tag manipulations that allow for the insertion, removal, or
        rewrite of one or two 802.1Q VLAN tags. The expectation is that
        manipulations are generally implemented in a symmetrical fashion,
        i.e. if a manipulation is performed on ingress traffic on an interface
        then the reverse manipulation is always performed on egress traffic out
        of the same interface. However, the model also allows for asymmetrical
        rewrites, which may be required to implement some forwarding models
        (such as E-Tree).</t>
      <t>The model also allows a flexible encapsulation and rewrite to be
        configured directly on an Ethernet or LAG interface without configuring
        separate child sub-interfaces.  Ingress frames that do not match the
        encapsulation are dropped.  Egress frames MUST conform to the
        encapsulation. </t>
      <t>The final aim for the model design is for it to be cleanly extensible
        to add in additional match and rewrite criteria of the layer 2 header,
        such as matching on the source or destination MAC address, PCP or DEI
        fields in the 802.1Q tags, or the EtherType of the frame payload.
        Rewrites can also be extended to allow for modification of other fields
        within the layer 2 frame header.</t>
      <t>A short example of configuring 802.1Q VLAN sub-interfaces with L2VPN
        using YANG is provided in <xref target="example2" format="default"/>.</t>
      <t keepWithNext="true">The "ietf-if-flexible-encapsulation" YANG module has the following
         structure:</t>
      <artwork name="" type="" align="left" alt=""><![CDATA[
                    
module: ietf-if-flexible-encapsulation
  augment /if:interfaces/if:interface/if-ext:encapsulation
            /if-ext:encaps-type:
    +--:(flexible)
       +--rw flexible
          +--rw match
          |  +--rw (match-type)
          |     +--:(default)
          |     |  +--rw default?                 empty
          |     +--:(untagged)
          |     |  +--rw untagged?                empty
          |     +--:(dot1q-priority-tagged)
          |     |  +--rw dot1q-priority-tagged
          |     |     +--rw tag-type    dot1q-types:dot1q-tag-type
          |     +--:(dot1q-vlan-tagged)
          |        +--rw dot1q-vlan-tagged
          |           +--rw outer-tag
          |           |  +--rw tag-type    dot1q-tag-type
          |           |  +--rw vlan-id     union
          |           +--rw second-tag!
          |           |  +--rw tag-type    dot1q-tag-type
          |           |  +--rw vlan-id     union
          |           +--rw match-exact-tags?   empty
          +--rw rewrite {flexible-rewrites}?
          |  +--rw (direction)?
          |     +--:(symmetrical)
          |     |  +--rw symmetrical
          |     |     +--rw dot1q-tag-rewrite {dot1q-tag-rewrites}?
          |     |        +--rw pop-tags?    uint8
          |     |        +--rw push-tags!
          |     |           +--rw outer-tag
          |     |           |  +--rw tag-type    dot1q-tag-type
          |     |           |  +--rw vlan-id     vlanid
          |     |           +--rw second-tag!
          |     |              +--rw tag-type    dot1q-tag-type
          |     |              +--rw vlan-id     vlanid
          |     +--:(asymmetrical) {asymmetric-rewrites}?
          |        +--rw ingress
          |        |  +--rw dot1q-tag-rewrite {dot1q-tag-rewrites}?
          |        |     +--rw pop-tags?    uint8
          |        |     +--rw push-tags!
          |        |        +--rw outer-tag
          |        |        |  +--rw tag-type    dot1q-tag-type
          |        |        |  +--rw vlan-id     vlanid
          |        |        +--rw second-tag!
          |        |           +--rw tag-type    dot1q-tag-type
          |        |           +--rw vlan-id     vlanid
          |        +--rw egress
          |           +--rw dot1q-tag-rewrite {dot1q-tag-rewrites}?
          |              +--rw pop-tags?    uint8
          |              +--rw push-tags!
          |                 +--rw outer-tag
          |                 |  +--rw tag-type    dot1q-tag-type
          |                 |  +--rw vlan-id     vlanid
          |                 +--rw second-tag!
          |                    +--rw tag-type    dot1q-tag-type
          |                    +--rw vlan-id     vlanid
          +--rw local-traffic-default-encaps!
             +--rw outer-tag
             |  +--rw tag-type    dot1q-tag-type
             |  +--rw vlan-id     vlanid
             +--rw second-tag!
                +--rw tag-type    dot1q-tag-type
                +--rw vlan-id     vlanid
            
          ]]></artwork>
    </section>
    <section numbered="true" toc="default">
      <name>VLAN Encapsulation YANG Module</name>
      <t>This YANG module augments the 'encapsulation' container
       defined in <xref target="I-D.ietf-netmod-intf-ext-yang" format="default">ietf-if-extensions.yang</xref>.
       It also contains references to <xref target="RFC8343" format="default"/>,
       <xref target="RFC7224" format="default"/>, and <xref target="IEEE802.1Qcp-2018" format="default"/>.</t>
      <sourcecode name="ietf-if-vlan-encapsulation@2022-12-14.yang" type="" markers="true"><![CDATA[
module ietf-if-vlan-encapsulation {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-if-vlan-encapsulation";
  prefix if-vlan;

  import ietf-interfaces {
    prefix if;
    reference
      "RFC 8343: A YANG Data Model For Interface Management";
  }

  import iana-if-type {
    prefix ianaift;
    reference
      "RFC 7224: IANA Interface Type YANG Module";
  }

  import ieee802-dot1q-types {
    prefix dot1q-types;
    reference
      "IEEE Std 802.1Qcp-2018: IEEE Standard for Local and
       metropolitan area networks -- Bridges and Bridged Networks --
       Amendment 30: YANG Data Model";
  }

  import ietf-if-extensions {
    prefix if-ext;
    reference
      "RFC XXXX: Common Interface Extension YANG Data Models";
  }

  organization
    "IETF NETMOD (NETCONF Data Modeling Language) Working Group";

  contact
    "WG Web:   <http://tools.ietf.org/wg/netmod/>
     WG List:  <mailto:netmod@ietf.org>

     Editor:   Robert Wilton
               <mailto:rwilton@cisco.com>";

  description
    "This YANG module models configuration to classify IEEE 802.1Q
     VLAN tagged Ethernet traffic by exactly matching the tag type
     and VLAN identifier of one or two 802.1Q VLAN tags in the frame.

     Copyright (c) 2022 IETF Trust and the persons identified as
     authors of the code.  All rights reserved.

     Redistribution and use in source and binary forms, with or
     without modification, is permitted pursuant to, and subject to
     the license terms contained in, the Simplified BSD License set
     forth in Section 4.c of the IETF Trust's Legal Provisions
     Relating to IETF Documents
     (https://trustee.ietf.org/license-info).

     This version of this YANG module is part of RFC XXXX
     (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
     for full legal notices.

     The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
     NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
     'MAY', and 'OPTIONAL' in this document are to be interpreted as
     described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
     they appear in all capitals, as shown here.";

  revision 2022-12-14 {
    description
      "Latest draft revision";
    reference
      "RFC XXXX: Sub-interface VLAN YANG Data Models";
  }

  augment "/if:interfaces/if:interface/if-ext:encapsulation/"
        + "if-ext:encaps-type" {
    when "derived-from-or-self(../if:type,
                               'ianaift:ethernetCsmacd') or
          derived-from-or-self(../if:type,
                               'ianaift:ieee8023adLag') or
          derived-from-or-self(../if:type, 'ianaift:l2vlan') or
          derived-from-or-self(../if:type,
                               'if-ext:ethSubInterface')" {
        description
          "Applies only to Ethernet-like interfaces and
           sub-interfaces.";
    }

    description
      "Augment the generic interface encapsulation with basic 802.1Q
       VLAN tag classifications";

    case dot1q-vlan {
      container dot1q-vlan {

        description
          "Classifies 802.1Q VLAN tagged Ethernet frames to a
           sub-interface (or interface) by exactly matching the
           number of tags, tag type(s) and VLAN identifier(s).

           Only frames matching the classification configured on a
           sub-interface/interface are processed on that
           sub-interface/interface.

           Frames that do not match any sub-interface are processed
           directly on the parent interface, if it is associated with
           a forwarding instance, otherwise they are dropped.";

        container outer-tag {
          must 'tag-type = "dot1q-types:s-vlan" or '
             + 'tag-type = "dot1q-types:c-vlan"' {

            error-message
              "Only C-VLAN and S-VLAN tags can be matched.";

            description
              "For IEEE 802.1Q interoperability, only C-VLAN and
               S-VLAN tags are matched.";
          }

          description
            "Specifies the VLAN tag values to match against the
             outermost (first) 802.1Q VLAN tag in the frame.";

          uses dot1q-types:dot1q-tag-classifier-grouping;
        }

        container second-tag {
          must '../outer-tag/tag-type = "dot1q-types:s-vlan" and '
             + 'tag-type = "dot1q-types:c-vlan"' {

            error-message
              "When matching two 802.1Q VLAN tags, the outermost
               (first) tag in the frame MUST be specified and be of
               S-VLAN type and the second tag in the frame must be of
               C-VLAN tag type.";

            description
              "For IEEE 802.1Q interoperability, when matching two
               802.1Q VLAN tags, it is REQUIRED that the outermost
               tag exists and is an S-VLAN, and the second tag is a
               C-VLAN.";
          }

          presence "Classify frames that have two 802.1Q VLAN tags.";

          description
            "Specifies the VLAN tag values to match against the
             second outermost 802.1Q VLAN tag in the frame.";

          uses dot1q-types:dot1q-tag-classifier-grouping;
        }
      }
    }
  }
}
]]></sourcecode>
    </section>
    <section numbered="true" toc="default">
      <name>Flexible Encapsulation YANG Module</name>
      <t>This YANG module augments the 'encapsulation' container
       defined in <xref target="I-D.ietf-netmod-intf-ext-yang" format="default">ietf-if-extensions.yang</xref>.
       This YANG module also augments the 'interface' list entry
       defined in <xref target="RFC8343" format="default"/>.  It also contains
       references to <xref target="RFC7224" format="default"/>, and <xref target="IEEE802.1Qcp-2018" format="default"/>.</t>
      <sourcecode name="ietf-if-flexible-encapsulation@2022-12-14.yang" type="" markers="true"><![CDATA[
module ietf-if-flexible-encapsulation {
  yang-version 1.1;
  namespace
    "urn:ietf:params:xml:ns:yang:ietf-if-flexible-encapsulation";
  prefix if-flex;

  import ietf-interfaces {
    prefix if;
    reference
      "RFC 8343: A YANG Data Model For Interface Management";
  }

  import iana-if-type {
    prefix ianaift;
    reference
      "RFC 7224: IANA Interface Type YANG Module";
  }

  import ieee802-dot1q-types {
    prefix dot1q-types;
    reference
      "IEEE Std 802.1Qcp-2018: IEEE Standard for Local and
       metropolitan area networks -- Bridges and Bridged Networks --
       Amendment 30: YANG Data Model";
  }

  import ietf-if-extensions {
    prefix if-ext;
    reference
      "RFC XXXX: Common Interface Extension YANG Data Models";
  }

  organization
    "IETF NETMOD (NETCONF Data Modeling Language) Working Group";

  contact
    "WG Web:   <http://tools.ietf.org/wg/netmod/>
     WG List:  <mailto:netmod@ietf.org>

     Editor:   Robert Wilton
               <mailto:rwilton@cisco.com>";

  description
    "This YANG module describes interface configuration for flexible
     classification and rewrites of IEEE 802.1Q VLAN tagged Ethernet
     traffic.

     Copyright (c) 2022 IETF Trust and the persons identified as
     authors of the code.  All rights reserved.

     Redistribution and use in source and binary forms, with or
     without modification, is permitted pursuant to, and subject to
     the license terms contained in, the Simplified BSD License set
     forth in Section 4.c of the IETF Trust's Legal Provisions
     Relating to IETF Documents
     (https://trustee.ietf.org/license-info).

     This version of this YANG module is part of RFC XXXX
     (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
     for full legal notices.

     The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
     NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
     'MAY', and 'OPTIONAL' in this document are to be interpreted as
     described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
     they appear in all capitals, as shown here.";

  revision 2022-12-14 {
    description
      "Latest draft revision";
    reference
      "RFC XXXX: Sub-interface VLAN YANG Data Models";
  }

  feature flexible-rewrites {
    description
      "This feature indicates that the network element supports
        specifying flexible rewrite operations.";
  }

  feature asymmetric-rewrites {
    description
      "This feature indicates that the network element supports
       specifying different rewrite operations for the ingress
       rewrite operation and egress rewrite operation.";
  }

  feature dot1q-tag-rewrites {
    description
      "This feature indicates that the network element supports the
       flexible rewrite functionality specifying 802.1Q tag
       rewrites.";
  }

  grouping flexible-match {
    description
      "Represents a flexible frame classification:

       The rules for a flexible match are:
         1. Match-type: default, untagged, priority tag, or tag
            stack.
         2. Each tag in the stack of tags matches:
          a. tag type (802.1Q or 802.1ad) +
          b. tag value:
            i.   single tag
            ii.  set of tag ranges/values.
            iii. 'any' keyword";

    choice match-type {
      mandatory true;

      description
        "Provides a choice of how the frames may be
         matched";

      case default {
        description
          "Default match";

        leaf default {
          type empty;

          description
            "Default match.  Matches all traffic not matched to any
             other peer sub-interface by a more specific
             encapsulation.";
        }
      }

      case untagged {
        description
          "Match untagged Ethernet frames only";

        leaf untagged {
          type empty;

          description
            "Untagged match.  Matches all untagged traffic.";
        }
      }

      case dot1q-priority-tagged {
        description
          "Match 802.1Q priority tagged Ethernet frames only";

        container dot1q-priority-tagged {
          description
            "802.1Q priority tag match";

          leaf tag-type {
            type dot1q-types:dot1q-tag-type;
            mandatory true;

            description
              "The 802.1Q tag type of matched priority
               tagged packets";
          }
        }
      }

      case dot1q-vlan-tagged {
        container dot1q-vlan-tagged {
          description
            "Matches VLAN tagged frames";

          container outer-tag {
            must 'tag-type = "dot1q-types:s-vlan" or '
               + 'tag-type = "dot1q-types:c-vlan"' {

              error-message
                "Only C-VLAN and S-VLAN tags can be matched.";

              description
                "For IEEE 802.1Q interoperability, only C-VLAN and
                 S-VLAN tags can be matched.";
            }

            description
              "Classifies traffic using the outermost (first) VLAN
               tag on the frame.";

            uses "dot1q-types:"
               + "dot1q-tag-ranges-or-any-classifier-grouping";
          }

          container second-tag {
            must
              '../outer-tag/tag-type = "dot1q-types:s-vlan" and '
            + 'tag-type = "dot1q-types:c-vlan"' {

              error-message
                "When matching two tags, the outermost (first) tag
                 must be specified and of S-VLAN type and the second
                 outermost tag must be of C-VLAN tag type.";

              description
                "For IEEE 802.1Q interoperability, when matching two
                 tags, it is required that the outermost (first) tag
                 exists and is an S-VLAN, and the second outermost
                 tag is a C-VLAN.";
            }

            presence "Also classify on the second VLAN tag.";

            description
              "Classifies traffic using the second outermost VLAN tag
               on the frame.";

            uses "dot1q-types:"
               + "dot1q-tag-ranges-or-any-classifier-grouping";
          }

          leaf match-exact-tags {
            type empty;
            description
              "If set, indicates that all 802.1Q VLAN tags in the
               Ethernet frame header must be explicitly matched, i.e.
               the EtherType following the matched tags must not be a
               802.1Q tag EtherType.  If unset then extra 802.1Q VLAN
               tags are allowed.";
          }
        }
      }
    }
  }

  grouping dot1q-tag-rewrite {
    description
      "Flexible rewrite grouping.  Can be either be expressed
       symmetrically, or independently in the ingress and/or egress
       directions.";

    leaf pop-tags {
      type uint8 {
        range "1..2";
      }

      description
        "The number of 802.1Q VLAN tags to pop, or translate if used
         in conjunction with push-tags.

         Popped tags are the outermost tags on the frame.";
    }

    container push-tags {
      presence "802.1Q tags are pushed or translated";

      description
        "The 802.1Q tags to push on the front of the frame, or
         translate if configured in conjunction with pop-tags.";

      container outer-tag {
        must 'tag-type = "dot1q-types:s-vlan" or '
           + 'tag-type = "dot1q-types:c-vlan"' {

          error-message "Only C-VLAN and S-VLAN tags can be pushed.";

          description
            "For IEEE 802.1Q interoperability, only C-VLAN and S-VLAN
             tags can be pushed.";
        }

        description
          "The outermost (first) VLAN tag to push onto the frame.";

        uses dot1q-types:dot1q-tag-classifier-grouping;
      }

      container second-tag {
        must '../outer-tag/tag-type = "dot1q-types:s-vlan" and '
           + 'tag-type = "dot1q-types:c-vlan"' {

          error-message
            "When pushing/rewriting two tags, the outermost tag must
             be specified and of S-VLAN type and the second outermost
             tag must be of C-VLAN tag type.";

          description
            "For IEEE 802.1Q interoperability, when pushing two tags,
             it is required that the outermost tag exists and is an
             S-VLAN, and the second outermost tag is a C-VLAN.";
        }

        presence
          "In addition to the first tag, also push/rewrite a second
           VLAN tag.";

        description
          "The second outermost VLAN tag to push onto the frame.";

        uses dot1q-types:dot1q-tag-classifier-grouping;
      }
    }
  }

  grouping flexible-rewrite {
    description
      "Grouping for flexible rewrites of fields in the L2 header.
       
       Restricted to flexible 802.1Q VLAN tag rewrites, but could be
       extended to cover rewrites of other fields in the L2 header in
       future.";

    container dot1q-tag-rewrite {
      if-feature "dot1q-tag-rewrites";

      description
        "802.1Q VLAN tag rewrite.

         Translate operations are expressed as a combination of tag
         push and pop operations.  E.g., translating the outer tag is
         expressed as popping a single tag, and pushing a single tag.
         802.1Q tags that are translated SHOULD preserve the PCP and
         DEI fields unless if a different QoS behavior has been
         specified.";
      uses dot1q-tag-rewrite;
    }
  }

  augment "/if:interfaces/if:interface/if-ext:encapsulation/"
        + "if-ext:encaps-type" {
    when "derived-from-or-self(../if:type,
                               'ianaift:ethernetCsmacd') or
          derived-from-or-self(../if:type,
                               'ianaift:ieee8023adLag') or
          derived-from-or-self(../if:type, 'ianaift:l2vlan') or
          derived-from-or-self(../if:type,
                               'if-ext:ethSubInterface')" {

        description
          "Applies only to Ethernet-like interfaces and
           sub-interfaces.";
    }

    description
      "Augment the generic interface encapsulation with flexible
       match and rewrite for VLAN sub-interfaces.";

    case flexible {
      description
        "Flexible encapsulation and rewrite";

      container flexible {
        description
          "Flexible encapsulation allows for the matching of ranges
           and sets of 802.1Q VLAN Tags and performing rewrite
           operations on the VLAN tags.

           The structure is also designed to be extended to allow for
           matching/rewriting other fields within the L2 frame header
           if required.";

        container match {
          description
            "Flexibly classifies Ethernet frames to a sub-interface
             (or interface) based on the L2 header fields.

             Only frames matching the classification configured on a
             sub-interface/interface are processed on that
             sub-interface/interface.

             Frames that do not match any sub-interface are processed
             directly on the parent interface, if it is associated
             with a forwarding instance, otherwise they are dropped.

             If a frame could be classified to multiple
             sub-interfaces then they get classified to the
             sub-interface with the most specific match.  E.g.,
             matching two VLAN tags in the frame is more specific
             than matching the outermost VLAN tag, which is more
             specific than the catch all 'default' match.";

          uses flexible-match;
        }

        container rewrite {
          if-feature "flexible-rewrites";

          description
            "L2 frame rewrite operations.

             Rewrites allows for modifications to the L2 frame header
             as it transits the interface/sub-interface.  Examples
             include adding a VLAN tag, removing a VLAN tag, or
             rewriting the VLAN Id carried in a VLAN tag.";

          choice direction {
            description
              "Whether the rewrite policy is symmetrical or
               asymmetrical.";

            case symmetrical {
              container symmetrical {
                uses flexible-rewrite;

                description
                  "Symmetrical rewrite.  Expressed in the ingress
                   direction, but the reverse operation is applied to
                   egress traffic.
 
                   E.g., if a tag is pushed on ingress traffic, then
                   the reverse operation is a 'pop 1', that is
                   performed on traffic egressing the interface, so
                   a peer device sees a consistent L2 encapsulation
                   for both ingress and egress traffic.";
              }
            }

            case asymmetrical {
              if-feature "asymmetric-rewrites";

              description
                "Asymmetrical rewrite.

                 Rewrite operations may be specified in only a single
                 direction, or different rewrite operations may be
                 specified in each direction.";

              container ingress {
                uses flexible-rewrite;

                description
                  "A rewrite operation that only applies to ingress
                   traffic.

                   Ingress rewrite operations are performed before
                   the frame is subsequently processed by the
                   forwarding operation.";
              }

              container egress {
                uses flexible-rewrite;

                description
                  "A rewrite operation that only applies to egress
                   traffic.";
              }
            }
          }
        }

        container local-traffic-default-encaps {
          presence "A local traffic default encapsulation has been
                    specified.";

          description
            "Specifies the 802.1Q VLAN tags to use by default for
             locally sourced traffic from the interface.

             Used for encapsulations that match a range of VLANs (or
             'any'), where the source VLAN Ids are otherwise
             ambiguous.";

          container outer-tag {
            must 'tag-type = "dot1q-types:s-vlan" or '
               + 'tag-type = "dot1q-types:c-vlan"' {

              error-message
                "Only C-VLAN and S-VLAN tags can be matched.";

              description
                "For IEEE 802.1Q interoperability, only C-VLAN and
                 S-VLAN tags can be matched.";
            }

            description
              "The outermost (first) VLAN tag for locally sourced
               traffic.";

            uses dot1q-types:dot1q-tag-classifier-grouping;
          }

          container second-tag {
            must
              '../outer-tag/tag-type = "dot1q-types:s-vlan" and '
            + 'tag-type = "dot1q-types:c-vlan"' {

              error-message
                "When specifying two tags, the outermost (first) tag
                 must be specified and of S-VLAN type and the second
                 outermost tag must be of C-VLAN tag type.";

              description
                "For IEEE 802.1Q interoperability, when specifying
                 two tags, it is required that the outermost (first)
                 tag exists and is an S-VLAN, and the second
                 outermost tag is a C-VLAN.";
            }

            presence
              "Indicates existence of a second outermost VLAN tag.";

            description
              "The second outermost VLAN tag for locally sourced
               traffic.";

            uses dot1q-types:dot1q-tag-classifier-grouping;
          }
        }
      }
    }
  }
}
]]></sourcecode>
    </section>
    <section anchor="Examples" numbered="true" toc="default">
      <name>Examples</name>
      <t>The following sections give examples of configuring a sub-interface
        supporting L3 forwarding, and a sub-interface being used in
        conjunction with the IETF L2VPN YANG model <xref target="I-D.ietf-bess-l2vpn-yang" format="default"/>.</t>
      <section anchor="example1" numbered="true" toc="default">
        <name>Layer 3 sub-interfaces with IPv6</name>
        <t>This example illustrates two layer sub-interfaces, 'eth0.1' and
          'eth0.2', both are child interfaces of the Ethernet interface
          'eth0'.</t>
        <t>'eth0.1' is configured to match traffic with two VLAN tags: an
          outer S-VLAN of 10 and an inner C-VLAN of 20.</t>
        <t>'eth0.2' is configured to match traffic with a single S-VLAN tag,
          with VLAN Id 11.</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
                        
<?xml version="1.0" encoding="utf-8"?>
<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <interfaces 
  xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"
  xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type"
  xmlns:dot1q-types="urn:ieee:std:802.1Q:yang:ieee802-dot1q-types"
  xmlns:if-ext="urn:ietf:params:xml:ns:yang:ietf-if-extensions">
    <interface>
      <name>eth0</name>
      <type>ianaift:ethernetCsmacd</type>
    </interface>
    <interface>
      <name>eth0.1</name>
      <type>ianaift:l2vlan</type>
      <if-ext:parent-interface>eth0</if-ext:parent-interface>
      <if-ext:encapsulation>
        <dot1q-vlan
         xmlns=
            "urn:ietf:params:xml:ns:yang:ietf-if-vlan-encapsulation">
          <outer-tag>
            <tag-type>dot1q-types:s-vlan</tag-type>
            <vlan-id>10</vlan-id>
          </outer-tag>
          <second-tag>
            <tag-type>dot1q-types:c-vlan</tag-type>
            <vlan-id>20</vlan-id>
          </second-tag>
        </dot1q-vlan>
      </if-ext:encapsulation>
      <ipv6 xmlns="urn:ietf:params:xml:ns:yang:ietf-ip">
        <forwarding>true</forwarding>
        <address>
          <ip>2001:db8:10::1</ip>
          <prefix-length>48</prefix-length>
        </address>
      </ipv6>
    </interface>
    <interface>
      <name>eth0.2</name>
      <type>ianaift:l2vlan</type>
      <if-ext:parent-interface>eth0</if-ext:parent-interface>
      <if-ext:encapsulation>
        <dot1q-vlan
         xmlns=
            "urn:ietf:params:xml:ns:yang:ietf-if-vlan-encapsulation">
          <outer-tag>
            <tag-type>dot1q-types:s-vlan</tag-type>
            <vlan-id>11</vlan-id>
          </outer-tag>
        </dot1q-vlan>
      </if-ext:encapsulation>
      <ipv6 xmlns="urn:ietf:params:xml:ns:yang:ietf-ip">
        <forwarding>true</forwarding>
        <address>
          <ip>2001:db8:11::1</ip>
          <prefix-length>48</prefix-length>
        </address>
      </ipv6>
    </interface>
  </interfaces>
</config>
            
              ]]></artwork>
      </section>
      <section anchor="example2" numbered="true" toc="default">
        <name>Layer 2 sub-interfaces with L2VPN</name>
        <t>This example illustrates a layer 2 sub-interface 'eth0.3'
            configured to match traffic with a S-VLAN tag of 10, and C-VLAN tag
            of 21; and remov the outer tag (S-VLAN 10) before the traffic is
            passed off to the L2VPN service.</t>
        <t>It also illustrates another sub-interface 'eth1.0' under a
            separate physical interface configured to match traffic with a
            C-VLAN of 50, with the tag removed before traffic is given to any
            service.  Sub-interface 'eth1.0' is not currently bound to any
            service and hence traffic classified to that sub-interface is
            dropped.</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
                        
<?xml version="1.0" encoding="utf-8"?>
<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <interfaces 
  xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"
  xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type"
  xmlns:dot1q-types="urn:ieee:std:802.1Q:yang:ieee802-dot1q-types"
  xmlns:if-ext="urn:ietf:params:xml:ns:yang:ietf-if-extensions">
    <interface>
      <name>eth0</name>
      <type>ianaift:ethernetCsmacd</type>
    </interface>
    <interface>
      <name>eth0.3</name>
      <type>ianaift:l2vlan</type>
      <if-ext:parent-interface>eth0</if-ext:parent-interface>
      <if-ext:encapsulation>
        <flexible xmlns=
        "urn:ietf:params:xml:ns:yang:ietf-if-flexible-encapsulation">
          <match>
            <dot1q-vlan-tagged>
              <outer-tag>
                <tag-type>dot1q-types:s-vlan</tag-type>
                <vlan-id>10</vlan-id>
              </outer-tag>
              <second-tag>
                <tag-type>dot1q-types:c-vlan</tag-type>
                <vlan-id>21</vlan-id>
              </second-tag>
            </dot1q-vlan-tagged>
          </match>
          <rewrite>
            <symmetrical>
              <dot1q-tag-rewrite>
                <pop-tags>1</pop-tags>
              </dot1q-tag-rewrite>
            </symmetrical>
          </rewrite>
        </flexible>
      </if-ext:encapsulation>
    </interface>
    <interface>
      <name>eth1</name>
      <type>ianaift:ethernetCsmacd</type>
    </interface>
    <interface>
      <name>eth1.0</name>
      <type>ianaift:l2vlan</type>
      <if-ext:parent-interface>eth0</if-ext:parent-interface>
      <if-ext:encapsulation>
        <flexible xmlns=
        "urn:ietf:params:xml:ns:yang:ietf-if-flexible-encapsulation">
          <match>
            <dot1q-vlan-tagged>
              <outer-tag>
                <tag-type>dot1q-types:c-vlan</tag-type>
                <vlan-id>50</vlan-id>
              </outer-tag>
            </dot1q-vlan-tagged>
          </match>
          <rewrite>
            <symmetrical>
              <dot1q-tag-rewrite>
                <pop-tags>1</pop-tags>
              </dot1q-tag-rewrite>
            </symmetrical>
          </rewrite>
        </flexible>
      </if-ext:encapsulation>
    </interface>
  </interfaces>
  <network-instances
      xmlns="urn:ietf:params:xml:ns:yang:ietf-network-instance">
    <network-instance
     xmlns:l2vpn="urn:ietf:params:xml:ns:yang:ietf-l2vpn">   
      <name>p2p-l2-1</name>
      <description>Point to point L2 service</description>
      <l2vpn:type>l2vpn:vpws-instance-type</l2vpn:type>
      <l2vpn:signaling-type>
        l2vpn:ldp-signaling
      </l2vpn:signaling-type>
      <endpoint xmlns="urn:ietf:params:xml:ns:yang:ietf-l2vpn">
        <name>local</name>
        <ac>
          <name>eth0.3</name>
        </ac>
      </endpoint>
      <endpoint xmlns="urn:ietf:params:xml:ns:yang:ietf-l2vpn">
        <name>remote</name>
        <pw>
          <name>pw1</name>
        </pw>
      </endpoint>
      <vsi-root>
      <!-- Does not Validate -->
      </vsi-root>
    </network-instance>
  </network-instances>
  <pseudowires
      xmlns="urn:ietf:params:xml:ns:yang:ietf-pseudowires">
    <pseudowire>
      <name>pw1</name>
        <peer-ip>2001:db8::50></peer-ip>
        <pw-id>100</pw-id>
    </pseudowire>
  </pseudowires>
</config>
            
            ]]></artwork>
      </section>
    </section>
    <!-- This PI places the pagebreak correctly (before the section title) in the text output. -->
      <section anchor="Acknowledgements" numbered="true" toc="default">
      <name>Acknowledgements</name>
      <t>The authors would particularly like to thank Benoit Claise, John
        Messenger, Glenn Parsons, and Dan Romascanu for their help progressing
        this draft.</t>
      <t>The authors would also like to thank Martin Bjorklund, Alex Campbell,
        Don Fedyk, Eric Gray, Giles Heron, Marc Holness, Iftekhar Hussain, Neil
        Ketley, William Lupton, John Messenger, Glenn Parsons, Ludwig Pauwels,
        Joseph White, Vladimir Vassilev, and members of the IEEE 802.1 WG for
        their helpful reviews and feedback on this draft.</t>
    </section>
    <section numbered="true" toc="default">
      <name>ChangeLog</name>
      <t>XXX, RFC Editor, please delete this change log before publication.</t>
      <section numbered="true" toc="default">
        <name>WG version -08</name>
        <ul spacing="normal">
          <li>Issues Resolved...TBD</li>
        </ul>
      </section>
      <section numbered="true" toc="default">
        <name>WG version -07 and -06</name>
        <ul spacing="normal">
          <li>Apply markups from WG last call.</li>
        </ul>
      </section>
      <section numbered="true" toc="default">
        <name>WG version -05</name>
        <ul spacing="normal">
          <li>Incorporate feedback from IEEE 802.1 WG, John Messenger in
              particular.</li>
          <li>Adding must constraints to ensure outer tags are always matched
	      to C-VLAN and S-VLAN tags.</li>
          <li>Fixed bug where second tag could be matched without outer tag,
	      and where tags must not be specified.</li>
        </ul>
      </section>
      <section numbered="true" toc="default">
        <name>WG version -04</name>
        <ul spacing="normal">
          <li>Added examples</li>
        </ul>
      </section>
      <section numbered="true" toc="default">
        <name>WG version -03</name>
        <ul spacing="normal">
          <li>Fix namespace bug in XPath identity references, removed
              extraneous 'dot1q-tag' containers.</li>
        </ul>
      </section>
      <section numbered="true" toc="default">
        <name>WG version -02</name>
        <ul spacing="normal">
          <li>Use explicit containers for outer and inner tags rather than
              lists.</li>
        </ul>
      </section>
      <section numbered="true" toc="default">
        <name>WG version -01</name>
        <ul spacing="normal">
          <li>Tweaked the abstract.</li>
          <li>Removed unnecessary feature for the L3 sub-interface
              module.</li>
          <li>Update the 802.1Qcp type references.</li>
          <li>Remove extra tag container for L3 sub-interfaces YANG.</li>
        </ul>
      </section>
      <section numbered="true" toc="default">
        <name>Version -04</name>
        <ul spacing="normal">
          <li>IEEE 802.1 specific types have been removed from the draft.
              These are now referenced from the 802.1Qcp draft YANG modules.</li>
          <li>Fixed errors in the xpath expressions.</li>
        </ul>
      </section>
      <section numbered="true" toc="default">
        <name>Version -03</name>
        <ul spacing="normal">
          <li>Incorporates feedback received from presenting to the IEEE
              802.1 WG.</li>
          <li>Updates the modules for double tag matches/rewrites to restrict
              the outer tag type to S-VLAN and inner tag type to C-VLAN.</li>
          <li>Updates the introduction to indicate primary use case is for
              IETF forwarding protocols.</li>
          <li>Updates the objectives to make IEEE 802.1Q bridge
              interoperability a key objective.</li>
        </ul>
      </section>
    </section>
    <!-- Possibly a 'Contributors' section ... -->
      <section anchor="IANA" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <section anchor="yang-module-registrations" numbered="true" toc="default">
        <name>YANG Module Registrations</name>
        <t>The following YANG modules are requested to be registered in the IANA
          "YANG Module Names" <xref target="RFC6020" format="default"/> registry:</t>
        <t>The ietf-if-vlan-encapsulation module:</t>
        <ul empty="true" spacing="normal">
          <li>Name: ietf-if-vlan-encapsulation</li>
          <li>XML Namespace: urn:ietf:params:xml:ns:yang:ietf-if-vlan-encapsulation</li>
          <li>Prefix: if-vlan</li>
          <li>Reference: [RFCXXXX]</li>
        </ul>
        <t>The ietf-if-flexible-encapsulation module:</t>
        <ul empty="true" spacing="normal">
          <li>Name: ietf-if-flexible-encapsulation</li>
          <li>XML Namespace: urn:ietf:params:xml:ns:yang:ietf-if-flexible-encapsulation</li>
          <li>Prefix: if-flex</li>
          <li>Reference: [RFCXXXX]</li>
        </ul>
        <t>This document registers two URIs in the "IETF XML Registry" <xref target="RFC3688" format="default"/>.  Following the format in RFC 3688, the following
        registrations have been made.

        </t>
        <ul empty="true" spacing="normal">
          <li>URI: urn:ietf:params:xml:ns:yang:ietf-if-vlan-encapsulation</li>
          <li>Registrant Contact: The IESG.</li>
          <li>XML: N/A, the requested URI is an XML namespace.</li>
        </ul>
        <ul empty="true" spacing="normal">
          <li>URI: urn:ietf:params:xml:ns:yang:ietf-if-flexible-encapsulation</li>
          <li>Registrant Contact: The IESG.</li>
          <li>XML: N/A, the requested URI is an XML namespace.</li>
        </ul>
      </section>
    </section>
    <section anchor="Security" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>The YANG module defined in this memo is designed to be accessed via
        the NETCONF protocol <xref target="RFC6241" format="default">RFC 6241</xref>. The lowest
        NETCONF layer is the secure transport layer and the mandatory to
        implement secure transport is SSH <xref target="RFC6242" format="default">RFC
        6242</xref>.  The NETCONF access control model <xref target="RFC6536" format="default">RFC 6536</xref> provides the means to restrict access
        for particular NETCONF users to a pre-configured subset of all available
        NETCONF protocol operations and content.</t>
      <t>There are a number of
        data nodes defined in this YANG module which are
        writable/creatable/deletable (i.e. config true, which is the default).
        These data nodes may be considered sensitive or vulnerable in some
        network environments.  Write operations (e.g. edit-config) to these data
        nodes without proper protection can have a negative effect on network
        operations.  These are the subtrees and data nodes and their
        sensitivity/vulnerability:</t>
      <section numbered="true" toc="default">
        <name>ietf-if-vlan-encapsulation.yang</name>
        <t>The nodes in the vlan encapsulation YANG module are concerned with
          matching particular frames received on the network device to connect
          them to a layer 3 forwarding instance, and as such
          adding/modifying/deleting these nodes has a high risk of causing
          traffic to be lost because it is not being classified correctly, or is
          being classified to a separate sub-interface. The nodes, all under the
          subtree /interfaces/interface/encapsulation/dot1q-vlan, that are
          sensitive to this are:
        </t>
        <ul spacing="normal">
          <li>outer-tag/tag-type</li>
          <li>outer-tag/vlan-id</li>
          <li>second-tag/tag-type</li>
          <li>second-tag/vlan-id</li>
        </ul>
      </section>
      <section numbered="true" toc="default">
        <name>ietf-if-flexible-encapsulation.yang</name>
        <t>There are many nodes in the flexible encapsulation YANG module that
          are concerned with matching particular frames received on the network
          device, and as such adding/modifying/deleting these nodes has a high
          risk of causing traffic to be lost because it is not being classified
          correctly, or is being classified to a separate sub-interface. The
          nodes, all under the subtree
          /interfaces/interface/encapsulation/flexible/match, that are sensitive
          to this are:
        </t>
        <ul spacing="normal">
          <li>default</li>
          <li>untagged</li>
          <li>dot1q-priority-tagged</li>
          <li>dot1q-priority-tagged/tag-type</li>
          <li>dot1q-vlan-tagged/outer-tag/vlan-type</li>
          <li>dot1q-vlan-tagged/outer-tag/vlan-id</li>
          <li>dot1q-vlan-tagged/second-tag/vlan-type</li>
          <li>dot1q-vlan-tagged/second-tag/vlan-id</li>
        </ul>
        <t>There are also many modes in the flexible encapsulation YANG module
	  that are concerned with rewriting the fields in the L2 header for
	  particular frames received on the network device, and as such
	  adding/modifying/deleting these nodes has a high risk of causing
	  traffic to be dropped or incorrectly processed on peer network
	  devices, or it could cause layer 2 tunnels to go down due to a
	  mismatch in negotiated MTU. The nodes, all under the subtree
	  /interfaces/interface/encapsulation/flexible/rewrite, that are
	  sensitive to this are:
        </t>
        <ul spacing="normal">
          <li>symmetrical/dot1q-tag-rewrite/pop-tags</li>
          <li>symmetrical/dot1q-tag-rewrite/push-tags/outer-tag/tag-type</li>
          <li>symmetrical/dot1q-tag-rewrite/push-tags/outer-tag/vlan-id</li>
          <li>symmetrical/dot1q-tag-rewrite/push-tags/second-tag/tag-type</li>
          <li>symmetrical/dot1q-tag-rewrite/push-tags/second-tag/vlan-id</li>
          <li>asymmetrical/ingress/dot1q-tag-rewrite/pop-tags</li>
          <li>asymmetrical/ingress/dot1q-tag-rewrite/push-tags/outer-tag/tag-type</li>
          <li>asymmetrical/ingress/dot1q-tag-rewrite/push-tags/outer-tag/vlan-id</li>
          <li>asymmetrical/ingress/dot1q-tag-rewrite/push-tags/second-tag/tag-type</li>
          <li>asymmetrical/ingress/dot1q-tag-rewrite/push-tags/second-tag/vlan-id</li>
          <li>asymmetrical/egress/dot1q-tag-rewrite/pop-tags</li>
          <li>asymmetrical/egress/dot1q-tag-rewrite/push-tags/outer-tag/tag-type</li>
          <li>asymmetrical/egress/dot1q-tag-rewrite/push-tags/outer-tag/vlan-id</li>
          <li>asymmetrical/egress/dot1q-tag-rewrite/push-tags/second-tag/tag-type</li>
          <li>asymmetrical/egress/dot1q-tag-rewrite/push-tags/second-tag/vlan-id</li>
        </ul>
        <t>Nodes in the flexible-encapsulation YANG module that are
          concerned with the VLAN tags to use for traffic sourced from the
          network element could cause protocol sessions (such as CFM) to fail if
          they are added, modified or deleted. The nodes, all under the subtree
          /interfaces/interface/flexible-encapsulation/local-traffic-default-encaps
          that are sensitive to this are:
        </t>
        <ul spacing="normal">
          <li>outer-tag/vlan-type</li>
          <li>outer-tag/vlan-id</li>
          <li>second-tag/vlan-type</li>
          <li>second-tag/vlan-id</li>
        </ul>
      </section>
    </section>
  </middle>
  <!--  *****BACK MATTER ***** -->
    <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
      <reference anchor="RFC3688" target="https://www.rfc-editor.org/info/rfc3688" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3688.xml">
          <front>
            <title>The IETF XML Registry</title>
            <author fullname="M. Mealling" initials="M." surname="Mealling"/>
            <date month="January" year="2004"/>
            <abstract>
              <t>This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="81"/>
          <seriesInfo name="RFC" value="3688"/>
          <seriesInfo name="DOI" value="10.17487/RFC3688"/>
        </reference>
        <reference anchor="RFC6020" target="https://www.rfc-editor.org/info/rfc6020" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6020.xml">
          <front>
            <title>YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)</title>
            <author fullname="M. Bjorklund" initials="M." role="editor" surname="Bjorklund"/>
            <date month="October" year="2010"/>
            <abstract>
              <t>YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6020"/>
          <seriesInfo name="DOI" value="10.17487/RFC6020"/>
        </reference>
        <reference anchor="RFC7950" target="https://www.rfc-editor.org/info/rfc7950" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7950.xml">
          <front>
            <title>The YANG 1.1 Data Modeling Language</title>
            <author fullname="M. Bjorklund" initials="M." role="editor" surname="Bjorklund"/>
            <date month="August" year="2016"/>
            <abstract>
              <t>YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols.  This document describes the syntax and semantics of version 1.1 of the YANG language.  YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification.  There are a small number of backward incompatibilities from YANG version 1.  This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7950"/>
          <seriesInfo name="DOI" value="10.17487/RFC7950"/>
        </reference>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized.  This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC8343" target="https://www.rfc-editor.org/info/rfc8343" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8343.xml">
          <front>
            <title>A YANG Data Model for Interface Management</title>
            <author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
            <date month="March" year="2018"/>
            <abstract>
              <t>This document defines a YANG data model for the management of network interfaces. It is expected that interface-type-specific data models augment the generic interfaces data model defined in this document. The data model includes definitions for configuration and system state (status information and counters for the collection of statistics).</t>
              <t>The YANG data model in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342.</t>
              <t>This document obsoletes RFC 7223.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8343"/>
          <seriesInfo name="DOI" value="10.17487/RFC8343"/>
        </reference>
        <reference anchor="RFC7224" target="https://www.rfc-editor.org/info/rfc7224" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7224.xml">
          <front>
            <title>IANA Interface Type YANG Module</title>
            <author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
            <date month="May" year="2014"/>
            <abstract>
              <t>This document defines the initial version of the iana-if-type YANG module.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7224"/>
          <seriesInfo name="DOI" value="10.17487/RFC7224"/>
        </reference>
        <reference anchor="RFC8344" target="https://www.rfc-editor.org/info/rfc8344" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8344.xml">
          <front>
            <title>A YANG Data Model for IP Management</title>
            <author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
            <date month="March" year="2018"/>
            <abstract>
              <t>This document defines a YANG data model for management of IP implementations. The data model includes configuration and system state.</t>
              <t>The YANG data model in this document conforms to the Network Management Datastore Architecture defined in RFC 8342.</t>
              <t>This document obsoletes RFC 7277.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8344"/>
          <seriesInfo name="DOI" value="10.17487/RFC8344"/>
        </reference>
        <reference anchor="I-D.ietf-netmod-intf-ext-yang" target="https://www.ietf.org/archive/id/draft-ietf-netmod-intf-ext-yang-10.txt" xml:base="https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-netmod-intf-ext-yang.xml">
          <front>
            <title>Common Interface Extension YANG Data Models</title>
            <author fullname="Robert Wilton">
              <organization>Cisco Systems</organization>
            </author>
            <author fullname="David Ball">
              <organization>Cisco Systems</organization>
            </author>
            <author fullname="Tapraj Singh">
              <organization>Cisco Systems</organization>
            </author>
            <author fullname="Selvakumar Sivaraj">
              <organization>Juniper Networks</organization>
            </author>
            <date day="29" month="July" year="2020"/>
            <abstract>
              <t>This document defines two YANG modules that augment the Interfaces data model defined in the "YANG Data Model for Interface Management" with additional configuration and operational data nodes to support common lower layer interface properties, such as interface MTU. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA) defined in RFC 8342.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-netmod-intf-ext-yang-10"/>
        </reference>
        <reference anchor="IEEE802.1Qcp-2018">
          <front>
            <title>IEEE Std 802.1Qcp-2018: IEEE Standard for
                    Local and metropolitan area networks -- Bridges
                    and Bridged Networks -- Amendment 30: YANG Data
                    Model</title>
            <author initials="M" surname="Holness">
              <organization>IEEE 802.1 WG</organization>
            </author>
            <date year="2018"/>
          </front>
        </reference>
      </references>
      <references>
        <name>Informative References</name>
        <!-- Here we use entities that we defined at the beginning. -->
            <!-- &RFC2629;
      &RFC3552; -->
      <reference anchor="RFC6241" target="https://www.rfc-editor.org/info/rfc6241" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6241.xml">
          <front>
            <title>Network Configuration Protocol (NETCONF)</title>
            <author fullname="R. Enns" initials="R." role="editor" surname="Enns"/>
            <author fullname="M. Bjorklund" initials="M." role="editor" surname="Bjorklund"/>
            <author fullname="J. Schoenwaelder" initials="J." role="editor" surname="Schoenwaelder"/>
            <author fullname="A. Bierman" initials="A." role="editor" surname="Bierman"/>
            <date month="June" year="2011"/>
            <abstract>
              <t>The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices.  It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages.  The NETCONF protocol operations are realized as remote procedure calls (RPCs).  This document obsoletes RFC 4741. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6241"/>
          <seriesInfo name="DOI" value="10.17487/RFC6241"/>
        </reference>
        <reference anchor="RFC6242" target="https://www.rfc-editor.org/info/rfc6242" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6242.xml">
          <front>
            <title>Using the NETCONF Protocol over Secure Shell (SSH)</title>
            <author fullname="M. Wasserman" initials="M." surname="Wasserman"/>
            <date month="June" year="2011"/>
            <abstract>
              <t>This document describes a method for invoking and running the Network Configuration Protocol (NETCONF) within a Secure Shell (SSH) session as an SSH subsystem.  This document obsoletes RFC 4742. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6242"/>
          <seriesInfo name="DOI" value="10.17487/RFC6242"/>
        </reference>
        <reference anchor="RFC6536" target="https://www.rfc-editor.org/info/rfc6536" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6536.xml">
          <front>
            <title>Network Configuration Protocol (NETCONF) Access Control Model</title>
            <author fullname="A. Bierman" initials="A." surname="Bierman"/>
            <author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
            <date month="March" year="2012"/>
            <abstract>
              <t>The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability.  There is a need for standard mechanisms to restrict NETCONF protocol access for particular users to a pre-configured subset of all available NETCONF protocol operations and content.  This document defines such an access control model. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6536"/>
          <seriesInfo name="DOI" value="10.17487/RFC6536"/>
        </reference>
        <reference anchor="RFC8340" target="https://www.rfc-editor.org/info/rfc8340" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8340.xml">
          <front>
            <title>YANG Tree Diagrams</title>
            <author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
            <author fullname="L. Berger" initials="L." role="editor" surname="Berger"/>
            <date month="March" year="2018"/>
            <abstract>
              <t>This document captures the current syntax used in YANG module tree diagrams.  The purpose of this document is to provide a single location for this definition.  This syntax may be updated from time to time based on the evolution of the YANG language.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="215"/>
          <seriesInfo name="RFC" value="8340"/>
          <seriesInfo name="DOI" value="10.17487/RFC8340"/>
        </reference>
        <reference anchor="RFC2460" target="https://www.rfc-editor.org/info/rfc2460" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2460.xml">
          <front>
            <title>Internet Protocol, Version 6 (IPv6) Specification</title>
            <author fullname="S. Deering" initials="S." surname="Deering"/>
            <author fullname="R. Hinden" initials="R." surname="Hinden"/>
            <date month="December" year="1998"/>
            <abstract>
              <t>This document specifies version 6 of the Internet Protocol (IPv6), also sometimes referred to as IP Next Generation or IPng. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2460"/>
          <seriesInfo name="DOI" value="10.17487/RFC2460"/>
        </reference>
        <reference anchor="RFC4448" target="https://www.rfc-editor.org/info/rfc4448" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4448.xml">
          <front>
            <title>Encapsulation Methods for Transport of Ethernet over MPLS Networks</title>
            <author fullname="L. Martini" initials="L." role="editor" surname="Martini"/>
            <author fullname="E. Rosen" initials="E." surname="Rosen"/>
            <author fullname="N. El-Aawar" initials="N." surname="El-Aawar"/>
            <author fullname="G. Heron" initials="G." surname="Heron"/>
            <date month="April" year="2006"/>
            <abstract>
              <t>An Ethernet pseudowire (PW) is used to carry Ethernet/802.3 Protocol Data Units (PDUs) over an MPLS network.  This enables service providers to offer "emulated" Ethernet services over existing MPLS networks.  This document specifies the encapsulation of Ethernet/802.3 PDUs within a pseudowire.  It also specifies the procedures for using a PW to provide a "point-to-point Ethernet" service. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4448"/>
          <seriesInfo name="DOI" value="10.17487/RFC4448"/>
        </reference>
        <reference anchor="RFC4761" target="https://www.rfc-editor.org/info/rfc4761" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4761.xml">
          <front>
            <title>Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling</title>
            <author fullname="K. Kompella" initials="K." role="editor" surname="Kompella"/>
            <author fullname="Y. Rekhter" initials="Y." role="editor" surname="Rekhter"/>
            <date month="January" year="2007"/>
            <abstract>
              <t>Virtual Private LAN Service (VPLS), also known as Transparent LAN Service and Virtual Private Switched Network service, is a useful Service Provider offering. The service offers a Layer 2 Virtual Private Network (VPN); however, in the case of VPLS, the customers in the VPN are connected by a multipoint Ethernet LAN, in contrast to the usual Layer 2 VPNs, which are point-to-point in nature.</t>
              <t>This document describes the functions required to offer VPLS, a mechanism for signaling a VPLS, and rules for forwarding VPLS frames across a packet switched network. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4761"/>
          <seriesInfo name="DOI" value="10.17487/RFC4761"/>
        </reference>
        <reference anchor="RFC4762" target="https://www.rfc-editor.org/info/rfc4762" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4762.xml">
          <front>
            <title>Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling</title>
            <author fullname="M. Lasserre" initials="M." role="editor" surname="Lasserre"/>
            <author fullname="V. Kompella" initials="V." role="editor" surname="Kompella"/>
            <date month="January" year="2007"/>
            <abstract>
              <t>This document describes a Virtual Private LAN Service (VPLS) solution using pseudowires, a service previously implemented over other tunneling technologies and known as Transparent LAN Services (TLS). A VPLS creates an emulated LAN segment for a given set of users; i.e., it creates a Layer 2 broadcast domain that is fully capable of learning and forwarding on Ethernet MAC addresses and that is closed to a given set of users. Multiple VPLS services can be supported from a single Provider Edge (PE) node.</t>
              <t>This document describes the control plane functions of signaling pseudowire labels using Label Distribution Protocol (LDP), extending RFC 4447. It is agnostic to discovery protocols. The data plane functions of forwarding are also described, focusing in particular on the learning of MAC addresses. The encapsulation of VPLS packets is described by RFC 4448. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4762"/>
          <seriesInfo name="DOI" value="10.17487/RFC4762"/>
        </reference>
        <reference anchor="I-D.ietf-bess-l2vpn-yang" target="https://www.ietf.org/archive/id/draft-ietf-bess-l2vpn-yang-10.txt" xml:base="https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-bess-l2vpn-yang.xml">
          <front>
            <title>YANG Data Model for MPLS-based L2VPN</title>
            <author fullname="Himanshu Shah">
              <organization>Ciena Corporation</organization>
            </author>
            <author fullname="Patrice Brissette">
              <organization>Cisco Systems</organization>
            </author>
            <author fullname="Ing-When Chen">
              <organization>The MITRE Corporation</organization>
            </author>
            <author fullname="Iftekar Hussain">
              <organization>Infinera Corporation</organization>
            </author>
            <author fullname="Bin Wen">
              <organization>Comcast</organization>
            </author>
            <author fullname="Kishore Tiruveedhula">
              <organization>Juniper Networks</organization>
            </author>
            <date day="2" month="July" year="2019"/>
            <abstract>
              <t>This document describes a YANG data model for Layer 2 VPN (L2VPN) services over MPLS networks. These services include point-to-point Virtual Private Wire Service (VPWS) and multipoint Virtual Private LAN service (VPLS) that uses LDP and BGP signaled Pseudowires. It is expected that this model will be used by the management tools run by the network operators in order to manage and monitor the network resources that they use to deliver L2VPN services. This document also describes the YANG data model for the Pseudowires. The independent definition of the Pseudowires facilitates its use in Ethernet Segment and EVPN data models defined in separate document.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-bess-l2vpn-yang-10"/>
        </reference>
      </references>
    </references>
    <section anchor="comparison" numbered="true" toc="default">
      <name>Comparison with the IEEE 802.1Q Configuration Model</name>
      <t>In addition to the sub-interface based YANG model proposed here,
          the IEEE 802.1Q working group has developed a YANG model for the
          configuration of 802.1Q VLANs.  This raises the valid question as to
          whether the models overlap and whether it is necessary or beneficial
          to have two different models for superficially similar constructs.
          This section aims to answer that question by summarizing and comparing
          the two models.</t>
      <section numbered="true" toc="default">
        <name>Sub-interface based configuration model overview</name>
        <t>The key features of the sub-interface based configuration model
            can be summarized as:
        </t>
        <ul spacing="normal">
          <li>The model is primarily designed to enable layer 2 and layer 3
              services on Ethernet interfaces that can be defined in a very
              flexible way to meet the varied requirements of service
              providers.</li>
          <li>Traffic is classified from an Ethernet-like interface to
	      sub-interfaces based on fields in the layer 2 header. This is
	      often based on VLAN Ids contained in the frame, but the model is
	      extensible to other arbitrary fields in the frame header.</li>
          <li>Sub-interfaces are just a type of if:interface and hence
	      support any feature configuration YANG models that can be applied
	      generally to interfaces. For example, QoS or ACL models that
	      reference if:interface can be applied to the sub-interfaces, or
	      the sub-interface can be used as an Access Circuit in L2VPN or
	      L3VPN models that reference if:interface.</li>
          <li>In the sub-interface based configuration model, the
	      classification of traffic arriving on an interface to a given
	      sub-interface, based on fields in the layer 2 header, is
	      completely independent of how the traffic is forwarded. The
	      sub-interface can be referenced (via references to if:interface)
	      by other models that specify how traffic is forwarded; thus
	      sub-interfaces can support multiple different forwarding
	      paradigms, including but not limited to: layer 3 (IPv4/IPv6),
	      layer 2 pseudowires (over MPLS or IP), VPLS instances, EVPN
	      instance.</li>
          <li>The model is flexible in the scope of the VLAN Identifier
	      space.  I.e. by default VLAN Ids can be scoped locally to a single
	      Ethernet-like trunk interface, but the scope is determined by the
	      forwarding paradigm that is used.</li>
        </ul>
      </section>
      <section numbered="true" toc="default">
        <name>IEEE 802.1Q Bridge Configuration Model Overview</name>
        <t>The key features of the IEEE 802.1Q bridge configuration model
            can be summarized as:
        </t>
        <ul spacing="normal">
          <li>Each VLAN bridge component has a set of Ethernet interfaces
              that are members of that bridge. Sub-interfaces are not used, nor
              required in the 802.1Q bridge model.</li>
          <li>Within a VLAN bridge component, the VLAN tag in the packet is
	      used, along with the destination MAC address, to determine how to
	      forward the packet. Other forwarding paradigms are not supported
	      by the 802.1Q model.</li>
          <li>Classification of traffic to a VLAN bridge component is based
	      only on the Ethernet interface that it arrived on.</li>
          <li>VLAN Identifiers are scoped to a VLAN bridge component. Often
	      devices only support a single bridge component and hence VLANs are
	      scoped globally within the device.</li>
          <li>Feature configuration is specified in the context of the
	      bridge, or particular VLANs on a bridge.</li>
        </ul>
      </section>
      <section numbered="true" toc="default">
        <name>Possible Overlap Between the Two Models</name>
        <t>Both models can be used for configuring similar basic layer 2
            forwarding topologies. The 802.1Q bridge configuration model is
            optimised for configuring Virtual LANs that span across enterprises
            and data centers.</t>
        <t>The sub-interface model can also be used for configuring
	    equivalent Virtual LAN networks that span across enterprises and
	    data centers, but often requires more configuration to be able to
	    configure the equivalent constructs to the 802.1Q bridge model.</t>
        <t>The sub-interface model really excels when implementing flexible
	    L2 and L3 services, where those services may be handled on the same
	    physical interface, and where the VLAN Identifier is being solely
	    used to identify the customer or service that is being provided
	    rather than a Virtual LAN.  The sub-interface model provides more
	    flexibility as to how traffic can be classified, how features can be
	    applied to traffic streams, and how the traffic is to be
	    forwarded.</t>
        <t>Conversely, the 802.1Q bridge model can also be use to implement
	    L2 services in some scenarios, but only if the forwarding paradigm
	    being used to implement the service is the native Ethernet
	    forwarding specified in 802.1Q - other forwarding paradigms such as
	    pseudowires or VPLS are not supported. The 802.1Q bridge model does
	    not implement L3 services at all, although this can be partly
	    mitigated by using a virtual L3 interface construct that is a
	    separate logical Ethernet-like interface which is a member of the
	    bridge.</t>
        <t>In conclusion, it is valid for both of these models to exist
	    since they have different deployment scenarios for which they are
	    optimized.  Devices may choose which of the models (or both) to
	    implement depending on what functionality the device is being
	    designed for.</t>
      </section>
    </section>
    <!--    <section anchor="app-additional" title="Additional Stuff">
      <t>This becomes an Appendix.</t>
    </section>-->
        <!-- Change Log

v00 2015-03-02  RGW   Initial version
                      -->
    </back>
</rfc>