[j-nsp] RFC3107 to LDP stitching

[Krasimir Avramski]

Hi Adam,

Yes, bgp-igp-both-ribs is needed for transport LSP stitching on ASBRs.
BGP-LU works as follow:
If the route has label then select new label and perform swap.
If there is no label then select new label and perform pop - note for the
direct routes(such as loopback) implicit label 3 is used.

So, ISIS local AS PE routes are advertised and label operation POP is
programmed  - this exposes traffic with vpn labels (requested by local AS
PEs different from asbr ) to the ASBR itself and since such ip-vpn routes
are not advertised, upon label lookup they are dropped.
When  bgp-igp-both-ribs is configured the LDP, RSVP routes are already in
inet.0 so when redistributed, label operation SWAP is programmed (actual
LSP transport stitch).

Personally I prefer "rib inet.3" way - this should work in case you
establish both "inet" and "labeled-unicast" bgp families (actually rib
inet.3 is only way to do that). This will relax the need
of bgp-igp-both-ribs(when it is not desired since the change is global for
the router) and resolve-vpn and through the policies you
can granularly control what is advertised for data path stitching and what
for control plane purposes.(plane IP).

As per local PE functionality on ASBR are you sure you properly
redistributed local loopbacks through the bgp-lu - while I'm not 100% sure
it should work without explicit-null .... Do you have vrf-table-label in
VRF?

Regards,
Krasi

On 1 April 2015 at 01:48, Adam Vitkovsky <Adam.Vitkovsky at gamma.co.uk> wrote:

> Hi Folks,
>
> So for the RFC3107 to LDP stitching if ASBR is also a PE the working
> config for ASBR is as follows but I'm not sure why/how it actually works.
>
> set protocols mpls traffic-engineering bgp-igp-both-ribs
> set protocols bgp group nni-opt-c family inet labeled-unicast
> per-prefix-label (probably optional)
> set protocols bgp group nni-opt-c family inet labeled-unicast
> explicit-null connected-only
> set protocols bgp group nni-opt-c family inet labeled-unicast resolve-vpn
>
> Why do I need to use "bgp-igp-both-ribs" or possibly "mpls-forwarding"
> option (haven't tested that yet) to copy routes from inet.3 to inet.0 if
> I'm already using "resolve-vpn" and with "resolve-vpn" the primary table
> for RFC3107 routes is inet.0 and inet.0 already has the local AS PEs and
> RRs loopbacks in it, so those are advertised to the remote AS.
> It seems like the "bgp-igp-both-ribs" is necessary for the inet.0 or I
> should say mpls.0 <-> RFC3107 LSP stitching but I have no idea how/why.
>
> And also why the ASBR acting as PE won't accept packet with just the VPN
> label and there's this explicit-null label stack required.
>
> The "resolve-vpn" vs "rib inet.3".
> Ok so "resolve-vpn" option uses inet.0 as primary routing table and will
> just copy the RFC3107 labeled routes to inet.3 table.
> The RFC3107 labeled routes have be placed in the inet.3 routing table so
> that VRF routes from remote AS have NH in inet.3 for proper NH resolution
> (In case the ASBR is also a PE for a vrf spanning across the ASNs).
> Since inet.0 is still the primary table the remote-AS PE loopbacks can be
> advertised via ISIS to local AS RRs -i.e pure IP connectivity is in place
> so MP-eBGP can be formed.
> However with "rib inet.3" the inet.3 will become the primary routing table
> for RFC3107 routes.
> So then you need to manually leak routes from inet.3 to inet.0 using
> rib-groups the remote-AS prefixes (PE loopbacks) can be advertised via ISIS
> to RRs.
> However since inet.3 is the primary table only for RFC3107 session only
> routes in inet.3 are advertised from local AS to the remote AS and RR
> loopbacks are not in inet.3 which is a show stopper unless it's somehow
> possible to leak routes from inet.0 to inet.3.
>
> I'd appreciate any thoughts, ideas on how this actually works.
>
> adam
>
> ---------------------------------------------------------------------------------------
>  This email has been scanned for email related threats and delivered
> safely by Mimecast.
>  For more information please visit http://www.mimecast.com
>
> ---------------------------------------------------------------------------------------
>
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>