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

[adamv0025 at netconsultings.com]

Hi James

> Of James Bensley
> Sent: Tuesday, July 24, 2018 11:17 AM
> 
> Hi All,
> 
> Like my other post about Egress Protection on Juniper, is anyone using
what
> Juniper call "Longest Match for LDP" - their implementation of
> RFC5283 LDP Extension for Inter-Area Label Switched Paths (LSPs) ?
> 
> The Juniper documentation is available here:
> 
> https://www.juniper.net/documentation/en_US/junos/topics/concept/long
> est-match-support-for-ldp-overview.html
> 
> https://www.juniper.net/documentation/en_US/junos/topics/task/configur
> ation/configuring-longest-match-ldp.html
> 
> As before, as far as I can tell only Juniper have implemented this:
> - Is anyone use this?
> - Are you using it in a mixed vendor network?
> - What is your use case for using it?
> 
> I'm looking at IGP/MPLS scaling issues where some smaller access layer
> boxes that run MPLS (e.g. Cisco ME3600X, ASR920 etc.) and have limited
> TCAM. We do see TCAM exhaustion issues with these boxes however the
> biggest culprit of this is Inter-AS MPLS Option B connections. This is
because
> Inter-AS OptB double allocates labels, which means label TCAM can run out
> before we run out of IP v4/v6 TCAM due to n*2 growth of labels vs
prefixes.
> 
> I'm struggling to see the use case for the feature linked above that has
been
> implemented by Juniper. When running LDP the label space TCAM usage
> increments pretty much linearly with IP prefix TCAM space usage.
> If you're running the BGP VPNv4/VPNv6 address family and per-prefix
> labeling (the default on Cisco IOS/IOS-XE) then again label TCAM usage
> increases pretty much linearly with IP prefix TCAM usage. If you're using
per-
> vrf/per-table labels or per-ce labels then label TCAM usage increases in a
> logarithmic fashion in relation to IP Prefix usage, and in this scenario
we run
> out of IP prefix TCAM long before we run out of label TCAM.
> 
> My point here is that label TCAM runs out because of BGP/RSVP/SR usage,
> not because of LDP usage.
> 
> So who is using this feature/RFC on low end MPLS access boxes (QFX5100 or
> ACX5048 etc.)?
> How is it helping you?
> Who's running out of MPLS TCAM space (on a Juniper device) before they
> run out of IP prefix space when using LDP (and not RSVP/SR/BGP)?
> 
I certainly was not aware of this one,
Interesting concept I'm guessing for OptB in Inter-Area deployments? (or a
neat alternative to current options?),

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.
 
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). 

I guess running out of FIB due to share size of the MPLS network can happen
in environments where you have just a few VRFs per PE with just a few routes
each but you have 10s or 100s of thousands of PEs, -it's a toll of MPLS all
the way down to the access layer -that's partly why they came up with
MPLS-TP. 

adam  

netconsultings.com
::carrier-class solutions for the telecommunications industry::