Color-Based Traffic Engineering Configuration

VPN Service Coloring

In general, a VPN service may be assigned a color on the egress router where the VPN NLRI is advertised, or on an ingress router where the VPN NLRI is received and processed.

You can assign a color to the VPN services at different levels:

• Per routing instance.

• Per BGP group.

• Per BGP neighbor.

• Per prefix.

• Set of prefixes.

Once you assign a color, the color is attached to a VPN service in the form of BGP color extended community.

You can assign multiple colors to a VPN service, referred to as multi-color VPN services. In such cases, the smallest color value is considered as the color of the VPN service, and all other colors are ignored.

Multiple colors are assigned by egress and/or ingress devices through multiple policies in the following order:

• BGP export policy on the egress device.

• BGP import policy on the ingress device.

• VRF import policy on the ingress device.

The two modes of VPN service coloring are:

• Egress Color Assignment
• Ingress Color Assignment

Specifying VPN Service Mapping Mode

To specify flexible VPN service mapping modes, you must define a policy using the resolution-map statement, and refer the policy in a VPN service’s routing-instance vrf-import, group import, or group neighbor import at the [edit protocols bgp] hierarchy level. All the VPN routes matching the routing policy are attached with the specified resolution-map.

For example:

You can apply import policy to the VPN service’s routing-instance.

You can also apply the import policy to a BGP group or BGP neighbor.

Color-IP Protocol Next Hop Resolution

The protocol next hop resolution process is enhanced to support colored-IP protocol next hop resolution. For a colored VPN service, the protocol next hop resolution process takes a color and a resolution-map, builds a colored-IP protocol next hop in the form of ip-address:color, and resolves the protocol next hop in the inetcolor.0 and inet6color.0 routing tables.

You must configure a policy to support multipath resolution of colored Layer 2 VPN, Layer 3 VPN, or EVPN services over colored LSPs. The policy must then be applied with the relevant RIB table as the resolver import policy.

For example:

Fallback to IP Protocol Next Hop Resolution

If a colored VPN service does not have a resolution-map applied to it, the VPN service ignores its color and falls back to the IP protocol next hop resolution. Conversely, if a non-colored VPN service has a resolution-map applied to it, the resolution-map is ignored, and the VPN service uses the IP protocol next hop resolution.

The fallback is a simple process from colored SR-TE LSPs to LDP LSPs, by using a RIB group for LDP to install routes in inet{6}color.0 routing tables. A longest prefix match for a colored-IP protocol next hop ensures that if a colored SR-TE LSP route does not exist, an LDP route with a matching IP address should be returned.

BGP Labeled Unicast Color-based Mapping over SR-TE and IS-IS Underlay

Starting in Junos OS Release 20.2R1, BGP Labeled Unicast (BGP-LU) can resolve IPv4 or IPv6 routes over segment routing–traffic engineering (SR-TE) with IS-IS underlay for both IPv4 and IPv6 address families. BGP-LU supports mapping a BGP community color and defining a resolution map for SR-TE. A colored protocol next hop is constructed and it is resolved on a colored SR-TE tunnel in the inetcolor.0 or inet6color.0 table. Thus BGP-LU resolves protocol next hop over SR-TE tunnels for packet transport. BGP uses inet.3 and inet6.3 tables for non-color based mapping.

Supported and Unsupported Features for Color-Based Mapping of VPN Services

The following features and functionality are supported with color-based mapping of VPN services:

• BGP Layer 3 VPN

• BGP Layer 2 VPN (Kompella Layer 2 VPN)

• BGP EVPN

• Resolution-map with a single IP-color option.

• Colored IPv4 and IPv6 protocol next hop resolution.

• Routing information base (also known as routing table) group based fallback to LDP LSP in inetcolor.0 or inet6color.0 routing tables.

• Colored SR-TE LSP.

• Virtual platforms.

• 64-bit Junos OS.

• Logical systems.

• BGP Labeled Unicast

The following features and functionality are not supported with color-based mapping of VPN services:

• Colored MPLS LSPs, such as RSVP, LDP, BGP-LU, static.

• Layer 2 circuit

• FEC-129 BGP auto-discovered and LDP-signaled Layer 2 VPN.

• VPLS

• MVPN

• IPv4 and IPv6 using resolution-map.

Benefits of BGP Classful Transport Planes

• Network-slicing–Service and transport layers are decoupled from each other, laying the foundation for network-slicing and virtualization with the end-to-end slicing across multiple domains, thereby significantly reducing the CAPEX.

• Inter-domain interoperability–Extends transport class deployment across co-operating domains so the different transport signaling protocols in each domain interoperate. Reconciles any differences between extended community namespaces that may be in use in each domain.

• Colored resolution with fallback–Enables resolution over colored tunnels (RSVP, IS-IS flexible algorithm) with flexible fallback options over best-effort tunnels or any other color tunnel.

• Quality-of-service–Customizes and optimizes the network to achieve the end-to-end SLA requirements.
• Leveraging existing deployments–Supports well deployed tunneling protocols like RSVP along with new protocols, such as IS-IS flexible algorithm, preserving ROI and reducing OPEX.

Terminology of BGP Classful Transport Planes

This section provides a summary of commonly used terms for understanding BGP classful transport plane.

• Service node–Ingress Provider Edge (PE) devices that send and receive service routes (Internet and Layer 3 VPN).

• Border node–Device at the connection point of different domains (IGP areas or ASs).

• Transport node–Device that sends and receives BGP-Labeled Unicast (LU) routes.

• BGP-VPN–VPNs built using RFC4364 mechanisms.

• Route Target (RT)–Type of extended community used to define VPN membership.

• Route Distinguisher (RD)–Identifier used to distinguish to which VPN or virtual private LAN service (VPLS) a route belongs. Each routing instance must have a unique route distinguisher associated with it.

• Resolution scheme–Used to resolve protocol next-hop address (PNH) in resolution RIBs providing fallback.

  They map the routes to the different transport RIBs in the system based on mapping community.

• Service family–BGP address family used for advertising routes for data traffic, as opposed to tunnels.

• Transport family –BGP address family used for advertising tunnels, which are in turn used by service routes for resolution.

• Transport tunnel–A tunnel over which a service may place traffic, for example, GRE, UDP, LDP, RSVP, SR-TE, BGP-LU.

• Tunnel domain–A domain of the network containing service nodes and border nodes under a single administrative control that has a tunnel between them. An end-to-end tunnel spanning several adjacent tunnel domains can be created by stitching the nodes together using labels.

• Transport class–A group of transport tunnels offering the same type of service.

• Transport class RT–A new format of route target used to identify a specific transport class.

  A new format of Route Target used to identify a specific transport class.

• Transport RIB–At the service node and border node, a transport class has an associted transport RIB that holds its tunnel routes.

• Transport RTI–A routing instance; container of transport RIB, and associated transport class Route Target and Route Distinguisher.

• Transport plane–Set of transport RTIs importing same transport class RT. These are in turn stitched together to span across tunnel domain boundaries using a mechanism similar to Inter-AS option-b to swap labels at border nodes (nexthop-self), forming an end-to-end transport plane.

• Mapping community–Community on a service route that maps to resolve over a transport class.

Understanding BGP Classful Transport Planes

You can use BGP classful transport planes to configure transport classes for classifying a set of transport tunnels in an intra-AS network based on the traffic engineering characteristics and use these transport tunnels to map service routes with the desired SLA and intended fallback.

BGP classful transport planes can extend these tunnels to inter-domain networks that span across multiple domains (ASs or IGP areas) while preserving the transport class. To do this, you must configure the BGP classful trasport transport layer BGP family between the border and service nodes.

In both inter-AS and intra-AS implementations, there can be many transport tunnels (MPLS LSPs, IS-IS flexible algorithm, SR-TE) created from the service and border nodes. The LSPs may be signaled using different signaling protocols in different domains, and can be configured with different traffic engineering characteristics (class or color). The transport tunnel endpoint also acts as the service endpoint and can be present in the same tunnel domain as the service ingress node, or in an adjacent or non-adjacent domain. You can use BGP classful transport planes to resove services over LSPs with certain traffic engineering charateristics either inside a single domain or across multiple domains.

BGP classful transport planes reuse the BGP-VPN technology, keeping the tunneling-domains loosely coupled and coordinated.

• The network layer reachability information (NLRI) is RD:TunnelEndpoint used for path-hiding.
• The route target indicates the transport class of the LSPs, and leaks routes to the corresponding transport RIB on the destination device.
• Every transport tunneling protocol installs an ingress route into the transport-class.inet.3 routing table, models the tunnel transport class as a VPN route target, and collects the LSPs of the same transport class in the transport-class.inet.3 transport-rib routing table.

• Routes in this routing instance are advertised in the BGP classful transport plane (inet transport) AFI-SAFI following procedures similar to RFC-4364.

• When crossing inter-AS link boundary, you must follow Option-b procedures to stitch the transport tunnels in these adjacent domains.

  Similarly, when crossing intra-AS regions you must follow Option-b procedures to stitch the transport tunnels in the different TE-domains.

• You can define resolution schemes to specify the intent on the variety of transport classes in a fallback order.

• You can resolve service routes and BGP classful transport routes over these transport classes, by carrrying the mapping community on them.

The BGP classful transport family runs along side the BGP-LU transport layer family. In a seamless MPLS network running BGP-LU, meeting stringent SLA requirements of 5G is a challenge as the traffic engineering characteristics of the tunnels are not known or preserved across domain boundaries. BGP classful transport planes provide operationally easy and scalable means to advertise multiple paths for remote loopbacks along with the transport class information in the seamless MPLS architecture. In BGP classful tranport family routes, different SLA paths are represented using Transport Route-Target extended community, which carries the transport class color. This Transport Route-Target is used by the receiving BGP routers to associate the BGP classful transport route with the appropriate transport class. When re-advertising the BGP classful transport routes, MPLS swaps routes, inter connect the intra-AS tunnels of the same transport class, thereby forming an end-to-end tunnel that preserves the transport class.

Intra-AS Implementation of BGP Classful Transport Planes

Figure 1 illustrates a network topology with before-and-after scenarios of implementing BGP classful transport planes in an intra-AS domain. Devices PE11 and PE12 use RSVP LSPs as the transport tunnel and all transport tunnel routes are installed in inet.3 RIB. Implementing BGP classful transort planes enables RSVP transport tunnels to be color-aware similar to segment routing tunnels.

Figure 1: Intra-AS Domain: Before-and-After Scenarios For BGP Classful Transport Planes Implementation

To classify transport tunnels into BGP transport class in an intra-AS setup:

1. Define the transport class at the service node (ingress PE devices), for example, gold and bronze, and assign color community values to the defined transport class.

   Sample configuration:

2. Associate the transport tunnel to a specific transport class at the ingress node of the tunnels.

   Sample configuration:

Intra-AS BGP classful transport plane functionality:

• BGP classful transport creates predefined transport RIBs per named transport class (gold and bronze) and auto derives mapping community from its color value (100 and 200).
• Intra-AS transport routes are populated in transport RIBs by the tunneling protocol when it is associated with a transport class.

  In this example, RSVP LSP routes associated with transport class gold (color 100) and transport class bronze (color 200) are installed in the transport RIBs junos-rti-tc-<100>.inet.3 and junos-rti-tc-<200>.inet.3, respectively.

• Service node (ingress PEs) match extended color community (color:0:100 and color:0:200) of service route against the mapping community in predefined resolution RIBs and resolve the protocol next hop (PNH) in corresponding transport RIBs (either junos-rti-tc-<100>.inet.3, or junos-rti-tc-<200>.inet.3).
• BGP routes bind to a resolution scheme by carrying the assiocaited mapping community.
• Each transport class automatically creates two predefined resolution schemes and automatically derives the mapping community.

  One resolution scheme is for resolving service routes that use Color:0:<val> as the mapping community.

  The other resolution scheme is for resolving transport routes that use Transport-Target:0:<val> as the mapping community.

• If service route PNH cannot be resolved using RIBs listed in the predefined resolution scheme, then it can fall back to the inet.3 routing table.
• You can also configure fallback between different colored transport RIBs by using user-defined resolution schemes under the [edit routing-options resolution scheme] configuration hierarchy.

Inter-AS Implementation of BGP Classful Transport Planes

In an inter-AS network, BGP-LU is converted to BGP classful transport network after configuring a minimum of two transport classes (gold and bronze) on all service nodes or PE devices and border nodes (ABRs and ASBRs).

To convert the transport tunnels into BGP classful transport:

1. Define transport class at the service nodes (ingress PE devices) and the border nodes (ABRs and ASBRs), for example, gold and broze.

   Sample configuration:

2. Associate the transport tunnels to a specific transport class at the ingress node of the tunnels (ingress PEs, ABRs,and ASBRs).

   Sample configuration:

   For RSVP LSPs

   For IS-IS flxible algorithm

3. Enable new family for the BGP classful transport (inet transport) and BGP-LU (inet labeled-unicast) in the network.

   Sample configuration:

4. Advertise service routes from the egress PE device with appropriate extended color community.

   Sample configuration:

Inter-AS BGP classful transport plane functionality:

1. BGP classful transport planes create predefined transport RIBs per named transport class (gold and bronze) and automatically derives mapping community from its color value.

2. Intra-AS transport routes are populated in transport RIBs by tunneling protocols when associated with a transport class.

   For example, transport tunnel routes associated with the transport class gold and bronze are installed in the transport RIBs junos-rti-tc-<100>.inet.3 and junos-rti-tc-<200>.inet.3, respectively.

3. BGP classful transport planes use unique Route Distinguisher and Route Target when it copies the transport tunnel routes from each transport RIB to the bgp.transport.3 routing table.
4. Border nodes advertise routes from bgp.transport.3 routing table to its peers in other domains if family inet transport is negotiated in the BGP session.
5. Receiving border node installs these bgp-ct routes in the bgp.transport.3 routing table and copies these routes based on the transport Route Target to the appropriate transport RIBs.
6. Service node matches the color community in the service route against a mapping community in the resolution schemes and resolves PNH in the corresponding transport RIB (either junos-rti-tc-<100>.inet.3, or junos-rti-tc-<200>.inet.3).
7. Border nodes use predefined resolution schemes for transport route PNH resolution.
8. Predefined or user defined, both resolution schemes support service route PNH resolution. Predefined uses inet.3 as fallback, and user-defined resolution scheme allows list of transport RIBs to be used in the order specified while resolving PNH.
9. If service route PNH cannot be resolved using RIBs listed in the user-defined resolution scheme, then route is discarded.

BGP Classful Transport (BGP-CT) with Underlying Colored SR-TE Tunnels Overview

Benefits of BGP-CT with underlying colored SR-TE Tunnels

• Solves scale concerns that may arise in the future as the network grows.
• Provides inter-connectivity for domains that use different technologies.
• Decouples services and the transport layers resulting in a completely distributed network.
• Provides independent bandwidth management through an intra-domain traffic engineering controller for SR-TE.

Large networks that are growing and evolving continuously require a seamless segment routing architecture. Starting in Junos OS Release 21.2,R1 we support BGP-CT with underlying transport as colored SR-TE tunnels. BGP-CT can resolve service routes using the transport RIBs and compute the next hop. Services that are currently supported over BGP-CT can also use the underlying SR-TE colored tunnels for route resolution. The services can now use the underlying SR-TE colored tunnels such as the static colored, BGP SR-TE, programmable rpd and PCEP colored tunnels. BGP-CT uses the next-hop reachability to resolve service routes over the desired transport class.

To enable BGP-CT service route resolution over underlying SR-TE colored tunnels, include the use-transport-class statement at the [edit protocols source-packet-routing] hierarchy level.

Benefits of BGP-CT with underlying colored SR-TE Tunnels

• Solves scale concerns that may arise in the future as the network grows.
• Provides inter-connectivity for domains that use different technologies.
• Decouples services and the transport layers resulting in a completely distributed network.
• Provides independent bandwidth management through an intra-domain traffic engineering controller for SR-TE.

Large networks that are growing and evolving continuously require a seamless segment routing architecture. Starting in Junos OS Release 21.2,R1 we support BGP-CT with underlying transport as colored SR-TE tunnels. BGP-CT can resolve service routes using the transport RIBs and compute the next hop. Services that are currently supported over BGP-CT can also use the underlying SR-TE colored tunnels for route resolution. The services can now use the underlying SR-TE colored tunnels such as the static colored, BGP SR-TE, programmable rpd and PCEP colored tunnels. BGP-CT uses the next-hop reachability to resolve service routes over the desired transport class.

To enable BGP-CT service route resolution over underlying SR-TE colored tunnels, include the use-transport-class statement at the [edit protocols source-packet-routing] hierarchy level.