Tony I agree with Peter that the job of the IGP is to provide reachability of all prefixes within the routing domain independent of mask.
So the optimization we are looking for is simply trying to make summarization LPM match instead of exact match possible with MPLS within an AS flooding of all host routes is done for LSP to build within an AS, however the domain wide flooding issue gets exacerbated with seamless MPLS for E2E LSP Core end Aggregation layers for Access layer E2E LSP. RFC 5283 provides a LDP inter area extension however the specification shifts the problem from the IGP RIB/FIB to the MPLS LFIB. So we don’t have a solution to be able to track component prefix host routes that are part of a summary route to make summarization a viable solution for MPLS. This would allow us to use the RFC 5283 inter area LDP extension and not have to flood the host routes into MPLS LFIB so can be suppressed with LDP filter once we are able to track the component prefixes that are part of the LPM summary FEC. This solution would also help speed up convergence for LPM summarization for IP based networks as well as SRv6. Kind Regards Gyan On Fri, Nov 19, 2021 at 12:03 PM Peter Psenak <ppse...@cisco.com> wrote: > Hi Tony, > > On 19/11/2021 17:55, Tony Li wrote: > > > > Hi Peter, > > > >> yes, but it's not specific to flat areas. Even in multi-area > >> deployments the host routing is mandated by MPLS. 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. > > > > > > Please re-read what you just wrote. The fact that someone decided to > > leak host routes is NOT something that the IGP was designed to do. > > Leaking negative updates is also wrong. Two wrongs don’t make a right. > > host routes are just routes, like any other routes, for which IGP > provide reachability. What's the length of the mask does not really > matter. The fact that they are used for liveness by some application is > also transparent to IGP. > > > > > > The fact that it is effectively providing liveness is wholly irrelevant. > > It’s still the wrong thing to do. > > well, then I guess we just agree to disagree. > > thanks, > Peter > > > > > > >> If IGPs can provide full liveness service between PEs today, why doing > >> 'optimized negative liveness service' would be architecturally wrong? > > > > > > IGPs could also deliver web pages. Capability doesn’t imply that it’s > > architecturally appropriate. The IGP is supposed to provide reachability > > and path computation at local scale and with stability. That’s it. One > > might well argue that we’re not doing that very well yet. Maybe we > > should stick to our knitting. > > > > T > > > > -- <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
