Most all operators have not deployed RFC 5283 LDP inter area extension due to the fact that it shifts the seamless MPLS flooding requirement and scalability problem from the RIB/FIB to the LFIB.
So we desperately need a viable IGP summarization solution mitigate domain wide flooding of host routes. Gyan On Sat, Nov 20, 2021 at 9:17 PM Gyan Mishra <hayabusa...@gmail.com> wrote: > > Robert > > RFC 5283 provides LDP extension for inter area for LPM summary FEC however > in this specification the component prefixes are probated via LDP which is > how the LDP inter-area extension is able to support summarization. > > The problem here is you make IGP scalable with this LDP inter-area > extension but then you pass the buck to MPLS which now is not scalable as > all the flooded prefixes are summarized in the IGP but now the LFIB has to > suffer from the domain wide flooding. > > This issue with domain wide flooding gets much worse with seamless MPLS > with E2E LSP requirements from core to aggregation layer so now all the > area and levels within the entire domain had all host routes. This can be > pretty tremendous for large operator networks and a huge scalability issue > that needs a solution. > > See section 7.2 > > The solution documented in this document reduces the link state database size > in the control plane and the number of FIB > entries in the forwarding plane. As such, it solves the scaling of > > pure IP routers sharing the IGP with MPLS routers. However, it does > not decrease the number of LFIB entries so is not sufficient to solve > the scaling of MPLS routers. For this, an additional mechanism is > required (e.g., introducing some MPLS hierarchy in LDP). This is out > of scope for this document. > > > Bottom of section 7.2 > > > For protocols and applications which need to track egress LER > availability, several solutions can be used, for example: > > - Rely on the LDP ordered label distribution control mode -- as > defined in [LDP <https://datatracker.ietf.org/doc/html/rfc5283#ref-LDP>] > -- to know the av.ailability of the LSP toward the > > egress LER. The egress to ingress propagation time of that > unreachability information is expected to be comparable to the IGP > (but this may be implementation dependent). > > - Advertise LER reachability in the IGP for the purpose of the > control plane in a way that does not create IP FIB entries in the > forwarding plane. > > > Gyan> So for this to work for egress convergence availability tracking you > either are back to flooding the routes in the IGP or use LDP ordered label > distribution. > > > Even if you used LDP ordered label distribution is still does not solve the > problem of robbing Peter to pay Paul now dumping the flooding of host routes > on MPLS LFIB making it not scalable. > > > Most vendors by default use LDP ordered label distribution defined in RFC > 3036. > > > However, net-net the problem is not solved. > > > > > Kind Regards > > Gyan > > On Fri, Nov 19, 2021 at 3:25 PM Robert Raszuk <rob...@raszuk.net> wrote: > >> Peter, >> >> >>> yes, but it's not specific to flat areas. Even in multi-area deployments >>> the host routing is mandated by MPLS. >> >> >> In the early days of MPLS yes that was the case. >> >> But that "mandate" was fixed by Ina, Bruno and Jean-Louis in 2008 :) >> >> https://datatracker.ietf.org/doc/html/rfc5283 >> >> In these multi-area deployments >>> the host routes are sent everywhere, updates are triggered regardless of >>> the failure type. IGPs are effectively providing liveness service >>> between PEs in any MPLS network. >>> >> >> That is true too - as folks just do not know how to configure BGP >> properly (if BGP is used for services). >> >> That leaves us the space what to do where there is no BGP carrying >> services. Or BGP implementation is broken and can not do the right thing. >> >> For the pulse proposal - no one answered the question posted what is a >> definition of mass failure. But maybe that will be the secret sauce of a >> vendor :) ? >> >> The fact that we are all in agreement that some network events will not >> work that well with the proposed solution seems to be a sufficient reason >> for me to consider different solution(s). >> >> Thx, >> R. >> > -- > > <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions A**rchitect * > > *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* > > > > *M 301 502-1347* > > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* *M 301 502-1347*
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
