Listen to this article if you do not want to read
All we know till now is RSVP based traffic engineering in LDP based MPLS. RSVP-TE is not scalable solution and it has its own complexities like
- the number of tunnels required in full mesh among nodes (becomes double if backup tunnel is also maintained is very un-scalable)
- state to be maintained in each node for each tunnel
- Lack of ECMP in RSVP based tunnels
On the other hand, SRTE provides state-less solution. Traffic engineering in Segment Routing is fundamentally a SR policy which is , firstly , translate intent (objective or constraints ) of traffic engineering into SR policies, secondly , steer traffic onto appropriate SR policy.
SR Policy in its simplest form is a set of segments or a sequence of Segment ids called SIDs. List of SIDs is computed by either router or path computation Element (SR-PCE) . Hybrid solution leverages computation on both router and SR-PCE.
Now, need to understand two fundamentals concepts briefly mentioned above, first is , intent or in other words constraints or we can call it as purpose of traffic engineering which is to provide SLAs. These SLAs constraints can be end-to-end delay, Bandwidth, disjointness of path or link affinity (to include or exclude few links in the network) etc. Second is , traffic steering.Traffic steering simply is associating or identifying traffic with SR policies . This is done by tagging BGP routes with color and associating color with SR policy.
In SRTE implementation, the role of centralized computation aka SDN controller (SR-PCE) becomes very important and almost mandatory for certain use cases such as disjoint path (disjoint paths are isolated paths from separate source/headend routers which will never follow same path. This cannot be accomplished without having central view via SR-PCE . Another example is , inter-domain SR policy which means source node and destination endpoint are in different domains ( IGP domain) and no redistribution or BGP-LU used. Another use case may be bandwidth aware SR policy where central view of real time available bandwidth and congestion awareness is required . In this case, centralized technique is required to optimize bandwidth allocation and coordination.
As mentioned previously, there is no concept of tunnel in SRTE , instead SR policy is defined which signifies intent or objective of traffic engineering . SR Policy has three attributes which are given below,
headend – where the SR policy is instantiated
endpoint – where policy ends
color – its a identification of intent or policy
At the headend node, SR policy is identified by endpoint and color.
There are few other concepts as well which plays critical role in SRTE like BGP-LS , PCEP, Flex-algo. BGP-LS which is required for centralized link state topology information, PCEP used while headend router communicated with SR-PCE and Flex-algo which is creating custom IGP algorithm. please refer to below link for Flex-algo details in my earlier Post.
There are other two important aspect of SRTE , one is automation of SR policies called ODN (on-demand next hop) and other is automation of traffic steering called automated steering.
We will discuss details of SRTE in subsequent articles along with use cases. I hope this article will help understanding basics of SRTE.