Route Reflector not reflecting BGP-LU (Labelled Unicast) prefixes

Question

I was reading about the Inter-AS MPLS VPN Option C from book ' MPLS in the SDN Era' . In it , the author establishes the BGP-LU peering between PEs and ASBRs and between RR and ASBR only.No BGP-LU peering between PEs and RR.

There is only VPNv4 BGP peering between PEs and RRs.

The reason author mentioned this in bullet point is below (copied from the book 'MPLS in the SDN Era'):

The RRs do not reflect BGP-LU prefixes. The only reason why they negotiate the IPv4-LU address family is for inter-AS RR reachability.

Can someone please explain why RRs dont reflect the BGP-LU prefixes? Many Thanks

Answer 1

To simplify the explanation, let's just pretend that only RR1 and RR3 exist (and let's forget about RR2 and RR4 for a second).

Similarly, let just pretend ASBR1 and ASBR3 are the only ASBRs (and let's forget about ASBR2 and ASBR4 for a second).

There is an EBGP session between RR1 and RR3, to exchange the IP VPN routes between the two ASs.

That means that there is a TCP connection between RR1 and RR3.

That means that there needs to be IP reachability between RR1 and RR3: RR1 needs to have an IP route to the loopback of RR3, which is in a different AS. And vice versa.

AS 65100 and AS 65101 are only exchanging labeled unicast routes with each other.

That means that ASBR1 must be advertising a labeled unicast route for RR1 to ASBR3.

Similarly, ASBR3 must be advertising a labeled unicast route for RR3 to ASBR1.

The cleanest way to achieve that is if RR1 advertises a labeled-unicast route for its own loopback to ASBR1, and if RR3 advertises a labeled-unicast route for its own loopback to ASBR3.

That way, we have a labeled-unicast route all the way from RR1 to RR3 and vice versa.

I have not set up a lab to verify this, but I don't think it is absolutely required to have a labeled unicast session from RR1 to ASBR1 and from RR3 to ASBR3. It just makes things more consistent and cleaner.

If you only had a normal IP unicast session between RR1 and ASBR1 (and RR3 and ASBR3) I strongly suspect that things would still work. In that case, we would only label switch the packets of the BGP TCP session up until the ASBR, and then do normal forwarding from there. The ASBR could receive a normal IP unicast route from the RR, bind an in-label (which may be the PHP implicit null label) and propagate the route as a label unicast further upstream.

But again, as I said, I haven created a test lab to verify that suspicion.

Answer 2

Let me try to answer this question. I guess there is a reason why the author configure only BGP-LU session between RR <---> ASBR and between PE <---> ASBR. The reason which I think is that there is already running IGP and some label distribution protocol within the AS. So we can also establish BGP-LU sessions between RR and all other routers in the AS just like normal route reflector.

Now RR will be having BGP-LU session with PEs and ASBRs. RR would also have IPv4 and VPNv4 peering with PEs as well. We can configure PEs to advertise their loopback IPs as BGP-LU routes (BGP + Label) to the RR so that it reflect this route to other routers in the same AS.

In this case RR would not reflect PEs loopback IPs as BGP-LU routes because the best route is via IS-IS not via BGP because of route preference. Hence to avoid extra peering (BGP-LU) between PEs and RRs , only PEs and RR need BGP-LU peering with ASBR because ASBR would then advertise the BGP-LU route as a BGP-LU route to the ASBR and create MPLS Label in/out entry in CEF/FIB. The BGP-LU peering between RR and PE can be established (no issue with it) but LSP utilized will be one that is from LDP/RSVP which are dependent on IGP and not BGP.

RR in one AS would have LSP to the other RR in other AS by virtue of fact that there is only BGP-LU peering between ASBRs in Option C.

However in case of RR having BGP-LU session with other PEs and ASBRs in the AS , RR would still advertise the BGP-LU route it receives from the ASBR (the route itself belong to the other AS) because in this case RR would have only one entry in its routing table which it would reflect to all PEs in its AS.