Les,
> Summarization is used in the network. > But customer identifies a modest number of key nodes where it wants to detect > loss of reachability ASAP. Unfortunately, customer is unable to assign > addresses which are outside of the summary to these nodes. > Customer assigns admin tags to the prefixes of interest and asks the IGP > vendor to support advertising reachability to the tagged prefixes in addition > to the summary (even though they are covered by summary). > Are we still within the IGP set of responsibilities IYO? IMHO, no. You’re intentionally breaking summarization and advertising liveness. You can claim that it’s just reachability, but it’s not. If it were reachability, then you’d be ok with a static prefix assignment. > Now, if the ABR so configured loses reachability to one of the tagged > prefixes, what should it do? > Clearly, it needs to stop advertising reachability for that prefix. No, it doesn’t. Static summarization is the preferred approach. It’s stable. You may recall back in the ‘90s that we did dynamic advertisement and withdrawl in BGP. That quickly got frowned on because of the resulting churn. No different here. > What we propose is that if a customer wants to use summaries, they should > feel free to do so. But if they want faster detection of loss of reachability > to (some) destinations covered by the summary, there is a new advertisement > which provides this which avoids the ambiguities mentioned above. > Again, the IGP isn’t acquiring new information – it has always known this > information – it just hasn’t had a way to advertise this in the presence of > summaries. You’re propagating new information out of the area. And doing so at the wrong time. I would MUCH rather just leak the prefixes when things are working than add stress in failure modes. > And, the use of tagging to identify the prefixes which may be advertised > using the new mechanism is one way to deal with scale issues. How? If there are 10,000 tagged prefixes, how does that not become 10,000 negative leaks? Tony
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
