Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 8466

A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service Delivery

Pages: 158
Proposed Standard
Errata
Part 5 of 8 – Pages 62 to 82
First   Prev   Next

Top   ToC   RFC8466 - Page 62   prevText

5.14. Enhanced VPN Features

5.14.1. Carriers' Carriers

In the case of Carriers' Carriers (CsC) [RFC8299], a customer may want to build an MPLS service using an L2VPN to carry its traffic. LAN customer1 | | CE1 | | ------------- (vrf_cust1) CE1_ISP1 | ISP1 POP | MPLS link | ------------- | (vrf ISP1) PE1 (...) Provider backbone PE2 (vrf ISP1) | | ------------ | | MPLS link | ISP1 POP CE2_ISP1 (vrf_cust1) | ------------ | CE2 | LAN customer1 Figure 21: MPLS Service Using an L2VPN to Carry Traffic In Figure 21, ISP1 resells an L2VPN service but has no core network infrastructure between its POPs. ISP1 uses an L2VPN as the core network infrastructure (belonging to another provider) between its POPs.
Top   ToC   RFC8466 - Page 63
   In order to support CsC, the VPN service must indicate MPLS support
   by setting the "carrierscarrier" leaf to "true" in the vpn-service
   list.  The link between CE1_ISP1/PE1 and CE2_ISP1/PE2 must also run
   an MPLS signaling protocol.  This configuration is done at the site
   level.

   In this model, LDP or BGP can be used as the MPLS signaling protocol.
   In the case of LDP, an IGP routing protocol MUST also be activated.
   In the case of BGP signaling, BGP MUST also be configured as the
   routing protocol.

   If CsC is enabled, the requested "svc-mtu" leaf will refer to the
   MPLS MTU and not to the link MTU.

5.15. External ID References

The service model sometimes refers to external information through identifiers. As an example, to order cloud access to a particular Cloud Service Provider (CSP), the model uses an identifier to refer to the targeted CSP. If a customer is directly using this service model as an API (through RESTCONF or NETCONF, for example) to order a particular service, the SP should provide a list of authorized identifiers. In the case of cloud access, the SP will provide the associated identifiers for each available CSP. The same applies to other identifiers, such as qos-profile. As a usage example, the remote-carrier-name setting is used in the NNI case because it should be known by the current L2VPN SP to which it is connecting, while the cloud-identifier setting should be known by both the current L2VPN SP and the customer because it is applied to the public cloud or Internet access. How an SP provides the meanings of those identifiers to the customer is out of scope for this document.
Top   ToC   RFC8466 - Page 64

5.16. Defining NNIs and Inter-AS Support

An Autonomous System (AS) is a single network or group of networks that are controlled by a common system administration group and that use a single, clearly defined routing protocol. In some cases, VPNs need to span different ASes in different geographical areas or span different SPs. The connection between ASes is established by the SPs and is seamless to the customer. Examples include: o A partnership between SPs (e.g., carrier, cloud) to extend their VPN services seamlessly. o An internal administrative boundary within a single SP (e.g., backhaul versus core versus data center). NNIs have to be defined to extend the VPNs across multiple ASes. [RFC4761] defines multiple flavors of VPN NNI implementations (e.g., VPLSs). Each implementation has pros and cons; this topic is outside the scope of this document. For example, in an inter-AS option A (two ASes), AS Border Router (ASBR) peers are connected by multiple interfaces with at least one of those interfaces spanning the two ASes while being present in the same VPN. In order for these ASBRs to signal label blocks, they associate each interface with a MAC-VRF (VSI) (Section 2) and a BGP session. As a result, traffic between devices in the back-to-back VPLS is Ethernet. In this scenario, the VPNs are isolated from each other, and because the traffic is Ethernet, QoS mechanisms that operate on Ethernet traffic can be applied to achieve customer SLAs.
Top   ToC   RFC8466 - Page 65
      --------                 --------------              -----------
     /        \               /              \            /           \
    | Cloud    |             |                |          |             |
    | Provider |-----NNI-----|                |----NNI---| Data Center |
    |  #1      |             |                |          |             |
     \        /              |                |           \           /
      --------               |                |            -----------
                             |                |
      --------               |   My network   |           -----------
     /        \              |                |          /           \
    | Cloud    |             |                |         |             |
    | Provider |-----NNI-----|                |---NNI---|  L2VPN      |
    |  #2      |             |                |         |  Partner    |
     \        /              |                |         |             |
      --------               |                |         |             |
                              \              /          |             |
                               --------------            \           /
                                     |                    -----------
                                     |
                                    NNI
                                     |
                                     |
                             -------------------
                            /                   \
                           |                     |
                           |                     |
                           |                     |
                           |     L2VPN Partner   |
                           |                     |
                            \                   /
                             -------------------

                  Figure 22: SP Network with Several NNIs

   Figure 22 illustrates an SP network called "My network" that has
   several NNIs.  This network uses NNIs to:

   o  increase its footprint by relying on L2VPN partners.

   o  connect its own data-center services to the customer L2VPN.

   o  enable the customer to access its private resources located in a
      private cloud owned by some CSPs.
Top   ToC   RFC8466 - Page 66

5.16.1. Defining an NNI with the Option A Flavor

AS A AS B ------------------- ------------------- / \ / \ | | | | | ++++++++ Inter-AS link +++++++++ | | + +_______________+ + | | +(MAC-VRF1)--(VPN1)--(MAC-VRF1)+ | | + + + + | | + ASBR + + ASBR + | | + + + + | | +(MAC-VRF2)--(VPN2)--(MAC-VRF2)+ | | + +_______________+ + | | ++++++++ +++++++++ | | | | | | | | | | | | | | ++++++++ Inter-AS link +++++++++ | | + +_______________+ + | | +(MAC-VRF1)--(VPN1)--(MAC-VRF1)+ | | + + + + | | + ASBR + + ASBR + | | + + + + | | +(MAC-VRF2)--(VPN2)--(MAC-VRF2)+ | | + +_______________+ + | | ++++++++ +++++++++ | | | | | | | | | \ / \ / ------------------- ------------------- Figure 23: NNI Defined with the Option A Flavor: Example 1 In option A, the two ASes are connected to each other with physical links on ASBRs. For resiliency purposes, there may be multiple physical connections between the ASes. A VPN connection -- physical or logical (on top of physical) -- is created for each VPN that needs to cross the AS boundary, thus providing a back-to-back VPLS model. From a service model's perspective, this VPN connection can be seen as a site. Let's say that AS B wants to extend some VPN connections for VPN C on AS A. The administrator of AS B can use this service model to order a site on AS A. All connection scenarios could be realized using the features of the current model. As an example, Figure 23 shows two physical connections that have logical connections per VPN overlaid on them. This could be seen as a multi-VPN scenario. Also, the administrator of AS B will be able to
Top   ToC   RFC8466 - Page 67
   choose the appropriate routing protocol (e.g., External BGP (EBGP))
   to dynamically exchange routes between ASes.

   This document assumes that the option A NNI flavor SHOULD reuse the
   existing VPN site modeling.

   Figure 24 illustrates an example where a customer wants its CSP A to
   attach its virtual network N to an existing L2VPN (VPN1) that it has
   from L2VPN SP B.

               CSP A                           L2VPN SP B
        -----------------                     -----------
       /                 \                   /           \
      |       |           |                 |             |
      |  VM --|       ++++++++     NNI    ++++++++++      |--- VPN1
      |       |       +      +____________+        +      |   Site 1
      |       |-------+(MAC-VRF1)-(VPN1)-(MAC-VRF1)+      |
      |       |       +      +            +        +      |
      |       |       + ASBR +            + ASBR   +      |
      |       |       +      +____________+        +      |
      |       |       ++++++++            ++++++++++      |
      |  VM --|           |                 |             |--- VPN1
      |       |Virtual    |                 |             |   Site 2
      |       |Network    |                 |             |
      |  VM --|           |                 |             |--- VPN1
      |       |           |                 |             |   Site 3
       \                 /                   \           /
        -----------------                     -----------
                                                   |
                                                   |
                                                  VPN1
                                                 Site 4

      VM = Virtual Machine

        Figure 24: NNI Defined with the Option A Flavor: Example 2

   To create the VPN connectivity, the CSP or the customer may use the
   L2SM that SP B exposes.  We could consider that, as the NNI is
   shared, the physical connection (bearer) between CSP A and SP B
   already exists.  CSP A may request through a service model the
   creation of a new site with a single site-network-access
   (single-homing is used in Figure 24).  As a placement constraint, CSP
   A may use the existing bearer reference it has from SP A to force the
   placement of the VPN NNI on the existing link.  The XML below
   illustrates a possible configuration request to SP B:
Top   ToC   RFC8466 - Page 68
   <?xml version="1.0"?>
   <l2vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc">
    <vpn-profiles>
     <valid-provider-identifiers>
      <qos-profile-identifier>
       <id>GOLD</id>
      </qos-profile-identifier>
      <qos-profile-identifier>
       <id>PLATINUM</id>
      </qos-profile-identifier>
     </valid-provider-identifiers>
    </vpn-profiles>
    <vpn-services>
     <vpn-service>
      <vpn-id>VPN1</vpn-id>
      <ce-vlan-preservation>true</ce-vlan-preservation>
      <ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
     </vpn-service>
    </vpn-services>
    <sites>
         <site>
             <site-id>CSP_A_attachment</site-id>
              <locations>
               <location>
                 <location-id>NY1</location-id>
                 <city>NY</city>
                 <country-code>US</country-code>
              </location>
              </locations>
             <site-vpn-flavor>site-vpn-flavor-nni</site-vpn-flavor>
               <site-network-accesses>
                 <site-network-access>
                  <network-access-id>CSP_A_VN1</network-access-id>
                          <connection>
                          <encapsulation-type>vlan</encapsulation-type>
                          <eth-inf-type>tagged</eth-inf-type>
                           <tagged-interface>
                            <tagged-inf-type>dot1q</tagged-inf-type>
                            <dot1q-vlan-tagged>
                             <cvlan-id>17</cvlan-id>
                           </dot1q-vlan-tagged>
                           </tagged-interface>
                          </connection>
                            <service>
                              <svc-bandwidth>
                                <bandwidth>
                                 <direction>input-bw</direction>
                                  <type>bw-per-cos</type>
Top   ToC   RFC8466 - Page 69
                                   <cir>450000000</cir>
                                   <cbs>20000000</cbs>
                                   <eir>1000000000</eir>
                                   <ebs>200000000</ebs>
                                </bandwidth>
                              </svc-bandwidth>
                              <carrierscarrier>
                                <signaling-type>bgp</signaling-type>
                             </carrierscarrier>
                            </service>
                           <vpn-attachment>
                              <vpn-id>12456487</vpn-id>
                              <site-role>spoke-role</site-role>
                            </vpn-attachment>
                </site-network-access>
             </site-network-accesses>
             <management>
              <type>customer-managed</type>
             </management>
         </site>
    </sites>
   </l2vpn-svc>

   The case described above is different from a scenario using the
   cloud-accesses container, as the cloud-access provides a public cloud
   access while this example enables access to private resources located
   in a CSP network.
Top   ToC   RFC8466 - Page 70

5.16.2. Defining an NNI with the Option B Flavor

AS A AS B ------------------- ------------------- / \ / \ | | | | | ++++++++ Inter-AS link ++++++++ | | + +_______________+ + | | + + + + | | + ASBR +<---MP-BGP---->+ ASBR + | | + + + + | | + +_______________+ + | | ++++++++ ++++++++ | | | | | | | | | | | | | | ++++++++ Inter-AS link ++++++++ | | + +_______________+ + | | + + + + | | + ASBR +<---MP-BGP---->+ ASBR + | | + + + + | | + +_______________+ + | | ++++++++ ++++++++ | | | | | | | | | \ / \ / ------------------- ------------------- Figure 25: NNI Defined with the Option B Flavor: Example 1 In option B, the two ASes are connected to each other with physical links on ASBRs. For resiliency purposes, there may be multiple physical connections between the ASes. The VPN "connection" between ASes is done by exchanging VPN routes through MP-BGP [RFC4761]. There are multiple flavors of implementations of such an NNI. For example: 1. The NNI is internal to the provider and is situated between a backbone and a data center. There is enough trust between the domains to not filter the VPN routes. So, all the VPN routes are exchanged. RT filtering may be implemented to save some unnecessary route states. 2. The NNI is used between providers that agreed to exchange VPN routes for specific RTs only. Each provider is authorized to use the RT values from the other provider.
Top   ToC   RFC8466 - Page 71
   3.  The NNI is used between providers that agreed to exchange VPN
       routes for specific RTs only.  Each provider has its own RT
       scheme.  So, a customer spanning the two networks will have
       different RTs in each network for a particular VPN.

   Case 1 does not require any service modeling, as the protocol enables
   the dynamic exchange of necessary VPN routes.

   Case 2 requires that an RT-filtering policy on ASBRs be maintained.
   From a service-modeling point of view, it is necessary to agree on
   the list of RTs to authorize.

   In Case 3, both ASes need to agree on the VPN RT to exchange, as well
   as how to map a VPN RT from AS A to the corresponding RT in AS B (and
   vice versa).

   Those modelings are currently out of scope for this document.

           CSP A                               L3VPN SP B
      -----------------                    ------------------
     /                 \                  /                  \
    |       |           |                |                    |
    |  VM --|       ++++++++   NNI    ++++++++                |--- VPN1
    |       |       +      +__________+      +                |   Site 1
    |       |-------+      +          +      +                |
    |       |       + ASBR +<-MP-BGP->+ ASBR +                |
    |       |       +      +__________+      +                |
    |       |       ++++++++          ++++++++                |
    |  VM --|           |                |                    |--- VPN1
    |       |Virtual    |                |                    |   Site 2
    |       |Network    |                |                    |
    |  VM --|           |                |                    |--- VPN1
    |       |           |                |                    |   Site 3
     \                 /                 |                    |
      -----------------                  |                    |
                                          \                  /
                                           ------------------
                                                    |
                                                    |
                                                   VPN1
                                                  Site 4

      VM = Virtual Machine

        Figure 26: NNI Defined with the Option B Flavor: Example 2
Top   ToC   RFC8466 - Page 72
   Figure 26 shows an NNI connection between CSP A and SP network B.
   The SPs do not trust each other and use different RT allocation
   policies.  So, in terms of implementation, the customer VPN has a
   different RT in each network (RT A in CSP A and RT B in SP
   network B).  In order to connect the customer's virtual network in
   CSP A to the customer's L2VPN (VPN1) in SP network B, CSP A should
   request that SP network B open the customer VPN on the NNI (accept
   the appropriate RT).  Who does the RT translation depends on the
   agreement between the two SPs: SP B may permit CSP A to request VPN
   (RT) translation.
Top   ToC   RFC8466 - Page 73

5.16.3. Defining an NNI with the Option C Flavor

AS A AS B ------------------- ------------------- / \ / \ | | | | | | | | | | | | | ++++++++ Multihop EBGP ++++++++ | | + + + + | | + + + + | | + RGW +<----MP-BGP---->+ RGW + | | + + + + | | + + + + | | ++++++++ ++++++++ | | | | | | | | | | | | | | | | | | | | | | ++++++++ Inter-AS link ++++++++ | | + +_______________+ + | | + + + + | | + ASBR + + ASBR + | | + + + + | | + +_______________+ + | | ++++++++ ++++++++ | | | | | | | | | | | | | | ++++++++ Inter-AS link ++++++++ | | + +_______________+ + | | + + + + | | + ASBR + + ASBR + | | + + + + | | + +_______________+ + | | ++++++++ ++++++++ | | | | | | | | | \ / \ / ------------------- ------------------- Figure 27: NNI Defined with the Option C Flavor
Top   ToC   RFC8466 - Page 74
   From a VPN service's perspective, the option C NNI is very similar to
   option B, as an MP-BGP session is used to exchange VPN routes between
   the ASes.  The difference is that the forwarding plane and the
   control plane are on different nodes, so the MP-BGP session is
   multihop between routing gateway (RGW) nodes.  From a VPN service's
   point of view, modeling options B and C will be configured
   identically.

5.17. Applicability of L2SM in Inter-provider and Inter-domain Orchestration

In the case where the ASes belong to different providers, one might imagine that providers would like to have fewer signaling sessions crossing the AS boundary and that the entities that terminate the sessions could be restricted to a smaller set of devices. Two approaches can be taken: a. Construct inter-provider control connections to run only between the two border routers. b. Allow end-to-end, multi-segment connectivity to be constructed out of several connectivity segments, without maintaining an end-to-end control connection. Inter-provider control connections as described in approach (a) can be realized using the techniques provided in Section 5.16 (e.g., defining NNIs). Multi-segment connectivity as described in approach (b) can produce an inter-AS solution that more closely resembles scheme (b) in Section 10 of [RFC4364]. It may be realized using "stitching" of per-site connectivity and service segments at different domains, e.g., end-to-end connectivity between Site 1 and Site 3 spans multiple domains (e.g., metropolitan area networks) and can be constructed by stitching network access connectivity within Site 1 with SEG1, SEG3, and SEG4, and network access connectivity within Site 3 (as shown in Figure 28). The assumption is that the service orchestration component in Figure 3 should have visibility into the complete abstract topology and resource availability. This may rely on network planning.
Top   ToC   RFC8466 - Page 75
             ----------   ----------   ----------
            |          | |          | |          |
          +--+        +---+        +---+        +--+
    Site 1|PE|==SEG1==|   |==SEG3==|   |==SEG4==|PE|Site 3
          +--+        +---+        |   |        +--+
            |          | |         |   |         |  ----------
            |          | |         |   |         | |          |
          +--+        +---+        |   |        +---+        +--+
    Site 2|PE|==SEG2==|   |==SEG5==|   |==SEG6==|   |==SEG7==|PE|Site 4
          +--+        +---+        +---+        +---+        +--+
            |          | |          | |          | |          |
             ----------   ----------   ----------   ----------

     Figure 28: Example: Inter-provider and Inter-domain Orchestration

   Note that SEG1, SEG2, SEG3, SEG4, SEG5, and SEG6 can also be regarded
   as network access connectivity within a site and can be created as a
   normal site using the L2SM.

   In Figure 28, we use BGP redistribution of L2VPN Network Layer
   Reachability Information (NLRI) instances from AS to neighboring AS.
   First, the PE routers use BGP to redistribute L2VPN NLRIs to either
   an ASBR or a route reflector of which an ASBR is a client.  The ASBR
   then uses BGP to redistribute those L2VPN NLRIs to an ASBR in another
   AS, which in turn distributes them to the PE routers in that AS, or
   perhaps to another ASBR that in turn distributes them, and so on.

   In this case, a PE can learn the address of an ASBR through which it
   could reach another PE to which it wishes to establish connectivity.
   That is, a local PE will receive a BGP advertisement containing an
   L2VPN NLRI corresponding to an L2VPN instance in which the local PE
   has some attached members.  The BGP next hop for that L2VPN NLRI will
   be an ASBR of the local AS.  Then, rather than building a control
   connection all the way to the remote PE, it builds one only to the
   ASBR.  A connectivity segment can now be established from the PE to
   the ASBR.  The ASBR in turn can establish connectivity to the ASBR of
   the next AS and then stitch that connectivity to the connectivity
   from the PE as described in [RFC6073].  Repeating the process at each
   ASBR leads to a sequence of connectivity segments that, when stitched
   together, connect the two PEs.

   Note that in the approach just described, the local PE may never
   learn the IP address of the remote PE.  It learns the L2VPN NLRI
   advertised by the remote PE, which need not contain the remote PE
   address, and it learns the IP address of the ASBR that is the BGP
   next hop for that NLRI.
Top   ToC   RFC8466 - Page 76
   When this approach is used for VPLS or for full-mesh VPWS, it leads
   to a full mesh of connectivity among the PEs, but it does not require
   a full mesh of control connections (LDP or L2TPv3 sessions).
   Instead, the control connections within a single AS run among all the
   PEs of that AS and the ASBRs of the AS.  A single control connection
   between the ASBRs of adjacent ASes can be used to support as many
   AS-to-AS connectivity segments as may be needed.

6. Interaction with Other YANG Modules

As explained in Section 4, this service model is not intended to configure network elements; rather, it is instantiated in a management system. The management system might follow modular design and comprise two different components: a. The component instantiating the service model (let's call it the service component). b. The component responsible for network element configuration (let's call it the configuration component). In some cases, when a split is needed between the behavior and functions that a customer requests and the technology that the network operator has available to deliver the service [RFC8309], a new component can be separated out of the service component (let's call it the control component). This component is responsible for network-centric operation and is aware of many features such as topology, technology, and operator policy. As an optional component, it can use the service model as input and is not required at all if the control component delegates its control operations to the configuration component. In Section 7, we provide an example of translation of service provisioning requests to router configuration lines as an illustration. In the YANG-based ecosystem, it is expected that NETCONF and YANG will be used between the configuration component and network elements to configure the requested service on those elements. In this framework, it is expected that YANG data models will be used to configure service components on network elements. There will be a strong relationship between the abstracted view provided by this service model and the detailed configuration view that will be provided by specific configuration models for network elements such
Top   ToC   RFC8466 - Page 77
   as those defined in [MPLS-L2VPN-YANG] and [EVPN-YANG].  Service
   components that would need configuration of network elements in
   support of the service model defined in this document include:

   o  Network instance definitions that include defined VPN policies.

   o  Physical interfaces.

   o  Ethernet-layer parameters (e.g., VLAN IDs).

   o  QoS: classification, profiles, etc.

   o  Support for Ethernet Service OAM.

7. Service Model Usage Example

As explained in Section 4, this service model is intended to be instantiated at a management layer and is not intended to be used directly on network elements. The management system serves as a central point of configuration of the overall service. This section provides an example of how a management system can use this model to configure an L2VPN service on network elements. This example provides a VPN service for three sites using point-to-point VPWS and a Hub-and-Spoke VPN service topology as shown in Figure 29. Load balancing is not considered in this case. Site 1 ............ : : P2P VPWS :Spoke Site:-----PE1--------------------------+ : : | Site 3 :..........: | ............ | : : PE3-----: Hub Site : Site 2 | : : ............ | :..........: : : P2P VPWS | :Spoke Site:-----PE2--------------------------+ : : :..........: Figure 29: Reference Network for Simple Example
Top   ToC   RFC8466 - Page 78
   The following XML describes the overall simplified service
   configuration of this VPN.

       <?xml version="1.0"?>
       <l2vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc">
         <vpn-services>
             <vpn-service>
              <vpn-id>12456487</vpn-id>
               <vpn-svc-type>vpws</vpn-svc-type>
               <svc-topo>hub-spoke</svc-topo>
               <ce-vlan-preservation>true</ce-vlan-preservation>
               <ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
              </vpn-service>
             <vpn-service>
               <vpn-id>12456488</vpn-id>
               <vpn-svc-type>vpws</vpn-svc-type>
               <svc-topo>hub-spoke</svc-topo>
               <ce-vlan-preservation>true</ce-vlan-preservation>
               <ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
              </vpn-service>
         </vpn-services>
       </l2vpn-svc>

   When receiving the request for provisioning the VPN service, the
   management system will internally (or through communication with
   another OSS component) allocate VPN RTs.  In this specific case, two
   RTs will be allocated (100:1 for Hubs and 100:2 for Spokes).  The
   output below describes the configuration of Spoke Site 1.

  <?xml version="1.0"?>
  <l2vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc">
   <vpn-services>
    <vpn-service>
     <vpn-id>12456487</vpn-id>
     <svc-topo>hub-spoke</svc-topo>
     <ce-vlan-preservation>true</ce-vlan-preservation>
     <ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
    </vpn-service>
   </vpn-services>
   <sites>
     <site>
        <site-id>Spoke_Site1</site-id>
           <locations>
             <location>
              <location-id>NY1</location-id>
              <city>NY</city>
              <country-code>US</country-code>
             </location>
Top   ToC   RFC8466 - Page 79
            </locations>
            <site-network-accesses>
               <site-network-access>
                  <network-access-id>Spoke_UNI-Site1</network-access-id>
                    <access-diversity>
                      <groups>
                        <group>
                          <group-id>20</group-id>
                        </group>
                      </groups>
                    </access-diversity>
                      <connection>
                       <encapsulation-type>vlan</encapsulation-type>
                        <tagged-interface>
                        <dot1q-vlan-tagged>
                          <cvlan-id>17</cvlan-id>
                        </dot1q-vlan-tagged>
                        </tagged-interface>
                        <l2cp-control>
                          <stp-rstp-mstp>tunnel</stp-rstp-mstp>
                          <lldp>true</lldp>
                        </l2cp-control>
                      </connection>
                      <service>
                        <svc-bandwidth>
                          <bandwidth>
                           <direction>input-bw</direction>
                            <type>bw-per-cos</type>
                             <cir>450000000</cir>
                             <cbs>20000000</cbs>
                             <eir>1000000000</eir>
                             <ebs>200000000</ebs>
                          </bandwidth>
                        </svc-bandwidth>
                        <carrierscarrier>
                         <signaling-type>bgp</signaling-type>
                        </carrierscarrier>
                     </service>
                      <vpn-attachment>
                        <vpn-id>12456487</vpn-id>
                        <site-role>spoke-role</site-role>
                      </vpn-attachment>
                    </site-network-access>
                  </site-network-accesses>
                  <management>
                    <type>provider-managed</type>
                  </management>
                </site>
Top   ToC   RFC8466 - Page 80
          </sites>
      </l2vpn-svc>

   When receiving the request for provisioning Spoke Site 1, the
   management system MUST allocate network resources for this site.  It
   MUST first determine the target network elements to provision the
   access and, in particular, the PE router (or possibly an aggregation
   switch).  As described in Sections 5.3.1 and 5.6, the management
   system SHOULD use the location information and MUST use the
   access-diversity constraint to find the appropriate PE.  In this
   case, we consider that Spoke Site 1 requires PE diversity with Hubs
   and that the management system will allocate PEs based on least
   distance.  Based on the location information, the management system
   finds the available PEs in the area closest to the customer and picks
   one that fits the access-diversity constraint.

   When the PE is chosen, the management system needs to allocate
   interface resources on the node.  One interface is selected from the
   PE's available pool of resources.  The management system can start
   provisioning the PE node using any means it wishes (e.g., NETCONF,
   CLI).  The management system will check to see if a VSI that fits its
   needs is already present.  If not, it will provision the VSI: the RD
   will come from the internal allocation policy model, and the RTs will
   come from the vpn-policy configuration of the site (i.e., the
   management system will allocate some RTs for the VPN).  As the site
   is a Spoke site (site-role), the management system knows which RTs
   must be imported and exported.  As the site is provider managed, some
   management RTs may also be added (100:5000).  Standard provider VPN
   policies MAY also be added in the configuration.

   Example of a generated PE configuration:

l2vpn vsi context one
  vpn id 12456487
     autodiscovery bgp signaling bgp
     ve id 1001     <---- identify the PE routers within the VPLS domain
     ve range 50    <---- VPLS Edge (VE) size
     route-distinguisher 100:3123234324
     route-target import 100:1
     route-target import 100:5000    <---- Standard SP configuration
     route-target export 100:2               for provider-managed CE
   !

   When the VSI has been provisioned, the management system can start
   configuring the access on the PE using the allocated interface
   information.  The tag or VLAN (e.g., service instance tag) is chosen
   by the management system.  One tag will be picked from an allocated
   subnet for the PE, and another will be used for the CE configuration.
Top   ToC   RFC8466 - Page 81
   LACP protocols will also be configured between the PE and the CE; in
   the case of the provider-managed model, the choice is left to the SP.
   This choice is independent of the LACP protocol chosen by the
   customer.

   Example of a generated PE configuration:

   !
   bridge-domain 1
    member Ethernet0/0 service-instance 100
    member vsi one
   !
   l2 router-id 198.51.100.1
   !
   l2 router-id 2001:db8::10:1/64
   !

   interface Ethernet0/0
    no ip address
    service instance 100 ethernet
   encapsulation dot1q 100
    !

   !
   router bgp 1
    bgp log-neighbor-changes
    neighbor 198.51.100.4 remote-as 1
    neighbor 198.51.100.4 update-source Loopback0
    !
    address-family l2vpn vpls
     neighbor 198.51.100.4 activate
     neighbor 198.51.100.4 send-community extended
     neighbor 198.51.100.4 suppress-signaling-protocol ldp
     neighbor 2001:db8::0a10:4 activate
     neighbor 2001:db8::0a10:4 send-community extended
    exit-address-family

   !
   interface vlan 100     <---- Associating the AC with
     no ip address                the MAC-VRF at the PE
     xconnect vsi PE1-VPLS-A
   !
   vlan 100
     state active
Top   ToC   RFC8466 - Page 82
   As the CE router is not reachable at this stage, the management
   system can produce a complete CE configuration that can be manually
   uploaded to the node (e.g., before sending the CE to the customer
   premises at the appropriate postal address, as described in
   Section 5.3.1).  The CE configuration will be built in the same way
   as the PE configuration is built.  Based on (1) the CE type
   (vendor/model) allocated to the customer and (2) bearer information,
   the management system knows which interface must be configured on the
   CE.  PE-CE link configuration is expected to be handled automatically
   using the SP's OSS, as both resources are managed internally.
   CE-to-LAN interface parameters, such as dot1Q tags, are derived from
   the Ethernet connection, taking into account how the management
   system distributes dot1Q tags between the PE and the CE within the
   subnet.  This will allow a plug'n'play configuration to be produced
   for the CE.

   Example of a generated CE configuration:

   interface Ethernet0/1
     switchport trunk allowed vlan none
     switchport mode trunk
     service instance 100 ethernet
     encapsulation default
     l2protocol forward cdp
     xconnect 203.0.113.1 100 encapsulation mpls
   !



(page 82 continued on part 6)

Next Section