This is not a critique at Tony's points, but there is one dangerous thought: On Mon, 27 Nov 1995, Tony Li wrote:
[Sorry for being late in responding, I've been on vacation...]
Let me start by pointing out that the global problem here is to
... stuff deleted
Using this, we can begin to characterize the behaviors that we'd like. Clearly, during T_{down}, we have a problem: we have no route and (as the interesting part of the problem is in the default-free portion of the net), we have no other shorter prefix for it. One can then either drop packets or forward them along the old route anyhow. The Internet philosophy has always been to drop packets as quickly as possible, as close to the source as possible. The alternative is to forward the packet anyhow, hoping that the packet is not forwarded into a sustained forwarding loop. As the routing protocols aren't truly
well, this is not really an alternative, I would say. It will certainly go into a routing loop for the first some packets until a sink route (if implemented at all) takes over: talk about potentially a whole T1 bandwidth go for max ttl: that's a blackout fo reverything else. I would realy not argument here with hopes, but with sanity, and not flood meetpoints or distant distribution POPs with packets. The stratey to drop as near to the source as possible should be made a must in all implementations. I would even say, nobody may forward otherwise, since I would not like to have a ring full of trashing packets when a customer goes down.
architected to protect against such a forwarding loop, the latter
the loop will occur at least for a transition time until a sink route takes effect (like loopback pullup or else). Mike
behavior seems risky. The implication is that during T_{down}, the infrastucture will drop packets from all sources to the destination.
Next, consider T_{recover}. As no one has invented FTL hardware (yet ;-), T_{recover} is non-zero on all interesting architectures that I know of. Further, during T_{recover}, packet loss should also be expected. This includes the case of a router which fully distributes the routing table, as the distribution itself takes finite time. What then are interesting values for T_{recover}? Clearly, \infinity is unacceptable. If T_{recover} << T_{down}, it hardly seems relevant. What then is an acceptable upper bound? And what is the sensitivity of this value? I leave this as an open question for discussion...
Selective packet discard (a new method we're putting in for prioritizing routing protocol packets over transit packets) will insure that T_{recover} is finite, and based on our lab tests, what I consider to be acceptable. I should note in fairness that credit for driving selective discard should be given to both Sprint and ANS. The former for demonstrating the need in the real world, the latter for focusing cisco's management on the subject.
I'd also like to correct some misperceptions that have been distributed:
- Distributing the full routing table is not the only way to achieve acceptable response to interesting flap. If someone has a technical argument suggesting that this is the only true way, then we have missed hearing it, and we'd really apprecaite it if you could tell us again. In detail.
- Distributing the full routing table to the SSE is not a logical way to proceed. For both obvious and non-obvious reasons, spending significant resources developing software for the 7000 at this point makes little sense, and without some convincing argument that it would move T_{recover} from the unacceptable to the acceptable, is beyond the bounds of rationality.
- The interesting flap rate introduced by end users can be controlled by deployment of CIDR. I trust no one on this list remains to be convinced.
- Certain statements about communications of problems to cisco mentioned in this forum have been patently incorrect. Sending a mail message to your favorite engineer saying "when will you do XYZ" is not a reasonable way to insure that you're mission critical business feature is being implemented. Still, if you believe you've attempted to communicate with us and you don't think we got the message, then we can only ask that you have patience, increase your retry count, and retransmit. We can't neccessarily do what you might like, but we can hear you and acknowledge your concerns.
Finally, I'd like to echo what Dennis said: we're all behind the eight ball, and we all know it. Recriminations are much less interesting than solutions. What should MCI & Sprint do? Well, let's just say that we've privately offered them our opinions, and they don't seem to object too strenuously. Assuming that things actually go that way, well, "You ain't seen nothing yet, baby."
Tony
p.s. I'm not on the mailing list, so please cc me if you wish me to respond.
---------------------------------------------------------- IDT Michael F. Nittmann --------- Senior Network Architect \ / (201) 928 1000 xt 500 ------- (201) 928 1888 FAX \ / mn@ios.com --- V IOS