Single post
BGP link state, what is this ?
The latest version of « draft-ietf-idr-ls-distribution » has a meaningfull title :
« North-Bound Distribution of Link-State and TE Information using BGP »
So the goal is clearly to use BGP as a carrier for link state information, coming from the IGP.
From the above draft :
The contents of a Link State Database (LSDB) or a Traffic Engineering Database (TED) has the scope of an IGP area. Some applications, such as end-to-end Traffic Engineering (TE), would benefit from visibility outside one area or Autonomous System (AS) in order to make better decisions.
The document pursues with considerations regarding ALTO servers (see RFC5693 and RFC6708) and MPLS TE Path Computation Element use cases.
This is sometimes funny to see how we often make new things with rather old stuff, since ALTO stand for « Application Layer Trafic Optmization », and was standardized mid 2009, while PCE (RFC4655) is almost ten years old…
SDN before SDN…
The great thing about BGP-LS is that we can see in real time the full LSDB, or TED, without any intrusive adjacency inside the AS.
Here below some outputs from an IOS XR box.
OOoouuchh !! on first approach, this looks a bit cryptic :
*> [V][O][I0x0][N[c65210][b10.209.1.1][a0.0.0.0][r10.209.1.3]]/376 0.0.0.0 0 i *> [V][O][I0x0][N[c65210][b10.209.1.1][a0.0.0.0][r10.209.1.4]]/376 0.0.0.0 0 i *> [E][O][I0x0][N[c65210][b10.209.1.1][a0.0.0.0][r10.209.1.1]][R[c65210][b10.209.1.1][a0.0.0.0][r10.209.1.2]][L[i10.208.0.0][n10.208.0.1]]/792 0.0.0.0 0 i*> [E][O][I0x0][N[c65210][b10.209.1.1][a0.0.0.0][r10.209.1.1]][R[c65210][b10.209.1.1][a0.0.0.0][r10.209.1.3]][L[i10.208.0.2][n10.208.0.3]]/792 0.0.0.0 0 i
If we spend some time looking at the legend, this makes sense :
Prefix codes: E link, V node, T IP reacheable route, u/U unknown I Identifier, N local node, R remote node, L link, P prefix L1/L2 ISIS level-1/level-2, O OSPF, D direct, S static a area-ID, l link-ID, t topology-ID, s ISO-ID, c confed-ID/ASN, b bgp-identifier, r router-ID, i if-address, n nbr-address, o OSPF Route-type, p IP-prefix d designated router address Network Next Hop Metric LocPrf Weight Path !! "V" entries for nodes (router LSA) *> [V][O][I0x0][N[c65210][b10.209.1.1][a0.0.0.0][r10.209.1.1]]/376 0.0.0.0 0 i <snap> !! "E" entries for links *> [E][O][I0x0][N[c65210][b10.209.1.1][a0.0.0.0][r10.209.1.1]][R[c65210][b10.209.1.1][a0.0.0.0][r10.209.1.2]][L[i10.208.0.0][n10.208.0.1]]/792 0.0.0.0 0 i *> [E][O][I0x0][N[c65210][b10.209.1.1][a0.0.0.0][r10.209.1.1]][R[c65210][b10.209.1.1][a0.0.0.0][r10.209.1.3]][L[i10.208.0.2][n10.208.0.3]]/792 0.0.0.0 0 i <snap> !! "T" entries for routes *> [T][O][I0x0][N[c65210][b10.209.1.1][a0.0.0.0][r10.209.1.1]][P[o0x01][p10.208.0.0/31]]/488 0.0.0.0 0 i *> [T][O][I0x0][N[c65210][b10.209.1.1][a0.0.0.0][r10.209.1.1]][P[o0x01][p10.208.0.2/31]]/488
OK, now let’s look deeper into a link :
BGP routing table entry for [E][O][I0x0][N[c65210][b10.209.1.1][a0.0.0.0][r10.209.1.4]][R[c65210][b10.209.1.1][a0.0.0.0][r10.209.1.2]][L[i10.208.0.7][n10.208.0.6]]/792 Versions: Process bRIB/RIB SendTblVer Speaker 67 67 Last Modified: Jun 19 11:31:44.397 for 1d11h Paths: (1 available, best #1) Advertised to peers (in unique update groups): 10.248.85.79 Path #1: Received by speaker 0 Advertised to peers (in unique update groups): 10.248.85.79 Local 0.0.0.0 from 0.0.0.0 (10.209.1.1) Origin IGP, localpref 100, valid, redistributed, best, group-best Received Path ID 0, Local Path ID 1, version 67 !! Since this is an MPLS TE network, I can see attributes coming from Opaque LSA here below Link-state: Local TE Router-ID: 10.209.1.4, Remote TE Router-ID: 10.209.1.2 admin-group: 0x00000000, max-link-bw (kbits/sec): 10000000 max-reserv-link-bw (kbits/sec): 9200000, max-unreserv-link-bw (kbits/sec): 9200000 9200000 9200000 9200000 9200000 9200000 9200000 9200000 TE-default-metric: 2, metric: 1 RP/0/RSP0/CPU0:xxx01#
That works fine, now I check the above link in my offnet network controller, using a REST primitive :
<link>
<adminGroup>0</adminGroup>
<id>-899539664</id>
<localAddress ip="10.208.0.7" prefixLength="32"/>
<localRouter>
<identifier>10.209.1.4</identifier>
</localRouter>
<lost>false</lost>
<maxLinkBandwidth>1.0E10</maxLinkBandwidth>
<maxReservableLinkBandwidth>9.2E9</maxReservableLinkBandwidth>
<metric>1</metric>
<remoteAddress ip="10.208.0.6" prefixLength="32"/>
<remoteRouter>
<identifier>10.209.1.2</identifier>
</remoteRouter>
<unreservedBandwidth>9.2E9</unreservedBandwidth>
<unreservedBandwidth>9.2E9</unreservedBandwidth>
<unreservedBandwidth>9.2E9</unreservedBandwidth>
<unreservedBandwidth>9.2E9</unreservedBandwidth>
<unreservedBandwidth>9.2E9</unreservedBandwidth>
<unreservedBandwidth>9.2E9</unreservedBandwidth>
<unreservedBandwidth>9.2E9</unreservedBandwidth>
<unreservedBandwidth>9.2E9</unreservedBandwidth>
</link>
That’s perfect : LSDB/TED are reported transparently, and real time, using BGP link-state.
This data can then be used for several purposes :
– capacity planning, based on TE bandwidth attributes
– feed for offnet PCE or ALTO server
– feed for BGP FlowSpec, Segment Routing…
There are no comments for BGP link state, what is this ?