> So we desperately need a viable IGP summarization And could you elaborate on how summarization is going to work with Segment Routing ? Not that I am pushing anyone to go there, but looking through the window this seems to be the current trend.
We rely on leaking as additional information is attached to host routes. Stopping that breaks the game. And btw LDP FECs where always host routes + label so unlike you say - nothing new needed there. As I recall even TDP was carrying host addresses with tags. Thx, R. On Sun, Nov 21, 2021 at 3:46 AM Gyan Mishra <[email protected]> wrote: > > 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 <[email protected]> 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 <[email protected]> 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 [email protected] <[email protected]>* >> >> >> >> *M 301 502-1347* >> >> -- > > <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions A**rchitect * > > *Email [email protected] <[email protected]>* > > > > *M 301 502-1347* > >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
