Re: Links on the blink - what will/should mci & sprint do?

[Mike <mn () tremere ios com>]

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