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

[Krzysztof Szarkowicz]

Hi,

The purpose of “Longest Match for LDP” is to be able to distribute /32 LDP FECs, if corresponding /32 routes are not available in IGP.
So, on ABR you inject e.g. default route into access IGP domain. ABR has /32 LDP FECs, and advertises this /32 FECs in LDP (but not in IGP) downstream into access domain. In access domain, LDP readvertises hop-by-hop these /32 LDP FECs, assigning the labels.

It is typically used with LDP DoD. On the other hand, however, nothing prevents you from having LDP policy on ABR to inject into access domain only specific /32 LDP FECs.

The same applies to IPv6 LDP FECs.

Thanks,
Krzysztof


> On 2018-Jul-25, at 09:25, James Bensley <jwbensley at gmail.com> wrote:
> 
> 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.
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp