This section has Frequently asked questions or Interview questions about segment Routing with short answers. This section can help for preparing for Interview . This is kind of cheat sheet for quick reference.
Click at any question to expand
MPLS uses LDP and IGP (ISIS and OSPF) as control plane protocols . LDP for label information exchange and IGP for Prefix information exchange between neighbours . On the other hand , Segment Routing uses IGP (ISIS and OSPF) for Prefix as well as segment id exchange between neighbours. Label in Segment routing is called as Segment Id and stack of labels is called SID list (Segment id list). Segment Routing can have two types of dataplane (forwarding operation) , MPLS or IPv6. Segment routing with MPLS dataplane is called SR-MPLS and with IPv6 dataplane is called SRv6. Visit here for more details.
Segment routing control plane consist of Routing protocols to distribute Prefix (subnets) and Segment ids in the network. Segment Routing control plane is specified for link-state interior gateway (IGP) protocols such as IS-IS, OSPF and for Border gateway protocol (BGP). Extension of routing protocols enables them to distribute Segment Routing information within IGP or BGP domain along with topology and reachability information. Refer here for more details.
Segment Routing architecture supports two Data Planes implementations. It can be either MPLS data plane and the IPv6 data plane. Segment Routing with MPLS data plane leverages existing MPLS architecture .Segment id (SID) is represented as MPLS label. Visit here for more details.
SR MPLS data plane uses same label forwarding operation of existing MPLS as given below,
Label Push – Label Pop – Label Swap
Segment Routing with IPv6 data plane uses new type of extension header called SRH (Segment Routing Header). The IPv6 data plane implementation of Segment Routing is known as SRv6 . In SRv6 implementation , segment is represented using IPv6 address , and segment list is encoded as an ordered list of IPv6 addresses in the SRH header. Visit here for more details.
There are two types of segments , Segments distributed by IGP are called IGP segments and those distributed by BGP are called BGP segments. Further, there are two types of IGP segments ,
1. IGP Prefix Segment – It is distributed by either ISIS or OSPF . IGP prefix segment is associated with prefix advertised by IGP.
2. IGP Adjacency Segment – This type of segment is associated with unidirectional adjacency of IS-IS or OSPF. It signify to steer traffic out to link of the adjacency (ISIS or OSPF) of the segment.
Similarly , there are two types of BGP segments,
1. BGP Prefix Segment – BGP prefix segment is associated with BGP prefixes , similar to IGP prefix segment associated with IGP prefixes.
2. BGP Peer Segment – BGP peer segments are associated with BGP Peering session to a specific neighbour
Further details can be found here
Mapping server helps in SR-LDP interworking functionality. If a Node which does not support SR, it will not advertise its Prefix-SID. Advertisement of Prefix-SID associated with prefix done by some other entity on behalf on non-SR enabled node is called mapping server functionality.
Mapping server keeps and advertise Prefix to Prefix-SID mapping entries. Mapping server functionality is required in the network to enable interworking between segment routing enabled nodes and non-Segment Routing enabled nodes such as LDP nodes.
For more details visit here
Traffic engineering in Segment Routing fundamentally is, defining a SR policy with two functions ,
- firstly , translate intent (objective or constraints say low latency path or high bandwidth path) of traffic engineering into SR policies
- secondly , steer traffic onto appropriate SR policy.
SR Policy defines two basic actions of SR traffic engineering ,
- It express a path through the network which is different from shortest path computed by IGP
- Traffic steering
Binding SID or BSID is locally significant SID associated with SR Policy . It helps to steer packets into its associated SR policy. If a packet is received with top label as BSID , it is steered into SR Policy associated with that BSID , top label (BSID) is popped and SID list of SR Policy is pushed.
BSID provides benefit of scaling , it helps to reduce the number of Segments on the headend node in large network or multi-domain network and brings service independence. In multi-domain network , transit SR Policy and its associated BSID brings topology non-transparency in case one domains do not want to share topology information with each other.
ODN functionality in Segment Routing traffic engineering (SRTE) automatically instantiate SR Policy paths by headend node. These paths are based on ODN templates , each template specifies the requirement of the path. ODN template specifies the characteristics of the candidate path such as metric or preference or link affinity etc.
SR candidate path can be either statically configured or instantiated automatically using ODN. It drastically reduces complex configuration on service headend nodes. The ODN can be applied to both intra or inter domain networks.
For more details visit here
Automated steering is a mechanism in SRTE by which it automatically steer service routes ( BGP routes or L3VPN routes) onto SR Policy based on color associated with those routes exchanged between BGP peers . Color information is exchanged between BGP peers using BGP extended community attribute.
There are two types of automated steering , these are,
1. Per-destination Automated steering – it automatically steers service route onto SR policy based on color and next-hop address.
2. Per-flow Automated steering – It automatically steers traffic flows based on fields like DSCP value or source address etc. (basically requires a match criteria which can identify specific flow rather than all traffic)
More details can be found here
Segment Routing traffic engineering (SRTE) database is very important in SRTE functionality having information about nodes, links, SR policies, prefixes which headend node or centralized SDN controller (SR-PCE) uses to compute and validate paths specially in Multi-domain or multi-AS networks.
To have multi-domain or multi-AS validated path or traffic engineering path , a centralized component SR-PCE is required to have central view of topology and database of link state information of entire network . SR-PCE (SDN controller) gets all information from BGP-LS (BGP address family link state). SR-PCE consolidates all information received via BGP-LS to compute inter-domain paths required in SRTE. Visit here for detailed information on BGP-LS.