Re: Intra-AS Routing Standards
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Intra-AS Routing Standards



Frankly, have the same metrics, same areas, and same authenication info (if any) 
for the same wires but for different protocols and different external 
connection topologies strikes me as a bad thing.  NASA for example has a
set of dedicated IP connections, dedicated DECNET connections, and shared
connections.  When things are shared, the metrics on such links are not set at all
alike.  In fact, the backbone topologies are different, because the external
connections to other IP and DECNET nets are in different places.  If I had to use
the same metrics for IP and DECNET, I'd have to go through and completely change 
how the whole system is put together to make this work.

I think similar arguments can be made for OSI.  Further, let me say that because
IP has the old venerable EGP2 protocol to use between systems, and that DECNET
and OSI do not, people tend to (or will tend to in the OSI case) to make the
routing domains much larger to compensate for the lacy of a dynamic inter-AS
routing protocol.  Thus what's a AS tends to be very different.  All this
makes it a nightmare to share common topological features (such as metrics and
area boundaries).  

If you think running an integrated protocol will save you a lot of management
hassles, I have a tip on a good savings and loan for you!

						Thanks,
						   Milo

PS I'll also speak up that I'd like a OSI protocol optimized for OSI, and
an IP protocol optimized for IP.  The 2 protocols have very different
architectures (like OSI having to route to end systems for example), and
this causes people to optimize for different things when building protocols
to support them.  It's not that I don't think IS-IS isn't a good protocol, it is,
it's just I don't want to comprimise my IP routing for some dubious advantages.




Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.