Subject: Summary on feedback to IESG on routing protocol overloading

From: Alex Zinin <[email-masked]>
Date: Wed, 9 Jul 2003 23:57:16 -0700

Folks-

 Please find below the summary of the discussion we had. Pay specific
 attention to recommendations (bullets 4, 5, 6, and 8). Shout if I
 misrepresented something or you'd like to change some words,
 pls.--quite possible that I missed something, as it's late here.

Alex

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.)

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 10 Jul 2003 09:56:22 -0400

>          behavior and scalability of the Internet routing system.

We should be careful of what we may step in here, in the sense of
stepping in something in a farm yard.  The concept of "tightly
coupled" and "loosely coupled" is a somewhat arbitrary one in some
respects.

In a "loosely coupled" system, we now have the same resources that may
be used and abused as a "tightly coupled" system, but with a somewhat
clearer distinction between what information is meant for what part
of the system.  In the event of resource constraints, the ability
to gracefully fail will depend on the implementation.

The fact that in a "tightly coupled" system the same information may
be tagged and sent in a single protocol (or similar mechanism)
doesn't necessarily change the information or the graceful failure
mechanisms.  As a matter of fact, it *potentially* worsens some of
them since information that is required to be in synch no longer

>     instantiating a new protocol with a similar framework.)

We must also therefore avoid duplicating information.  There is no
sense in having two instances of something that looks like BGP, where
one carries "Internet routing information" and the other carries
"other information" and have that "other" carry another copy of the
Internet routing table.

Talk about scalability nightmare.

IMO, we must therefore recommend another step in this path:

Where information is meant to be coupled, a protocol mechanism should
be proposed, generically, that allows for coupling of the information.
Essentially, if we're going to go to the effort to "normalize" (in
the database fashion) our information, we must provide keying and
synchronization mechanisms between the protocols.

In the case of BGP, this might be accomplished through a keying
path attribute of some form.

The question then becomes, is the operational and coding consequences
of this worse than the original problem?

-- 
Jeff Haas 
NextHop Technologies

---

From: Alex Zinin <[email-masked]>
Date: Sun, 13 Jul 2003 03:47:51 +0200

Jeff-

 We seem to agree that for the cases where the "application"
 information is meant to be in sync with the routing info, putting it
 in the routing protocol may be the right way to go, given that
 all other conditions are satisfied, of course.

 See below regarding coupling.

> coupled" and "loosely coupled" is a somewhat arbitrary one in some

agreed

> of the system.

I think we should agree on the term "tightly coupled" within the
context of this discussion first. To me, tightly coupled means using
the same protocol, port, transport sessions, queues, databases,
threads, walkers, etc. So, if, for instance, the new BGP application
experiences a lot of activity, there is a potential that it will
compete for resources with the original BGP process. If this happens
at a large scale (multiple routers), the results could be interesting.

The positive side of using a different protocol (even with the same
machinery) is that the separation of those resources is more likely to
happen. Specifically, the protocol instance is likely to be
implemented as a different thread/process with it's own resources such
as memory pools, queues, timers, sockets, etc. So, while a complete
decoupling is hardly achievable while the two process are running on
the same system, the risk of interference should be lower.

> In the event of resource constraints, the ability

> has the tight coupling to ensure that it is.  Thus my next point:

Did you mean the second sentence to talk about loosely coupled rather
than tightly coupled system? If not, then you lost me here.

BTW, could you suggest changes to the text, please?

Alex