[j-nsp] Longest Match for LDP (RFC5283)

[James Bensley]

On 24 July 2018 at 14:35,  <adamv0025 at netconsultings.com> wrote:
> Hi James

Hi Adam,

> Suppose I have ABR advertising default-route + label down to a stub area,
> And suppose PE-3 in this stub area wants to send packets to PE1 and PE2 in
> area 0 or some other area.
> Now I guess the whole purpose of "Longest Match for LDP"  is to save
> resources on PE-3 so that all it has in its RIB/FIB is this default-route +
> LDP label pointing at the ABR.
> So it encapsulates packets destined to PE1 and PE2 with the only transport
> label it has and put the VPN label it learned via BGP from PE1 and PE2 on
> top and send the packets to ABR,
> When ABR receives these two packets -how is it going to know that these are
> not destined to it and that it needs to stitch this LSP further to LSPs
> toward PE1 and PE2 and also how would it know which of the two packets it
> just received is supposed to be forwarded to PE1 and which to PE2?
> This seem to defeat the purpose of an end-to-end LSPs principle where the
> labels stack has to uniquely identify the label-switch-path's end-point (or
> group of end-points)
> The only way out is if ABR indeed thinks these packets are destined for it
> and it also happens to host both VRFs and actually is advertised VPN
> prefixes for these VRFs to our PE-3 so that PE-3 sends packets to PE1 and
> PE2 these will land on ABR ain their respective VRFs and will be send
> further by ABR to PE1 and PE2.

^ This is exactly my problem with this feature. It only works if
directly above the transport label is the IP payload (e.g. in your
topology, PE3 is sending traffic inside the global routing tablet /
inet.0), then we need to store fewer prefixes + labels for transport
of GRT traffic. For MPLS VPN traffic as you say, the ABR needs all the
routes (for L3 VPNs), must be IPv6 capable in the case of IPv6 VPNs,
and the ability to do L2 VPN stitching to support inter-area L2 VPNs.
This is quite a lot of extra work for the ABR just to save TCAM/FIB
space on PE-3.

> In the old world the PE-3 would need to have a route + transport label for
> PE1 and PE2.
> Options:
> a) In single area for the whole core approach, PE3 would have to hold these
> routes + transport labels for all other PEs in the backbone -same LSDB on
> each host requirement.
> b) In multi-area with BGP-LU (hierarchical MPLS) we could have ABR to
> advertise only subset of routes + labels to PE-3 (or have PE-3 to only
> accept routes it actually needs) -this reduction might suffice or not, note:
> no VPN routes at the ABR.
> c) I guess this new approach then further reduces the FIB size requirements
> on PE-3 by allowing it to have just one prefix and transport label  (or two
> in case of redundant ABRs), but it increase requirements on ABRs as now they
> need to hold all VPN routes -just like RRs (i.e. require much more FIB than
> a regular PE).

^ Agree with all of the above.
Opt1 doesn't scale well.
Opt2 scales better, you could only accept the /32s you need on each PE
but now you need per-pe loopback filters :(
Opt3 doesn't scale well either. If your topology is AREA_1 -- AREA_0
-- AREA_2, then the ABR on the area 1/0 boarder must carry all the
service VRFs/prefixes/labels for all PEs inside area 1 and 2, so that
an LSP can stretch from a PE inside area 1 to a PE inside area 2 and
that ABR (and the area 0/2 ABR) can perform service label swap. This
goes for any area 0 ABR, and the more areas you have the worse it
gets, those area x/0 ABRs must carry all service prefixes/labels from
all areas. So this obviously isn't a scalable approach.

So what is the use case of this feature?

All I can see if for a label switching a default route inside the
GRT/inet.0 from access PE to an access PE in another area. Similar to
the Cisco IOS command "mpls ip default route" which allocates a label
for the default route in LDP (default is no label).

Cheers,
James.