Subject: Extending BGP

From: Ron Bonica <[email-masked]>
Date: Wed, 13 Aug 2003 18:32:55 -0400

Folks,

To date, I hear two sub-threads running through this discussion. One
sub-thread addresses software engineering, while the other addresses
Internet Architecture.

The software engineering thread revolves around the notions of "functions",
"protocols" and "software modules". Some have suggested that if we assign
too many functions to a protocol (BGP), we increase the complexity of its
supporting software modules beyond acceptable limits. Because BGP is central
to the well-being of the Internet, this causes Internet providers great
concern. Others have pointed out that the IETF's assignment of functions to
protocols does not dictate a vendor's assignment of those same functions to
software modules. Therefore, vendors can produce stable, modular
implementations of very complex protocols. (They can also produce less
stable, less modular implementations of simple protocols!)

As the mapping of functions to software modules is beyond the scope of the
IETF, I suggest that we not pursue this software engineering sub-thread.

As Pedro points out, another sub-thread addresses the Internet Architecture.
This sub-thread contains echoes of an older debate between the IP-centric
and the IP-convergence-minded. The IP-centric believe that the Internet
should provide IP services only. The IP-convergence-minded believe that the
Internet should support multiple services by tunneling through an IP
platform.

As it is not likely that we will settle this debate in this forum, I suggest
that we also not pursue this sub-thread, either.

So, what is there left to discuss? :-)

As we ask routers to do more things, we may need a generic database
synchronization mechanism whose capabilities are beyond those of BGP. For
example, it may require security, prioritization and convergence features
that are not currently supported by BGP.

If we take this opportunity to specify a new database convergence mechanism,
we could support these features. We could also specify the mechanism in
isolation from the many applications that will consume its services.

At this point, we might do well to examine whether we have enough new
requirements to justify the specification of an new, generic database
synchronization protocol. Maybe its time to bring this discussion from the
IRTF to the IETF?

===========================================
Ronald P. Bonica       Ph: 703 886 1681
vBNS Engineering       page: 1 888 268 8021
Ashburn, Va.
===========================================
"An eye for an eye only ends up making
the whole world blind."
            -- Gandhi

_______________________________________________
routing-discussion mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/routing-discussion