Hi Tony On Mon, Mar 8, 2021 at 7:22 PM Tony Li <[email protected]> wrote:
> > Hi Aijun, > > > > There are two scenarios as introduced by Gyan: one is the node > failure(Scenario 1), and another is the link failure(Scenario 2). > > > > For scenario 1, also when all ABRs can’t reach the specified address, it > is not efficient to advertise all of other detail prefixes when only one > prefix or some prefixes are missing. The ABRs tell exactly the specified > failure prefixes via PUA message is reasonable. > > > If no ABR can reach the address, then there is no point in advertising > anything. The traffic is going to black hole. > > > > > For scenarios 2, because the specified prefixes can be accessed via > another ABR, then we can let this ABR to advertise the details prefixes > information for the specified address, which behavior is similar with RIFT, > as also mentioned in the presentation materials. > > > Agreed. > > So, why do we need to punch a hole? Gyan> The goal of the solution is to be able to take advantage of summarizing LPM match using MPLS LDP inter-area LSP extension of VPN overlay next hop attribute /32 host route so that in larger domains with 1000s of PEs that domain wide flooding of host routes can be eliminated per RFC 5302 impacts of domain wide flooding. The prefix is the egress PE next hop attribute for VPN overlay component prefix that becomes unreachable due to a link or node failure. All BGP next hop attributes for VPN overlay are being summarized so LPM summary FEC binding must be used to route the traffic. As all the BGP next hop attribute for vpn overlay are summarized as is the goal to mitigate domain wide host route flooding, the next hop attribute host routes component prefixes cannot be advertised. That is the problem we are trying to solve with PUA signaling of the component prefix being down using the prefix originator Sub TLV RFC 7794 setting to null0 and flooding using Normal procedures to force control plane convergence to alternate egress PE next hop for the LSP to properly re-route. > > > Tony > > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
