...

That's not a fault of the router vendor, or the software.

Stipulated. but neither of those excuses protect the net.

Not concerning with protecting the 'Net. The 'Net should be protected by cluefull ISPs. Your idea is to waste CPU cycles to prevent people from reading the manual.

I've yet to have anyone explain to me why adding a requirement to tell the router that a given port has other routers behind it, instead of hosts, "won't work in many, many implementations"... by which I assume you mean many networks, rather than many router brands.

You obviously fail to understand corporate networks. Since corporate networks are still 90-9?% of the router business, your requirements for what the 'Net needs are irrelevant. (also irrelevant since the functionality is there. You just have to RFTM..)

...

Not enough reason. Small picture. Pretty silly proposition. I can think of many better propositions, with much better reasons, that I'd rather see put forward.

Pointers?

Replace BGP with PATH metrics and congestion info. More intelligent route filters More adaptive response to route table fluctuations. Defined backups when routing table destablizes. Automatic local priority updates when routing table fluctates (Bay has it, noone else does). Defined actions for loss/gain of specific routes. Better path info update in OSPF. Common path info exchange in OSPF (wake up Cisco) Cleaner route switching in OSPF. On-Demand SVC Frame Interfaces. Real code, real purpose, real function. Not code to prevent people from reading the manual. -- Joe Rhett Systems Engineer JRhett@ISite.Net ISite Services PGP keys and contact information: http://www.navigist.com/Staff/JRhett