RFC 8466
A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service Delivery
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.
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.
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.
-------- -------------- ----------- / \ / \ / \ | 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.
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
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:
<?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>
<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.
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.
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
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.
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
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.
---------- ---------- ---------- | | | | | | +--+ +---+ +---+ +--+ 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.
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
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
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>
</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>
</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.
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
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)
