Hi Aijun, > Stuffing things in the IGP seems like a poor way of determining that there’s > a BGP failure. Wouldn’t BFD be a more appropriate way of determining the > loss of connectivity? Or aggressive BGP keepalive timers? > [WAJ] For BFD, you need to configure between each pair of them to track the > connectivity. For BGP keeplive times, the duration is too long.
You have to configure BGP on both sides too. Most implementations do allow you to change the timers. >> The other side of BGP peer can quickly remove the BGP session when it >> receives such PUA message which tell it the other peer is down now. Other >> BGP peer protection procedures can then take effects on. >> The immediate notification of the failure prefix can certainly accelerate >> the switchover of BGP control plane and also the service traffic that such >> BGP session carries. > > > The IGP is a very poor way of delivering service liveness information. > [WAJ] why? Because it’s not a service (un)availability protocol. It’s a reachability and path computation function. That is it’s role in the architecture. Asking it to do something else is a violation of the architecture. Routing protocols are not transport protocols. Or dump trucks. Or service advertisement protocols. > That seems 100% unnecessary as the longer prefix will attract the traffic in > the way that you want. > [WAJ] If the ABR advertises such detail prefix, it will certainly attract the > traffic. But here the PUA message is just to trigger the ABR to advertise > such detail prefix, or else, such ABR will still advertise the summary > address. You don’t need the PUA message. The ABR can see the loss of topology and can realize that it’s the best path to the prefix and can then advertise the explicit longer prefix in addition to the normal summary. Tony _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
