ops-dir feedback on routing protocol abuse

[Alex Zinin <zinin@psg.com>]

  FYI below.
  I should have a summary from rtg-dir and a proposed
  text of the IESG position by the telechat.

-- 
Alex
http://www.psg.com/~zinin/


 General analysis:

  1. BGP is part of the Internet's critical infrastructure,
     whose failures would severely affect the operations of
     the Internet.

  2. Overloading of BGP increases the likelihood of problems
     appearing in the original protocol and the Internet
     routing system, because of the following potential reasons:

       a. Increasing size of the code
       
       b. Increasing complexity of the code
       
       c. Increasing memory and BW requirements
       
       d. Interference between the original BGP code and it's
          "applications" due to implementation flaws. At a minimum in
          terms of memory usage and CPU utilization, and more direct
          if code is reused.)

       e. Interference between the Internet BGP routing system and
          other BGP-application specific distributed systems

  3. It is not clear that the above problems will appear for sure,
     however, given the importance of BGP for the Internet, the burden
     of proof that they will not should be on the proponents of the
     new BGP applications.

 Recommendations:

  1. Changes made to the Internet-critical protocols such as BGP
     should not be taken lightly. The following conditions should
     be met before changes are accepted:

       a. Reason for a change should be carefully described
          and agreed upon. Specifically, if the application
          is not obviously routing-related, justification should
          be provided as to why a particular routing protocol
          is the right choice.

       b. Operational impacts should be characterized, with
          the analysis of potential failure modes and their
          mitigation

       c. Changes to the deployment scenarios should be identified
          and analyzed to see how protocol characteristics may be
          affected

     Ideally, changes should not be admitted to the protocol unless
     it has been proven that they will do no harm to the existing
     Internet infrastructure, as opposed to a lack of proof that
     they will do harm.

  2. In the particular situation with non-routing application of BGP
     as used for VPN membership discovery and L2 VPN signaling, a
     careful analysis should be performed to see if BGP protocol
     framework is the best fit for the problems that need to be
     solved.

  3. If the conclusion is that the BGP framework is a good fit for
     these problems, the recommendation is to clearly separate
     BGP as used today for Internet routing from the BGP framework
     used for non-routing functions. This should be done by
     instantiating a new protocol, that would inherit the BGP
     functions most interesting for introduced functionality, yet
     would have its own name, transport protocol ports, and would
     explicitly not interoperate with what is known as BGP today.