Color-Based Traffic Engineering Configuration
SUMMARY
Color-Based Mapping of VPN Services Overview
You can specify color as a protocol next hop constraint (in addition to the IPv4 or IPv6 address) for resolving transport tunnels over static colored and BGP segment routing traffic-engineered (SR-TE) LSPs. This is called the color-IP protocol next hop resolution, where you are required to configure a resolution-map and apply to the VPN services. With this feature, you can enable color-based traffic steering of Layer 2 and Layer 3 VPN services.
Junos OS supports colored SR-TE LSPs associated with a single color. The color-based mapping of VPN services feature is supported on static colored LSPs and BGP SR-TE LSPs.
- VPN Service Coloring
- Specifying VPN Service Mapping Mode
- Color-IP Protocol Next Hop Resolution
- Fallback to IP Protocol Next Hop Resolution
- BGP Labeled Unicast Color-based Mapping over SR-TE and IS-IS Underlay
- Supported and Unsupported Features for Color-Based Mapping of VPN Services
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
In this mode, the egress device (that is, the advertiser of the VPN NLRI) is responsible for coloring the VPN service. To enable this mode, you can define a routing policy, and apply it in the VPN service’s routing-instance vrf-export, group export, or group neighbor export at the [edit protocols bgp] hierarchy level. The VPN NLRI is advertised by BGP with the specified color extended community.
For example:
[edit policy-options] community red-comm { members color:0:50; }
[edit policy-options] policy-statement pol-color { term t1 { from { [any match conditions]; } then { community add red-comm; accept; } } }
[edit routing-instances] vpn-X { ... vrf-export pol-color ...; }
OR
When you apply the routing policy as an export policy of a BGP group or BGP neighbor,
you must include the vpn-apply-export
statement at the BGP, BGP group,
or BGP neighbor level in order for the policy to take an effect on the VPN NLRI.
[edit protocols bgp] group PEs { ... neighbor PE-A { export pol-color ...; vpn-apply-export; } }
The routing policies are applied to Layer 3 VPN prefix NLRIs, Layer 2 VPN NRLIs, and EVPN NLRIs. The color extended community is inherited by all the VPN routes, imported, and installed in the target VRFs on one or multiple ingress devices.
Ingress Color Assignment
In this mode, the ingress device (that is, the receiver of the VPN NLRI) is responsible
for coloring the VPN service. To enable this mode, you can define a routing policy, and
apply it to the 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 is attached with the specified color extended
community.
For example:
[edit policy-options] community red-comm { members color:0:50; }
[edit policy-options] policy-statement pol-color { term t1 { from { [any match conditions]; } then { community add red-comm; accept; } } }
[edit routing-instances] vpn-Y { ... vrf-import pol-color ...; }
OR
[edit protocols bgp] group PEs { ... neighbor PE-B { import pol-color ...; } }
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:
[edit policy-options] resolution-map map-A { <mode-1>; <mode-2>; ... } policy-statement pol-resolution { term t1 { from { [any match conditions]; } then { resolution-map map-A; accept; } } }
You can apply import policy to the VPN service’s routing-instance.
[edit routing-instances] vpn-Y { ... vrf-import pol-resolution ...; }
You can also apply the import policy to a BGP group or BGP neighbor.
[edit protocols bgp] group PEs { ... neighbor PE-B { import pol-resolution ...; } }
Each VPN service mapping mode should have a unique name defined in the resolution-map. Only a single entry of IP-color is supported in the resolution-map, where the VPN route(s) are resolved using a colored-IP protocol next hop in the form of ip-address:color over the inetcolor.0 and inet6color.0 routing tables.
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:
[edit policy-options] policy-statement mpath { then multipath-resolve; }
[edit routing-options] resolution { rib bgp.l3vpn.0 { inetcolor-import mpath; } } resolution { rib bgp.l3vpn-inet6.0 { inet6color-import mpath; } } resolution { rib bgp.l2vpn.0 { inetcolor-import mpath; } } resolution { rib mpls.0 { inetcolor-import mpath; } } resolution { rib bgp.evpn.0 { inetcolor-import mpath; } }
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.
See Also
BGP Classful Transport Planes Overview
- Benefits of BGP Classful Transport Planes
- Terminology of BGP Classful Transport Planes
- Understanding BGP Classful Transport Planes
- Intra-AS Implementation of BGP Classful Transport Planes
- Inter-AS Implementation of BGP Classful Transport Planes
- BGP Classful Transport (BGP-CT) with Underlying Colored SR-TE Tunnels Overview
- Benefits of BGP-CT with underlying colored SR-TE Tunnels
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.


To classify transport tunnels into BGP transport class in an intra-AS setup:
- 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:
pe11# show routing-options route-distinguisher-id 172.16.1.1; transport-class { name gold { color 100; } name bronze { color 200;
- Associate the transport tunnel to a specific transport class at the ingress node of the
tunnels.
Sample configuration:
pe11# show protocols mpls label-switched-path toPE12-bronze { transport-class bronze; } label-switched-path toPE12-gold { transport-class gold; }
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:
- Define transport class at the service nodes (ingress PE devices) and the border nodes
(ABRs and ASBRs), for example, gold and broze.
Sample configuration:
pe11# show routing-options route-distinguisher-id 172.16.1.1; transport-class { name gold { color 100; } name bronze { color 200;
- 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
abr23# show protocols mpls label-switched-path toASBR21-bronze { transport-class bronze; } label-switched-path toASBR22-gold { transport-class gold;
For IS-IS flxible algorithm
asbr13# show routing-options flex-algorithm 128 { … color 100; use-transport-class; } flex-algorithm 129 { … color 200; use-transport-class; }
- Enable new family for the BGP classful transport (inet transport) and BGP-LU (inet
labeled-unicast) in the network.
Sample configuration:
abr23# show protocols bgp group toAs2-RR27 { family inet { labeled-unicast { … } transport { … } cluster 172.16.2.3; neighbor 172.16.2.7; }
- Advertise service routes from the egress PE device with appropriate extended color
community.
Sample configuration:
pe11# show policy-options policy-statement red term 1 { from { route-filter 192.168.3.3/32 exact; } then { community add map2gold; next-hop self; accept; } } term 2 { from { route-filter 192.168.33.33/32 exact; } then { community add map2bronze; next-hop self; accept; } } community map2bronze members color:0:200; community map2gold members color:0:100;
Inter-AS BGP classful transport plane functionality:
- BGP classful transport planes create predefined transport RIBs per named transport class (gold and bronze) and automatically derives mapping community from its color value.
-
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.
- 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.
- 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.
- 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.
- 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).
- Border nodes use predefined resolution schemes for transport route PNH resolution.
- 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.
- 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.
- Enable the
use-transport-class
statementat the
along with the[edit protocols source-packet-routing]
hierarchy level.auto-create
statement at the[edit routing-options transport-class]
hierarchy level. - We don't support RIB groups for colored SR-TE with
use-transport-class
and color-only SR-TE tunnels with this feature.
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.
- Enable the
use-transport-class
statementat the
along with the[edit protocols source-packet-routing]
hierarchy level.auto-create
statement at the[edit routing-options transport-class]
hierarchy level. - We don't support RIB groups for colored SR-TE with
use-transport-class
and color-only SR-TE tunnels with this feature.