Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
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 4 of 8 – Pages 48 to 61
First   Prev   Next

Top   ToC   RFC8466 - Page 48   prevText

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).
Top   ToC   RFC8466 - Page 49
   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.
Top   ToC   RFC8466 - Page 50

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
Top   ToC   RFC8466 - Page 51
   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.
Top   ToC   RFC8466 - Page 52
   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.
Top   ToC   RFC8466 - Page 53
   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.
Top   ToC   RFC8466 - Page 54
   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.
Top   ToC   RFC8466 - Page 55
   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.
Top   ToC   RFC8466 - Page 56

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.
Top   ToC   RFC8466 - Page 57
   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
Top   ToC   RFC8466 - Page 58
   "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.
Top   ToC   RFC8466 - Page 59
   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.
Top   ToC   RFC8466 - Page 60
   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.
Top   ToC   RFC8466 - Page 61

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)

Next Section