Inter-domain Adj segments with BGP-LS-EPE

Lately, i’ve been exploring the evolution of TE solutions in inter-domain scenarios.

In a previous post, I showed how to enable passive IGP on the inter-domain link in order to advertise that information via BGP-LS and enrich local TED with data from other domains.

Inter-domain link information is fundamental as TED needs to know about it so to, for example, have rsvp being able to build the lsp.

That solution, passive IGP on both sides of the link, was ok in a RSVP-driven world.

Instead, if we move to a SR-based one, and that’s what we want to do, we need something else as we need some labels to identify the inter-domain link as a segment.

To achieve this, we rely on our good old friend BGP.

BGP allows us to define so-called EPE neighbors (Egress PE).

Let’s consider this scenario:

We want to define EPE neighbors on both r4a and r4b.

What we want to have are two new Adj SIDs, one for each direction.

On r4a, on the eBGP session with r4b, we configure:

set protocols bgp group bgp-ls neighbor 192.168.45.1 egress-te-adj-segment to-r4b label 1000451
set protocols bgp group bgp-ls neighbor 192.168.45.1 egress-te-adj-segment to-r4b next-hop 192.168.45.1
set protocols bgp group bgp-ls neighbor 192.168.45.1 egress-te-adj-segment to-r4b te-link-attribute te-metric 4
set protocols bgp group bgp-ls neighbor 192.168.45.1 egress-te-adj-segment to-r4b te-link-attribute igp-metric 3
set protocols bgp group bgp-ls neighbor 192.168.45.1 egress-te-adj-segment to-r4b te-link-attribute admin-group premium
set protocols bgp group bgp-ls neighbor 192.168.45.1 egress-te-adj-segment to-r4b te-link-attribute admin-group video

• label 1000451 is assigned to reach neighbor 192.168.45.1
• admin-groups can be addedd
• igp/te metrics can be defined

Basically, we define a new segment (a single hop adj segment) that can be enriched with TE attributes like colors and metric.

Similarly, on r4b:

set protocols bgp group bgp-ls neighbor 192.168.45.0 egress-te-adj-segment to-r4a label 1000450
set protocols bgp group bgp-ls neighbor 192.168.45.0 egress-te-adj-segment to-r4a next-hop 192.168.45.0
set protocols bgp group bgp-ls neighbor 192.168.45.0 egress-te-adj-segment to-r4a te-link-attribute te-metric 4
set protocols bgp group bgp-ls neighbor 192.168.45.0 egress-te-adj-segment to-r4a te-link-attribute igp-metric 3
set protocols bgp group bgp-ls neighbor 192.168.45.0 egress-te-adj-segment to-r4a te-link-attribute admin-group premium

Let’s focus on r1a.

The EPE segment is stored into TED bgp-ls-epe topology. This is another topology along with the default one and l3-unicast:

We can have a look:

root@r4a> show ted link topology-type bgp-ls-epe detail
100.4.4.4->200.4.4.4, Local: 192.168.45.0, Remote: 192.168.45.1
  Local interface index: 336, Remote interface index: 0
  Link name: to-r4b
  Local bgp peer as: 100, Remote bgp peer as: 200
  LocalPath: 0, Metric: 4, IGP metric: 3
      Color: 0x6 video premium
  localBW [0] 0bps  [1] 0bps  [2] 0bps  [3] 0bps
  localBW [4] 0bps  [5] 0bps  [6] 0bps  [7] 0bps
  SID: 1000451 Type: Adj-SID Flags: 0xd0 Weight: 0

root@r4a> show ted link topology-type l3-unicast detail
100.4.4.4->200.4.4.4, Local: 192.168.45.0, Remote: 192.168.45.1
  Local interface index: 336, Remote interface index: 0
  Link name: to-r4b
  LocalPath: 0, Metric: 4, IGP metric: 3
      Color: 0x6 video premium
  localBW [0] 0bps  [1] 0bps  [2] 0bps  [3] 0bps
  localBW [4] 0bps  [5] 0bps  [6] 0bps  [7] 0bps
  SID: 1000451 Type: Adj-SID Flags: 0xd0 Weight: 0

As you can see, EPE segment can be found in both topologies (bgp-ls-epe and l3-unicast, meaning it can be used to build SRTE paths).

Last, we can check what routes were created:

root@r4a> show route protocol bgp-ls-epe

inet.0: 20 destinations, 21 routes (20 active, 0 holddown, 0 hidden)

inet.3: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)

iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)

mpls.0: 19 destinations, 19 routes (19 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

1000451            *[BGP-LS-EPE/170] 1w5d 18:29:46
                    >  to 192.168.45.1 via ge-0/0/2.0, Pop
1000451(S=0)       *[BGP-LS-EPE/170] 1w5d 18:29:46
                    >  to 192.168.45.1 via ge-0/0/2.0, Pop

inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)

lsdist.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

NODE { AS:100 BGP-LS ID:100 IPv4:100.4.4.4 BGP-LS-EPE:0 }/1216
                   *[BGP-LS-EPE/170] 1w5d 00:57:08
                       Fictitious
NODE { AS:100 BGP-LS ID:100 IPv4:200.4.4.4 BGP-LS-EPE:0 }/1216
                   *[BGP-LS-EPE/170] 1w5d 00:57:08
                       Fictitious
LINK { Local { AS:100 BGP-LS ID:100 IPv4:100.4.4.4 }.{ IfIndex:336 } Remote { AS:200 BGP-LS ID:100 IPv4:200.4.4.4 }.{ IfIndex:0 } BGP-LS-EPE:0 }/1216
                   *[BGP-LS-EPE/170] 1w5d 00:57:08
                       Fictitious

• We have a route in mpls.0 for label 1000451 that simply tells to send packet to r4b (192.168.45.1)
• we have routes into lsdist.0: the two nodes of the inter-domain link and the link itself

Table lsdist.0 has those routes because we configured the ted-to-bgp policy accordingly:

set policy-options policy-statement ted-to-bgp term ok from protocol bgp-ls-epe
set policy-options policy-statement ted-to-bgp term ok then accept
set policy-options policy-statement ted-to-bgp then reject

We also need this knob so to download l3-unicast data into lsdist.0 rib:

protocols mpls traffic-engineering database import l3-unicast-topology bgp-link-state

Finally, we can advertise those routes via BGP-LS.

As you might imagine, this is just a piece of a bigger puzzle. We said the primary reason to define EPE neighbors is to have the inter-domain link modeled as an adjacency segment.
This suggests us the final goal might be to create an inter-domain SRTE path…and that’s exactly where we are headed…

but before that, we still need one more piece: express-segments. Next time!

Ciao
IoSonoUmberto