draft of rtg-dir feedback on routing protocol overloading

[Alex Zinin <zinin@psg.com>]

below is the first draft summary of the rtg-dir discussion.
some changes are likely, but good enough for us to talk.

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

On the question of appropriate and inappropriate use of routing
protocols in general, and BGP in particular.

 1. Routing protocols are generally designed with specific assumptions
    in mind about the amount of information that needs to be
    distributed, the frequency of its changes, and it's nature. These
    assumptions influence such characteristics of the routing
    protocols as required bandwidth, CPU utilization, convergence
    times, as well as the overall protocol scalability.

 2. Hardware and software of the Internet routers have been carefully
    fine-tuned over the years to ensure adequate routing stability and
    convergence characteristics of the SP networks and the Internet as
    a whole. Particular care has been taken to minimize unnecessary
    routing protocol packet drops, high CPU utilization, excessive
    memory consumption, distributed instabilities (such as flooding
    storms.)

 3. Routing protocols in general SHOULD NOT be treated as a general
    purpose reliable multicast transport system because of the
    following aspects:

      a) when used for an arbitrary application, the fundamental
         assumptions (see bullet 1 above) may not hold true any more,
         and the scalability of the protocol may be affected

      b) if implemented and deployed in a tightly-coupled fashion
         with the Internet routing system (sharing the same transport
         and protocol sessions, internal router infrastructure, databases,
         etc.), additional applications of the routing protocols may start
         competing for resources (see bullet 2 above) and thus affect
         behavior and scalability of the Internet routing system.

    While the right design choices may prevent undesired effects, it
    is hard to foresee all possible interactions, and so the
    probability of a failure is increased.

 4. Generally, the decision on whether a particular type of
    information belongs in a routing protocol or not should be made on
    a case-by-case basis. However, it is considered appropriate to
    distribute the following types of it in the routing protocols:

      a) information required to calculate the routing tables

      b) route tagging, administrative, and policy-related information

      c) security-related information

      d) information closely related to routing, especially when
         synchronization with routing information is needed

    Note that even for the cases above, a careful analysis must be
    performed to show that the volume and frequency of the information
    will stay within reasonable bounds.

 5. For non-routing-related applications, the onus probandi lies with
    the proposers to show:

      a) why the use of a routing protocol is appropriate (and by
         inference, why some other mechanism isn't), and

      b) why this use cannot break the routing protocol

 6. If the framework used in a specific routing protocol is agreed to be
    a good fit for a non-routing application, and synchronization with
    the routing information is not an issue, it is recommended that
    potential interference with the Internet routing system is avoided
    by using a separate instance of the protocol (or, obviously, by
    instantiating a new protocol with a similar framework.)

On whether the specific approaches described in the documents above
represent an appropriate use of BGP:

 7. From the purely encoding and dynamics perspective (not taking
    into considerations potential interactions with the Internet
    routing system), and from the perspective of the BGP's general
    framework, rather than it's being an IP routing protocol, the
    following comments apply:

      a) NLRI overloading is considered slightly (though only
         slightly) problematic.

         Specifically, appearance of the TLVs in the NLRI field does
         not match the original of separation of keying information
         (prefixes) and their parameters in BGP. However, it is
         understood that, in a way, TLVs formalize representation of
         key-bound information.

         A cleaner approach would be to provide a mechanism to
         encode prefix-specific parameters outside the NLRI field.

      b) Extended communities normally used for policy purposes
         are used to distribute membership information. Thus, misconfiguration
         of policy on extended communities may potentially be hazardous to
         the correct operation of a VPN

      c) RSN TLV. It is not clear how often the contents of this
         TLV found in the NLRI field would change, and hence wether
         it would cause excessive updates or not.

      d) The documents should clearly specify what information is
         present in the MP-NEXTHOP field and how it is used

 8. However, the bigger concern is how introduction of this
    information in BGP would affect the Internet routing system.
    Steps described in bullet 5 above should be followed, and
    the VPN and BGP communities should consider separating the
    Internet routing BGP system from other, non-routing-related
    applications of the BGP framework (the VPN case included.)