RFC 8466
A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service Delivery
5.6. Deciding Where to Connect the Site
The management system will have to determine where to connect each site-network-access of a particular site to the provider network (e.g., PE or aggregation switch).
This model defines parameters and constraints that can influence the meshing of the site-network-access. The management system MUST honor all customer constraints, or, if a constraint is too strict and cannot be fulfilled, the management system MUST NOT provision the site and MUST provide the user with information regarding any constraints that could not be fulfilled. How this information is provided is out of scope for this document. Whether or not to relax the constraint would then be left up to the user. Parameters such as site location (see Section 5.6.2) and access type (see Section 5.6.3) affect the service placement that the management system applies. In addition to parameters and constraints, the management system's decision MAY be based on any other internal constraints that are left up to the SP, e.g., least load, distance.5.6.1. Constraint: Device
In the case of provider management or co-management, one or more devices have been ordered by the customer to a particular location that has already been configured. The customer may force a particular site-network-access to be connected on a particular device that it ordered. New York Site +------------------+ Site | +--------------+ |------------------------------------- | | Manhattan | | | | CE1********* (site-network-access#1) ****** | +--------------+ | | +--------------+ | | | Brooklyn | | | | CE2********* (site-network-access#2) ****** | +--------------+ | | |------------------------------------- +------------------+ Figure 18: Example of a Constraint Applied to a Device In Figure 18, site-network-access#1 is associated with CE1 in the service request. The SP must ensure the provisioning of this connection.
5.6.2. Constraint/Parameter: Site Location
The location information provided in this model MAY be used by a management system to determine the target PE to mesh the site (SP side). A particular location must be associated with each site network access when configuring it. The SP MUST honor the termination of the access on the location associated with the site network access (customer side). The "country-code" in the site location should be expressed as an ISO 3166 code and is similar to the "country" label defined in [RFC4119]. The site-network-access location is determined by the "location-flavor". In the case of a provider-managed or co-managed site, the user is expected to configure a "device-reference" (device case) that will bind the site-network-access to a particular device that the customer ordered. As each device is already associated with a particular location, in such a case the location information is retrieved from the device location. In the case of a customer-managed site, the user is expected to configure a "location-reference" (location case); this provides a reference to an existing configured location and will help with placement. POP#1 (New York) +---------+ | PE1 | Site 1 ---... | PE2 | (Atlantic City) | PE3 | +---------+ POP#2 (Washington) +---------+ | PE4 | | PE5 | | PE6 | +---------+ POP#3 (Philadelphia) +---------+ | PE7 | Site 2 CE#1---... | PE8 | (Reston) | PE9 | +---------+ Figure 19: Location Information for Sites In Figure 19, Site 1 is a customer-managed site with a location "L1", while Site 2 is a provider-managed site for which a CE (CE#1) was ordered. Site 2 is configured with "L2" as its location. When
configuring a site-network-access for Site 1, the user will need to reference location L1 so that the management system will know that the access will need to terminate on this location. Then, for distance reasons, this management system may mesh Site 1 on a PE in the Philadelphia POP. It may also take into account resources available on PEs to determine the exact target PE (e.g., least loaded). For Site 2, the user is expected to configure the site-network-access with a device-reference to CE#1 so that the management system will know that the access must terminate on the location of CE#1 and must be connected to CE#1. For placement of the SP side of the access connection, in the case of the nearest PE used, it may mesh Site 2 on the Washington POP.5.6.3. Constraint/Parameter: Access Type
The management system needs to elect the access media to connect the site to the customer (for example, xDSL, leased line, Ethernet backhaul). The customer may provide some parameters/constraints that will provide hints to the management system. The bearer container information SHOULD be the first piece of information considered when making this decision: o The "requested-type" parameter provides information about the media type that the customer would like to use. If the "strict" leaf is equal to "true", this MUST be considered a strict constraint so that the management system cannot connect the site with another media type. If the "strict" leaf is equal to "false" (default) and if the requested media type cannot be fulfilled, the management system can select another media type. The supported media types SHOULD be communicated by the SP to the customer via a mechanism that is out of scope for this document. o The "always-on" leaf defines a strict constraint: if set to "true", the management system MUST elect a media type that is "always-on" (e.g., this means no dial-in access type). o The "bearer-reference" parameter is used in cases where the customer has already ordered a network connection to the SP apart from the L2VPN site and wants to reuse this connection. The string used is an internal reference from the SP and describes the already-available connection. This is also a strict requirement that cannot be relaxed. How the reference is given to the customer is out of scope for this document, but as an example, when the customer ordered the bearer (through a process that is out of scope for this model), the SP may have provided the bearer reference that can be used for provisioning services on top.
Any other internal parameters from the SP can also be used. The management system MAY use other parameters, such as the requested "input svc-bandwidth" and "output svc-bandwidth", to help decide which access type to use.5.6.4. Constraint: Access Diversity
Each site-network-access may have one or more constraints that would drive the placement of the access. By default, the model assumes that there are no constraints, but allocation of a unique bearer per site-network-access is expected. In order to help with the different placement scenarios, a site-network-access may be tagged using one or multiple group identifiers. The group identifier is a string, so it can accommodate both explicit naming of a group of sites (e.g., "multihomed-set1") and the use of a numbered identifier (e.g., 12345678). The meaning of each group-id is local to each customer administrator, and the management system MUST ensure that different customers can use the same group-ids. One or more group-ids can also be defined at the site level; as a consequence, all site-network-accesses under the site MUST inherit the group-ids of the site to which they belong. When, in addition to the site group-ids some group-ids are defined at the site-network-access level, the management system MUST consider the union of all groups (site level and site-network-access level) for this particular site-network-access. For an already-configured site-network-access, each constraint MUST be expressed against a targeted set of site-network-accesses. This site-network-access (i.e., the already-configured site-network-access) MUST never be taken into account in the targeted set of site-network-accesses -- for example, "My site-network-access S must not be connected on the same POP as the site-network-accesses that are part of Group 10." The set of site-network-accesses against which the constraint is evaluated can be expressed as a list of groups, "all-other-accesses", or "all-other-groups". The all-other-accesses option means that the current site-network-access constraint MUST be evaluated against all the other site-network-accesses belonging to the current site. The all-other-groups option means that the constraint MUST be evaluated against all groups to which the current site-network-access does not belong. The current model defines multiple constraint-types: o pe-diverse: The current site-network-access MUST NOT be connected to the same PE as the targeted site-network-accesses.
o pop-diverse: The current site-network-access MUST NOT be connected
to the same POP as the targeted site-network-accesses.
o linecard-diverse: The current site-network-access MUST NOT be
connected to the same linecard as the targeted site-network-
accesses. Note that the customer can request linecard-diverse for
site-network-accesses, but the specific linecard identifier used
should not be exposed to the customer.
o bearer-diverse: The current site-network-access MUST NOT use
common bearer components compared to bearers used by the targeted
site-network-accesses. "bearer-diverse" provides some level of
diversity at the access level. As an example, two bearer-diverse
site-network-accesses must not use the same Digital Subscriber
Line Access Multiplexer (DSLAM), Broadband Access Switch (BAS), or
Layer 2 switch.
o same-pe: The current site-network-access MUST be connected to the
same PE as the targeted site-network-accesses.
o same-bearer: The current site-network-access MUST be connected
using the same bearer as the targeted site-network-accesses.
These constraint-types can be extended through augmentation. Each
constraint is expressed as "The site-network-access S must be
<constraint-type> (e.g., pe-diverse, pop-diverse) from these <target>
site-network-accesses."
The group-id used to target some site-network-accesses may be the
same as the one used by the current site-network-access. This eases
the configuration of scenarios where a group of site-network-access
points has a constraint between the access points in the group.
5.7. Route Distinguisher and Network Instance Allocation
The Route Distinguisher (RD) is a critical parameter of BGP-based
L2VPNs as described in [RFC4364] that provides the ability to
distinguish common addressing plans in different VPNs. As for Route
Targets (RTs), a management system is expected to allocate a MAC-VRF
on the target PE and an RD for that MAC-VRF; that RD MUST be unique
across all MAC-VRFs on the target PE.
If a MAC-VRF already exists on the target PE and the MAC-VRF fulfills
the connectivity constraints for the site, there is no need to
recreate another MAC-VRF, and the site MAY be meshed within the
existing MAC-VRF. How the management system checks to see if an
existing MAC-VRF fulfills the connectivity constraints for a site is
out of scope for this document.
If no such MAC-VRF exists on the target PE, the management system has to initiate the creation of a new MAC-VRF on the target PE and has to allocate a new RD for the new MAC-VRF. The management system MAY apply a per-VPN or per-MAC-VRF allocation policy for the RD, depending on the SP's policy. In a per-VPN allocation policy, all MAC-VRFs (dispatched on multiple PEs) within a VPN will share the same RD value. In a per-MAC-VRF model, all MAC-VRFs should always have a unique RD value. Some other allocation policies are also possible, and this document does not restrict the allocation policies to be used. The allocation of RDs MAY be done in the same way as RTs. The information provided in Section 5.2.2.1 could also be used in this scenario. Note that an SP MAY configure a target PE for an automated allocation of RDs. In this case, there will be no need for any backend system to allocate an RD value.5.8. Site-Network-Access Availability
A site may be multihomed, meaning that it has multiple site-network-access points. The placement constraints defined in Section 5.6 will help ensure physical diversity. When the site-network-accesses are placed on the network, a customer may want to use a particular routing policy on those accesses. The "site-network-access/availability" container defines parameters for site redundancy. The "access-priority" leaf defines a preference for a particular access. This preference is used to model load-balancing or primary/backup scenarios. The higher the access-priority value, the higher the preference will be. The "redundancy-mode" attribute is defined for a multihoming site and used to model single-active and active/active scenarios. It allows for multiple active paths in forwarding state and for load-balancing options.
Figure 20 illustrates how the access-priority attribute can be used. Hub#1 LAN (Primary/backup) Hub#2 LAN (Load-sharing) | | | access-priority 1 access-priority 1 | |--- CE1 ------- PE1 PE3 --------- CE3 --- | | | | | |--- CE2 ------- PE2 PE4 --------- CE4 --- | | access-priority 2 access-priority 1 | PE5 | | | CE5 | Spoke#1 site (Single-homed) Figure 20: Example: Configuring Access Priority In Figure 20, Hub#2 requires load-sharing, so all the site-network- accesses must use the same access-priority value. On the other hand, as Hub#1 requires a primary site-network-access and a backup site-network-access, a higher access-priority setting will be configured on the primary site-network-access. Scenarios that are more complex can also be modeled. Let's consider a Hub site with five accesses to the network (A1, A2, A3, A4, and A5). The customer wants to load-share its traffic on A1 and A2 in the nominal situation. If A1 and A2 fail, the customer wants to load-share its traffic on A3 and A4; finally, if A1, A2, A3, and A4 are all down, the customer wants to use A5. We can model this easily by configuring the following access-priority values: A1=100, A2=100, A3=50, A4=50, A5=10. The access-priority scenario has some limitations. An access-priority scenario like the previous one with five accesses but with the constraint of having traffic load-shared between A3 and A4 in the case where only A1 or A2 (not both) is down is not achievable. But the access-priority attribute defined will cover most of the deployment use cases, and if necessary the model can be extended via augmentation to support additional use cases.
5.9. SVC MTU
The MTU of subscriber service frames can be derived from the physical interface MTU by default, or it can be specified under the "svc-mtu" leaf if it is different than the default number.5.10. Service
The service container defines service parameters associated with the site.5.10.1. Bandwidth
The service bandwidth refers to the bandwidth requirement between the CE and the PE and can be represented using the Committed Information Rate (CIR), the Excess Information Rate (EIR), or the Peak Information Rate (PIR). The requested bandwidth is expressed as ingress bandwidth and egress bandwidth. The ingress or egress direction uses the customer site as the point of reference: "ingress-direction bandwidth" refers to download bandwidth for the site, and "egress-direction bandwidth" refers to upload bandwidth for the site. The service bandwidth is only configurable at the site-network-access level (i.e., for the site network access associated with the site). Using a different ingress and egress bandwidth will allow an SP to know if a customer allows for asymmetric bandwidth access like ADSL. It can also be used to set the rate limit in a different way for uploads and downloads on symmetric bandwidth access. The svc-bandwidth parameter has a specific type. This document defines four types: o bw-per-access: bandwidth is per connection or site network access, providing rate enforcement for all service frames at the interface that are associated with a particular network access. o bw-per-cos: bandwidth is per CoS, providing rate enforcement for all service frames for a given CoS with a specific cos-id. o bw-per-svc: bandwidth is per site, providing rate enforcement for all service frames that are associated with a particular VPN service. o opaque bandwidth is the total bandwidth that is not associated with any particular cos-id, VPN service identified with the vpn-id, or site network access ID.
The svc-bandwidth parameter must include a "cos-id" parameter if the "type" is set to "bw-per-cos". The cos-id can be assigned based on either (1) the IEEE 802.1p value [IEEE-802-1D] in the C-tag or (2) the Differentiated Services Code Point (DSCP) in the Ethernet frame header. Service frames are metered against the bandwidth profile based on the cos-id. The svc-bandwidth parameter must be associated with a specific "site-network-access-id" parameter if the "type" is set to "bw-per-access". Multiple bandwidths per cos-id can be associated with the same site network access. The svc-bandwidth parameter must include a specific "vpn-id" parameter if the "type" is set to "bw-per-svc". Multiple bandwidths per cos-id can be associated with the same EVPN service.5.10.2. QoS
The model defines QoS parameters as an abstraction: o qos-classification-policy: Defines a set of ordered rules to classify customer traffic. o qos-profile: Provides a QoS scheduling profile to be applied.5.10.2.1. QoS Classification
QoS classification rules are handled by "qos-classification-policy". qos-classification-policy is an ordered list of rules that match a flow or application and set the appropriate target CoS (target-class-id). The user can define the match using a more specific flow definition (based on Layer 2 source and destination MAC addresses, cos, dscp, cos-id, color-id, etc.). A "color-id" will be assigned to a service frame to identify its QoS profile conformance. A service frame is "green" if it is conformant with the "committed" rate of the bandwidth profile. A service frame is "yellow" if it exceeds the "committed" rate but is conformant with the "excess" rate of the bandwidth profile. Finally, a service frame is "red" if it is conformant with neither the "committed" rate nor the "excess" rate of the bandwidth profile. When a flow definition is used, the user can use a target-sites leaf-list to identify the destination of a flow rather than using destination addresses. In such a case, an association between the site abstraction and the MAC addresses used by this site must be done dynamically. How this association is done is out of scope for this document. The association of a site to an L2VPN is done through the vpn-attachment container. Therefore, the user can also employ the
"target-sites" leaf-list and "vpn-attachment" to identify the destination of a flow targeted to a specific VPN service. A rule that does not have a "match" statement is considered a "match-all" rule. An SP may implement a default terminal classification rule if the customer does not provide it. It will be up to the SP to determine its default target class. This model defines some applications, but new application identities may be added through augmentation. The exact meaning of each application identity is up to the SP, so it will be necessary for the SP to advise the customer on the usage of application-matching.5.10.2.2. QoS Profile
A user can choose between the standard profile provided by the operator or a custom profile. The QoS profile ("qos-profile") defines the traffic-scheduling policy to be used by the SP. A custom QoS profile is defined as a list of CoS entries and associated properties. The properties are as follows: o direction: Used to specify the direction to which the qos-profile setting is applied. This model supports the site-to-WAN direction ("site-to-wan"), the WAN-to-site direction ("wan-to-site"), and both directions ("bidirectional"). By default, "bidirectional" is used. In the case of both directions, the provider should ensure scheduling according to the requested policy in both traffic directions (SP to customer and customer to SP). As an example, a device-scheduling policy may be implemented on both the PE side and the CE side of the WAN link. In the case of the WAN-to-site direction, the provider should ensure scheduling from the SP network to the customer site. As an example, a device-scheduling policy may be implemented only on the PE side of the WAN link towards the customer. o policing: Optional. Indicates whether policing should apply to one-rate, two-color or to two-rate, three-color. o byte-offset: Optional. Indicates how many bytes in the service frame header are excluded from rate enforcement. o frame-delay: Used to define the latency constraint of the class. The latency constraint can be expressed as the lowest possible latency or as a latency boundary expressed in milliseconds. How this latency constraint will be fulfilled is up to the SP implementation: a strict priority-queuing mechanism may be used on the access and in the core network, or a low-latency routing path may be created for this traffic class.
o frame-jitter: Used to define the jitter constraint of the class.
The jitter constraint can be expressed as the lowest possible
jitter or as a jitter boundary expressed in microseconds. How
this jitter constraint will be fulfilled is up to the SP
implementation: a strict priority-queuing mechanism may be used on
the access and in the core network, or a jitter-aware routing path
may be created for this traffic class.
o bandwidth: Used to define a guaranteed amount of bandwidth for
the CoS. It is expressed as a percentage. The
"guaranteed-bw-percent" parameter uses available bandwidth as a
reference. The available bandwidth should not fall below the CIR
value defined under the input svc-bandwidth or the output
svc-bandwidth. When the "qos-profile" container is implemented on
the CE side, the output svc-bandwidth is taken into account as a
reference. When it is implemented on the PE side, the input
svc-bandwidth is used. By default, the bandwidth reservation is
only guaranteed at the access level. The user can use the
"end-to-end" leaf to request an end-to-end bandwidth reservation,
including across the MPLS transport network. (In other words, the
SP will activate something in the MPLS core to ensure that the
bandwidth request from the customer will be fulfilled by the MPLS
core as well.) How this is done (e.g., RSVP-TE reservation,
controller reservation) is out of scope for this document.
In addition, due to network conditions, some constraints may not be
completely fulfilled by the SP; in this case, the SP should advise
the customer about the limitations. How this communication is done
is out of scope for this document.
5.10.3. Support for BUM
The "broadcast-unknown-unicast-multicast" container defines the type
of site in the customer multicast service topology: source, receiver,
or both. These parameters will help the management system optimize
the multicast service.
Multiple multicast group-to-port mappings can be created using the
"multicast-gp-address-mapping" list. The
"multicast-gp-address-mapping" list defines the multicast group
address and port LAG number. Those parameters will help the SP
select the appropriate association between an interface and a
multicast group to fulfill the customer service requirement.
To ensure that a given frame is transparently transported, a whole
Layer 2 multicast frame (whether for data or control) should not be
altered from a CE to other CEs, except for the VLAN ID field. VLAN
IDs assigned by the SP can also be altered.
For point-to-point services, the provider only needs to deliver a single copy of each service frame to the remote PE, regardless of whether the destination MAC address of the incoming frame is unicast, multicast, or broadcast. Therefore, all service frames should be delivered unconditionally. BUM frame forwarding in multipoint-to-multipoint services, on the other hand, involves both local flooding to other ACs on the same PE and remote replication to all other PEs, thus consuming additional resources and core bandwidth. Special BUM frame disposition rules can be implemented at external-facing interfaces (UNIs or External NNIs (E-NNIs)) to rate-limit the BUM frames, in terms of the number of packets per second or bits per second. The threshold can apply to all BUM traffic, or one threshold can be applied for each category of traffic.5.11. Site Management
The "management" sub-container is intended for site management options, depending on device ownership and security access control. Three common management models are as follows: Provider-managed CE: The provider has sole ownership of the CE device. Only the provider has access to the CE. The responsibility boundary between the SP and the customer is between the CE and the customer network. This is the most common use case. Customer-managed CE: The customer has sole ownership of the CE device. Only the customer has access to the CE. In this model, the responsibility boundary between the SP and the customer is between the PE and the CE. Co-managed CE: The provider has ownership of the CE device and is responsible for managing the CE. However, the provider grants the customer access to the CE for some configuration/monitoring purposes. In this co-managed mode, the responsibility boundary is the same as for the provider-managed model. The selected management mode is specified under the "type" leaf. The "address" leaf stores CE device management addressing information. The "management-transport" leaf is used to identify the transport protocol for management traffic: IPv4 or IPv6. Additional security options may be derived based on the particular management model selected.
5.12. MAC Loop Protection
MAC address flapping between different physical ports typically indicates a bridge loop condition in the customer network. Misleading entries in the MAC cache table can cause service frames to circulate around the network indefinitely and saturate the links throughout the provider's network, affecting other services in the same network. In the case of EVPNs, it also introduces massive BGP updates and control-plane instability. The SP may opt to implement a switching loop-prevention mechanism at the external-facing interfaces for multipoint-to-multipoint services by imposing a MAC address move threshold. The MAC move rate and prevention-type options are listed in the "mac-loop-prevention" container.5.13. MAC Address Limit
The optional "mac-addr-limit" container contains the customer MAC address limit and information that describes the action taken when the limit is exceeded and the aging time for a MAC address. When multiple services are provided on the same network element, the MAC address table (and the Routing Information Base space for MAC routes in the case of EVPNs) is a shared common resource. SPs may impose a maximum number of MAC addresses learned from the customer for a single service instance by using the "mac-addr-limit" leaf and may use the "action" leaf to specify the action taken when the upper limit is exceeded: drop the packet, flood the packet, or simply send a warning log message. For point-to-point services, if MAC learning is disabled, then the MAC address limit is not necessary.
(next page on part 5)
