Hi, Chris: We have considered let BGP send the unreachable information in some situations(Robert is also trying to propose this?) But the key difference is that the host knows the reachability of sever via default route, not via BGP, then leak such information within is not helpful to the mentioned service. But BGP NH or Tunnel Endpoint is relying on the IGP, knowing such unreachable information can certainly help the converge or switch of the overlay service on top of them, for example BGP PIC performance.
Aijun Wang China Telecom > On Nov 21, 2021, at 16:26, Christian Hopps <[email protected]> wrote: > > > >>> On Nov 21, 2021, at 3:09 AM, Aijun Wang <[email protected]> wrote: >>> >>> Hi, Tony: >>> >>> Aijun Wang >>> China Telecom >>> >>>> On Nov 21, 2021, at 15:17, Tony Li <[email protected]> wrote: >>>> >>>> >>>> Hi Aijun, >>>> >>>>> The ABR should do the summary work based on the liveness, right? >>>> >>>> >>>> No. ABRs advertised statically configured prefixes for the area. Anything >>>> else would cause flap. And it’s purely reachability, not liveness. There >>>> can be zero live nodes within an area and the ABR should still advertise >>>> its summary. >>> >>> [WAJ] What the usage of the summary advertisement in such conditions >>> excepts it misleads the nodes within the area it attached? >> >> Perhaps it would help to consider another example of reachability vs >> liveness. Summaries are just one form of the more general concept of >> aggregation. Consider the Internet and aggregation done at the AS level. >> Would you have BGP flapping routes in the entire Internet based on hosts >> going up and down at the originating AS? No, we do not expect it. When you >> try to connect to a server in azure or aws etc you don’t expect routing to >> let you know that a server is down through an unreachable routing message, >> you expect TCP to tell you it can’t connect to it. >> >> Thanks, >> Chris. >> >> >>>> >>>> >>>> Pub/Sub style notification seems promising, but it will require the ABR >>>> store the subscription state which will certainly degrade its performance. >>> >>> >>> Baloney. A notification list address post-SPF is wholly outside of the >>> performance path. >> >> [WAJ] Is there any existing mechanism to accomplish your proposal among the >> PEs? >> >>> >>> >>>> On the other hand, let the receiver decides whether to utilize such >>>> information is distributed design and more robust? There is no much work >>>> to be done when they receive the PUAM message. Just to judge the >>>> originator of the prefix is valid or not. >>> >>> >>> Correct, you just flood information throughout the network that most of the >>> nodes don’t care about, burdening others with additional flooding and >>> database scale issues, just when there are failures. >> >> [WAJ] Within the network, the number of PEs often surpasses the number of P >> nodes. Even with P nodes, such information can also help them reroute/switch >> to other endpoints along the SRv6 tunnel backup path. >> I think you could imagine the signal just as the alert information that >> often seen on the highway. It can certainly save the driver’s time. Wouldn’t >> you like to know such information immediately? Or you just drive as planned >> until near the target to know the road is broken? >> >>> >>> Tony > > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
