[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
INTERNET-DRAFT                             D. Meyer (Editor)
Category                                       Informational
Expires: April 2004                             October 2003


                    Routing Protocol Overloading --
                  Issues, Concerns, and Considerations
                        <draft-meyer-rpo-00.txt>



Status of this Document

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   The key words "MUST"", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC 2119].


   This document is a product of the RPO Design Team.  Comments should
   be addressed to the authors, or the mailing list at
   rpo@lists.uoregon.edu.

Copyright Notice

   Copyright (C) The Internet Society (2003). All Rights Reserved.







Meyer, et. al.                                                  [Page 1]


INTERNET-DRAFT             Expires: April 2004              October 2003


                                Abstract


   The Routing Protocol Overloading (RPO) design team was formed to
   document the concerns and considerations surrounding the use of
   Internet routing protocols for functions not directly related to
   routing of IP packets within the Internet and IP networks. This
   document is the output of that activity.











































Meyer, et. al.                                                  [Page 2]


INTERNET-DRAFT             Expires: April 2004              October 2003


                           Table of Contents


   1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .   5
   2. Scope of this Work . . . . . . . . . . . . . . . . . . . . . .   5
   3. Problem Statement. . . . . . . . . . . . . . . . . . . . . . .   6
    3.1. Risk, Interference, and Application Fit . . . . . . . . . .   6
     3.1.1. Risk: Software Engineering . . . . . . . . . . . . . . .   7
     3.1.2. Interference: Protocol Specification/Dynamic Behavior  .   7
     3.1.3. Application Fit. . . . . . . . . . . . . . . . . . . . .   7
   4. Definitions. . . . . . . . . . . . . . . . . . . . . . . . . .   8
    4.1. Layer 3 Routing Information . . . . . . . . . . . . . . . .   8
    4.2. Reachability Information. . . . . . . . . . . . . . . . . .   8
    4.3. Auxiliary (non-routing) Information . . . . . . . . . . . .   8
    4.4. Address Family Identifier (AFI) . . . . . . . . . . . . . .   9
    4.5. Subsequent Address Family Identifier (SAFI) . . . . . . . .   9
    4.6. Network Layer Reachability. . . . . . . . . . . . . . . . .   9
    4.7. Application . . . . . . . . . . . . . . . . . . . . . . . .  10
    4.8. Routing Protocol. . . . . . . . . . . . . . . . . . . . . .  10
    4.9. Fate Sharing. . . . . . . . . . . . . . . . . . . . . . . .  10
   5. Architectural Models . . . . . . . . . . . . . . . . . . . . .  10
    5.1. General Purpose Transport Infrastructure (GPT) Model. . . .  11
    5.2. Special Purpose Transport Infrastructure (SPT) Model. . . .  11
   6. Analyzing Risk and Interference. . . . . . . . . . . . . . . .  12
    6.1. Risk: Code Impact, and Resource Sharing . . . . . . . . . .  12
     6.1.1. Code Impact. . . . . . . . . . . . . . . . . . . . . . .  13
     6.1.2. Resource Sharing . . . . . . . . . . . . . . . . . . . .  13
      6.1.2.1. Resource Sharing and Operating System Level Issues  .  14
    6.2. Interference. . . . . . . . . . . . . . . . . . . . . . . .  14
   7. BGP and TCP Models: Risk and Interference. . . . . . . . . . .  15
    7.1. Risk. . . . . . . . . . . . . . . . . . . . . . . . . . . .  15
     7.1.1. Code Impact. . . . . . . . . . . . . . . . . . . . . . .  15
     7.1.2. Resource Sharing . . . . . . . . . . . . . . . . . . . .  16
    7.2. Interference. . . . . . . . . . . . . . . . . . . . . . . .  17
    7.3. The TCP Model and Interference. . . . . . . . . . . . . . .  17
    7.4. The BGP Model and Interference. . . . . . . . . . . . . . .  18
   8. Operational Implications . . . . . . . . . . . . . . . . . . .  18
   9. Conclusions and Recommendations. . . . . . . . . . . . . . . .  18
   10. Intellectual Property . . . . . . . . . . . . . . . . . . . .  18
   11. Design Team . . . . . . . . . . . . . . . . . . . . . . . . .  18
   12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  19
   13. Security Considerations . . . . . . . . . . . . . . . . . . .  20
   14. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  20
   15. References. . . . . . . . . . . . . . . . . . . . . . . . . .  21



Meyer, et. al.                                                  [Page 3]


INTERNET-DRAFT             Expires: April 2004              October 2003


    15.1. Normative References . . . . . . . . . . . . . . . . . . .  21
    15.2. Informative References . . . . . . . . . . . . . . . . . .  23
   16. Editor's Address. . . . . . . . . . . . . . . . . . . . . . .  24
   17. Full Copyright Statement. . . . . . . . . . . . . . . . . . .  24















































Meyer, et. al.                                                  [Page 4]


INTERNET-DRAFT             Expires: April 2004              October 2003


1.  Introduction


   The stability of the global Internet routing system has been the
   subject of much research (see e.g., [RVBIB]) and discussion on
   various IETF mailing lists [IETFOL]. Much of the research into the
   routing system has centered around the analysis of the dynamics and
   stability of the Border Gateway Protocol Version 4 [BGP] (hereafter
   referred to as BGP).

   However, while the theoretical properties of BGP remains a topic of
   great interest, a more recent discussion has focused on effects of
   the addition of new types of Network Layer Reachability Information,
   or NLRI to BGP. In particular, the advent of two BGP attributes,
   Multiprotocol Reachable NLRI (MP_REACH_NLRI), and Multiprotocol
   Unreachable NLRI (MP_UNREACH_NLRI) [RFC2858], have made it possible
   to encode and transport a wide variety of features and their
   associated signaling using the BGP transport infrastructure. Examples
   include IPv6 [RFC2460], flow specification rules [FLOW], virtual
   private LAN services [VPLS], and virtual private Wire Service [VPWS].

   Finally, while this document outlines the concerns and issues
   surrounding using the BGP infrastructure as a generic feature and
   signaling transport, note that the similar concerns apply to the
   Interior Gateway Protocols (IGPs) in common use (e.g., ISIS [RFC1142]
   or OSPF [RFC2328]), although at this time there is no specific
   material on IGPs.


   The rest of this document is organized as follows: Section 2 outlines
   the scope of this work. Section 3 introduces the problem statement
   which is the focus of this document, section 4 provides definitions,
   and section 5 outlines the main architectural models that are
   discussed. The remaining sections discuss the the implications of
   those models.



2.  Scope of this Work


   It is the intention of the RPO design team that this document serve
   as a guide for both protocol designers and network operators, and
   that an attempt is being made to shine a neutral light on the
   implications (in the form of both benefits and offshoots) associated
   with proceeding to employ routing protocols to enable additional
   feature sets and functionality, or to design new mechanisms for
   carriage of that information.



Meyer, et. al.                                      Section 2.  [Page 5]


INTERNET-DRAFT             Expires: April 2004              October 2003


   The issues, concerns and considerations discussed in this document
   focus on the implications for BGP [BGP,RFC1771]. It is important to
   note that similar issues will arise when considering generalizations
   to the information that the IGPs carry.




3.  Problem Statement


   The advent of the MP_REACH_NLRI and MP_UNREACH_NLRI attributes,
   combined with the resulting generalization to the BGP infrastructure,
   have created the opportunity to use BGP to transport a wide variety
   of data types and their associated signaling. The combination of a
   BGP data type and its associated signaling is frequently called an
   "application"; example applications include the IPv4 routing system,
   flow specification rules [FLOW], auto-discovery mechanisms for Layer
   3 VPNs [BGPVPN], and virtual private LAN services [VPLS].

   More recently, the discussion in the IETF community has focused on
   the use of the BGP as a generalized feature transport infrastructure
   [IETFOL]. The debate has recently intensified due to the emergence of
   a new class of application that use the BGP infrastructure to
   distribute information that is not directly related to inter-domain
   routing. Examples of such applications include the use of the BGP
   transport infrastructure to provide auto-discovery for Layer 3 VPNs
   [BGPVPN] and the virtual private LAN services mentioned above.



3.1.  Risk, Interference, and Application Fit


   As mentioned above, much of the debate surrounding these new uses of
   BGP transport infrastructure has focused on the potential tradeoffs
   between the stability of the Internet routing system as effected by
   the deployment of new applications, and the desire on the part of
   service providers to rapidly deploy these new applications. These
   tradeoffs have at times been described in terms of risk,
   interference, and application fit. Risk models the software
   engineering impact of new applications on a generic implementation,
   while interference models the impact of new applications on protocol
   definition and behavior. Finally, application fit models the
   similarity between application's data and signaling requirements and
   a specific distribution algorithm. Each is described below.





Meyer, et. al.                                    Section 3.1.  [Page 6]


INTERNET-DRAFT             Expires: April 2004              October 2003


3.1.1.  Risk: Software Engineering


   Risk attempts to assess the robustness tradeoffs inherent in the
   addition of new applications to a given implementation. In this case,
   risk models the impact of generic software engineering issues on a
   given implementation. These issues including the impact of new
   applications on existing implementations and on the fate sharing
   properties of those implementations.

   A second aspect of risk lies in  the trade-off of extending an
   existing protocol (with the risks in 3.1.1), versus designing,
   implementing, and deploying a new protocol. (more from Kireeti here).



3.1.2.  Interference: Protocol Specification/Dynamic Behavior


   Interference, on the other hand, models the potential for a new
   application to adversely effect the operation of an existing
   implementation, at the protocol level, by inadvertently introducing a
   detrimental dependency of some kind. That is, is it possible that we
   might, by some extension, break something fundamental to a protocol's
   specification? For example, could we create a new state which
   introduces an unanticipated deadlock situation to occur? Or could we
   destabilize the distributed behavior of the protocol? Or might we
   simply run out of the attributes or bits available (as happened, for
   example, with RADIUS [RFC2138])?



3.1.3.  Application Fit


   Application fit refers to the matching of the requirements of the
   data to be distributed with the underlying capabilities of a
   distribution mechanism.  Broadcast, multicast and unicast
   distribution mechanisms in use today.  When considering a
   distribution mechanism (such as BGP), an important issue to address
   is whether the behavior of the distribution mechanism matches the
   distribution needs.  For example, it is clearly inefficient to
   broadcast data to all peers that is only required between two peers,
   just as it is inefficient to create many unicasts of data that is
   required by all peers when a single broadcast would do.






Meyer, et. al.                                  Section 3.1.3.  [Page 7]


INTERNET-DRAFT             Expires: April 2004              October 2003


4.  Definitions




4.1.  Layer 3 Routing Information


   Layer 3 routing information represents either link state information
   or network reachability information. Link state information
   represents Layer 3 adjacencies and topology. Link state routing
   protocols, such as OSPF [RFC2328] and ISIS [RFC1142], flood link
   state information throughout an IGP domain, so that each
   participating router maintains an identical copy of a database that
   is computed to reflect the complete Layer 3 topology.

   Layer 3 reachability information represents Layer 3 networks that are
   reachable through gateway routers. Distance/path vector routing
   protocols, such as BGP, distribute Layer 3 reachability information
   among routing domains.

   Routers use both types of Layer 3 routing information (link state and
   reachability) to produce IP forwarding tables.

   For purposes of this discussion, "routing information" relates to the
   Layer 3 inter-domain routing data traditionally carried by BGP.



4.2.  Reachability Information


   Reachability information refers to information describing some locale
   of a network, along with how one can reach it, and perhaps also
   containing attributes that indicate the suitability of the implied |
   path to the network locale.  An example is VPLS information [VPLS].




4.3.  Auxiliary (non-routing) Information


   Auxiliary Information is any information that is exchanged by routers
   which is neither Layer 3 routing information, nor reachability
   information. For example, flow specification [FLOW] is auxiliary
   information.




Meyer, et. al.                                    Section 4.3.  [Page 8]


INTERNET-DRAFT             Expires: April 2004              October 2003


4.4.  Address Family Identifier (AFI)


   An Address Family contains addresses that share common structure and
   semantics. An Address Family Identifier (AFI) uniquely identifies
   each address family. Several routing protocol messages contain a
   field that represents the AFI. The AFI identifies the address type
   used by another data item contained in that message. The Routing
   Information Protocol (RIP) [RFC2453], Distance Vector Multicast
   Routing Protocol (DVMRP) [RFC1075], and BGP all employ the AFI field.

   For example, the BGP MP_REACH_NLRI and MP_UNREACH_NLRI attributes
   contain an AFI field. These BGP attributes also contain a NLRI field
   that enumerates reachable or unreachable subnetworks corresponding to
   the associated address family. The AFI field indicates the address
   type by which reachable subnetworks are identified. When BGP is used
   to distribute Layer 3 routing information, AFIs can indicate the
   following address types: IPv4, IPv6, VPNv4 [RFC2547BIS]. When BGP is
   used to distribute auxiliary information, AFIs can indicate other
   address families.



4.5.  Subsequent Address Family Identifier (SAFI)


   A Subsequent Address Family Identifier (SAFI) is part of the BGP
   MP_REACH_NLRI and MP_UNREACH_NLRI attributes. These BGP attributes
   also contain a NLRI field that enumerates reachable or unreachable
   subnetworks. The SAFI augments the AFI, carrying additional
   information regarding networks enumerated in the NLRI field.



4.6.  Network Layer Reachability


   Network Layer Reachability Information, or NLRI is the data described
   by the AFI/SAFI fields [AFI,SAFI]. While these concepts were
   originally described for protocols such as DVMRP [RFC1075], the bulk
   of the generalization of the NLRI described in this document derive
   from the introduction to BGP of the MP_REACH_NLRI and MP_UNREACH_NLRI
   attributes [RFC2858].








Meyer, et. al.                                    Section 4.6.  [Page 9]


INTERNET-DRAFT             Expires: April 2004              October 2003


4.7.  Application

   The term application is used in this document to refer to the
   combination of a BGP data type and any signaling data that is carried
   by BGP in support of the service the data type carries. The data type
   is typically described an AFI/SAFI, while the actual data is
   frequently contained in both NLRI and BGP community attributes
   [RFC1997].



4.8.  Routing Protocol


   A routing protocol is composed of two basic components: a data
   distribution algorithm and a decision algorithm. A router typically
   obtains Layer 3 routing information via its data distribution
   algorithm, and it uses this information to produce an IP forwarding
   table (by applying the protocol's decision algorithm to the received
   routing data). Note that it is the use of BGP's data distribution
   algorithm that is the focus of this document.  However, when judging
   application fit, one may also consider whether the decision
   algorithms suit the application.



4.9.  Fate Sharing


   The fate sharing principle for end to end network protocols was first
   enunciated by Dave Clark [CLARK]. As applied to software systems,
   fate sharing refers to the sharing of common resources among a group
   of applications. In our case, the particular "fate" of most interest
   is the ability of one application, call it application A, to cause an
   application with which it is fate sharing, call it application B, to
   experience one or more faults due to faults in application A. In the
   case of BGP, one way to reduce fate sharing is to run applications A
   and B in seprate BGP sessions.



5.  Architectural Models


   In this section, we consider the two architectural models which are
   motivated by salient questions considered in this document, namely:

     Does the BGP distribution protocol suit a particular



Meyer, et. al.                                     Section 5.  [Page 10]


INTERNET-DRAFT             Expires: April 2004              October 2003


     application, and if it does, what are the effects on the global
     routing system (if any) of carrying that application using the
     BGP distribution protocol?

   That is:
     (i).  Does the BGP distribution protocol suit a particular application?

     (ii). What are the effects on the global routing system (if
           any) of carrying that application using the BGP
           distribution protocol?

   These questions must be analyzed in terms of the the cost of protocol
   and code development, as well as operational expense that may be
   incurred by utilizing (or not utilizing) the mechanisms already
   present in BGP.

   Two models, describing alternate viewpoints, are examined in the
   following sections.



5.1.  General Purpose Transport Infrastructure (GPT) Model


   The GPT model models BGP data distribution infrastructure as a
   generic application transport mechanism. As such, it focuses on
   "application fit", and assumes that the tradeoffs, both in terms of
   risk and interference can be managed in an efficient manner.  As a
   result, the GTP models these issues not in terms of whether the
   application and signaling data that need to be distributed are part
   of some particular class (routing, in this case), but rather whether
   the requirements for the distribution these attributes are similar
   enough to the distribution mechanisms of BGP.  In those cases when
   they are sufficiently similar, BGP becomes a logical candidate for
   such a transport infrastructure. Note that this is not because of the
   nature of information distributed, but rather due to the similarity
   in the transport requirements. There are other operational
   considerations that make BGP a logical candidate, including its close
   to ubiquitous deployment in the Internet (as well as in intra-nets),
   its policy capabilities, and operator comfort levels with the
   technology.



5.2.  Special Purpose Transport Infrastructure (SPT) Model


   The SPT model, on the other hand, models the BGP infrastructure as a



Meyer, et. al.                                   Section 5.2.  [Page 11]


INTERNET-DRAFT             Expires: April 2004              October 2003


   special purpose transport designed specifically to transport inter-
   domain routing information. As such, it is more sensitive to risk and
   interference than to application fit.

   There are two basic arguments supporting the SPT model: The first is
   based on the perceived risk profile of the fate sharing involved in
   adding new applications to the BGP transport infrastructure. The
   concern here is that the new applications being added to BGP will
   cause software quality degrade, and hence destabilize the global
   routing system. This position is based upon well understood software
   engineering principles, and is strengthened long-standing experience
   that there is a direct correlation between software features and bugs
   [MULLER1999]. This concern is augmented by the fact that in many
   cases, the existence of the code for these features, even if unused,
   can also cause destabilization in the routing system, since in many
   cases software faults cannot be isolated.

   A second concern is based on interference arguments, notably that the
   increase in complexity of BGP due to the number of data types that it
   carries can also potentially destabilize the global routing system.
   This concern is based on a wide range of concerns, including that the
   interaction of BGP dynamics and current deployment practices are
   poorly understood, and that the addition of non-routing data types
   may adversely effect convergence and other scaling properties of the
   global routing system.



6.  Analyzing Risk and Interference


   One way to frame the tradeoffs involved in analyzing risk is in terms
   of the software engineering issues surrounding where an
   implementation might demultiplex among applications. An
   implementation's application demultiplexing point directly effects a
   given implementation's risk profile due to its effects on existing
   code, and on the system resources it requires to be shared among
   those applications.



6.1.  Risk: Code Impact, and Resource Sharing


   For purposes of this discussion, we consider two models of
   application demultiplexing: The first model, which we will call the
   "BGP model", based on the current BGP model, provides a single point
   for demultiplexing all applications (i.e., the AFI/SAFI). The BGP



Meyer, et. al.                                   Section 6.1.  [Page 12]


INTERNET-DRAFT             Expires: April 2004              October 2003


   model is and instantiation of the GPT model.

   The second model, which we will call the "TCP model", provides an
   application demultiplexing point above BGP (typically at the TCP port
   level). In particular, in the BGP model, applications currently share
   a common transport session, while the TCP model envisions one or more
   applications per transport session. The TCP model an instantiation of
   the SPT model.

   Finally, note that these models can have very risk profiles with
   respect to code impact and resource sharing. Some of the questions
   relating to risk assessment are considered below.



6.1.1.  Code Impact


   In this section, we outline the high-level questions one might ask in
   assessing the difference in risk between TCP model and the BGP model
   based on their effect on an existing code base.

   o Does the code below the demultiplexing point need to be
     changed when a new application is added?

   o Does the code in existing applications have to be changed when
     a new application is added (that is, to what extent are the
     applications decoupled)?

   o Can the code in separate applications be developed, tested,
     released, debugged and packaged independently from other
     applications?

   o Is there significant code below the demultiplexing point that
     can be shared among all applications?





6.1.2.  Resource Sharing


   In this section, we outline the high-level questions one might ask in
   assessing the difference in risk between TCP model and the BGP model
   with respect to the requirements and properties of the system
   resource sharing it they require.




Meyer, et. al.                                 Section 6.1.2.  [Page 13]


INTERNET-DRAFT             Expires: April 2004              October 2003


    o Do applications have to compete for socket buffers, and hence
      have to potential to block or starve each other (at the TCP
      port level)?

    o Do applications have to compete for possible protocol-level
      transport-related buffers and queues, and hence have the
      potential to starve or block each other at the protocol
      send/receive level?

    o Do applications have to compete for a possible per-connection
      processing time budget, hence have the potential to starve
      each other at the intra-process scheduling level?

    o Do applications have to compete for resources within the
      network (e.g., bandwidth), when the protocol session spans
      multiple hops ?




6.1.2.1.  Resource Sharing and Operating System Level Issues


   In this section, we outline the high-level questions one might ask in
   assessing the difference in risk between TCP model and the BGP model
   based on the effect on resource sharing at the operating system
   level.

    o Do applications share a common scheduling context? That is,
      do applications have to compete for per-process scheduling
      budgets?

    o What is the degree of fate sharing between applications?




6.2.  Interference


   Interference models the potential for a new application to effect the
   behavior of an existing application or applications. For example, in
   the case of the Internet routing system, one might ask if a certain
   application "interferes" with IPv4 Unicast routing by effecting some
   aspect of its protocol operation (e.g., convergence time).

   Interference in the Internet routing system has it is roots in the
   observation that the routing system itself can be described as highly



Meyer, et. al.                                   Section 6.2.  [Page 14]


INTERNET-DRAFT             Expires: April 2004              October 2003


   self-dissimilar, with extremely different scales and levels of
   abstraction. Complex systems with this property are susceptible
   "coupling", which RFC 3439 [RFC3439] defines as follows:

      The Coupling Principle states that as things get larger, they
      often exhibit increased interdependence between components.

      COROLLARY: The more events that simultaneously occur, the
      larger the likelihood that two or more will interact. This
      phenomenon has also been termed "unforeseen feature
      interaction" [WILLINGER2002].

   That is, interference, if and where it occurs, has its roots protocol
   complexity and is frequently the result of application coupling.



7.  BGP and TCP Models: Risk and Interference


   In this section, we analyze the BGP and TCP models risk and
   interference.



7.1.  Risk


   As mentioned above, risk models the robustness tradeoffs around
   generic software architecture and engineering associated with
   protocol implementations, including the impact on impact on existing
   protocol implementations, and on the fate sharing properties of those
   implementations. In the following sections we consider these
   components of risk for both the TCP and BGP models.



7.1.1.  Code Impact


   In this section, we outline the answers to the questions posed above.

   o Does the code below the demultiplexing point need to be
     changed when a new application is added?

     Such code changes are unlikely to be required in the TCP model,
     as the TCP model envisions that a new application will have a
     new demultiplexing point (port).



Meyer, et. al.                                 Section 7.1.1.  [Page 15]


INTERNET-DRAFT             Expires: April 2004              October 2003


     In theory, the BGP model does not require new code below the
     demultiplexing point either. Specifically, it is possible
     to isolate code below the demultiplexing point with suitable
     abstraction and constructs such as AFI/SAFI API registries.

   o Does the code in existing applications have to be changed when
     a new application is added (that is, to what extent are the
     applications decoupled)?

     The TCP model envisions application independence with respect
     to demultiplexing point. As such, it is unlikely to require
     such changes. However, it is important to note that good
     software engineering practices encourage code reuse and
     construction of general purpose libraries. As a result, if
     applications share libraries and/or other code, the practical
     independence decreases, and consequently risk increases. The
     same analysis can be made for the BGP model, since in this case
     we are already demultiplexing on the AFI/SAFI fields.


   o Can the code in separate applications be developed, tested,
     released, debugged and packaged independently from other
     applications?

     While this is theoretically possible in the TCP model (and
     possibly harder in the BGP model) practice and experience has
     shown that achieving this type of independence is difficult in
     either model.



7.1.2.  Resource Sharing


   In this section, we address the questions raised above to assess the
   difference in risk between TCP model and the BGP model based on the
   effect on resource sharing considerations.

    o Do applications have to compete for socket buffers, and hence
      have to potential to block or starve each other (at the TCP
      level)?

      The TCP model does not require applications to compete for
      socket level resources. It should also be possible to achieve
      this type of application independence in the BGP model with
      multi-session extensions to BGP (i.e., grouping of one or more
      AFI/SAFI per TCP session).




Meyer, et. al.                                 Section 7.1.2.  [Page 16]


INTERNET-DRAFT             Expires: April 2004              October 2003


    o Do applications have to compete for possible protocol-level
      transport-related buffers and queues, and hence have the
      potential to starve or block each other at the protocol
      send/receive level?

      Again, while the TCP model does not require competition for
      transport-level resources, it should be possible to achieve
      similar behavior with the BGP model and multi-session
      extensions.

    o Do applications have to compete for a possible per-connection
      processing time budget, hence have the potential to starve
      each other at the intra-process scheduling level?

      Applications written to the the TCP model should require this
      type of resource competition. Note, however, that it should be
      possible in the BGP model with multi-session extensions to
      BGP.


    o Do applications have to compete for resources within the
      network (e.g., bandwidth), when the protocol session spans
      multiple hops ?

      Neither the TCP model nor the BGP model (again, with
      multi-session extensions) should be require competition for
      network resources in this case.



7.2.  Interference


   Interference concerns stem from the possibility that application
   coupling can lead to the destabilization of the Internet routing
   system in unanticipated and unexpected ways. In this section we
   consider interference properties of the TCP and BGP models.



7.3.  The TCP Model and Interference










Meyer, et. al.                                   Section 7.3.  [Page 17]


INTERNET-DRAFT             Expires: April 2004              October 2003


7.4.  The BGP Model and Interference




8.  Operational Implications





9.  Conclusions and Recommendations



10.  Intellectual Property


   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11 [RFC2028].
   Copies of claims of rights made available for publication and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementors or users of this
   specification can be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.



11.  Design Team

   The design team that produced this document consisted of Daniel
   Awduche (awduche@awduche.com), Ron Bonica (Ronald.P.Bonica@mci.com),
   Hank Kilmer (hank@rem.com), Kireeti Kompella (kireeti@juniper.net),
   Chris Lewis (chrlewis@cisco.com), Danny McPherson (danny@tcb.net),
   David Meyer (dmm@1-4-5.net) and Pete Whiting (pete@sprint.net).




Meyer, et. al.                                    Section 11.  [Page 18]


INTERNET-DRAFT             Expires: April 2004              October 2003


12.  Acknowledgments


   David Ball, Eric Rosen, and Mark Townsley made many insightful
   comments on earlier versions of this draft.














































Meyer, et. al.                                    Section 12.  [Page 19]


INTERNET-DRAFT             Expires: April 2004              October 2003


13.  Security Considerations


   This document specifies neither a protocol nor an operational
   practice, and as such, it creates no new security considerations.



14.  IANA Considerations


   This document creates a no new requirements on IANA namespaces
   [RFC2434].






































Meyer, et. al.                                    Section 14.  [Page 20]


INTERNET-DRAFT             Expires: April 2004              October 2003


15.  References

15.1.  Normative References


   [AFI]           http://www.iana.org/assignments/address-family-
   numbers

   [BGP]           Rekhter, Y, T.Li, and S. Hares, "A Border Gateway
                   Protocol 4 (BGP-4)", draft-ietf-idr-bgp4-20.txt,
                   Work in Progress.

   [BGPVPN]        Ould-Brahim, H., E. Rosen, and Y. Rekhter, "Using
                   BGP as an Auto-Discovery Mechanism for
                   Provider-provisioned VPNs",
                   draft-ietf-l3vpn-bgpvpn-auto-00.txt, July,
                   2003. Work in Progress.

   [CLARK]         Clark, D., "Design Philosophy of the DARPA Internet
                   Protocols", Computer Communication Review, volume
                   25, number 1, January 1995. ISSN # 0146-4833.

   [EXTCOMM]       Sangali, S., D. Tappan, and Y. Rekhter, "BGP
                   Extended Communities Attribute",
                   draft-ietf-idr-bgp-ext-communities-06.txt. Work
                   in Progress.

   [FLOW]          Marques, P, et. al., "Dissemination of flow
                   specification rules",
                   draft-marques-idr-flow-spec-00.txt, June,
                   2003. Work in Progress.

   [MULLER1999]    Muller, R. et. al., "Control System Reliability
                   Requires Careful Software Installation
                   Procedures", International Conference on
                   Accelerator and Largeand Large Experimental
                   Physics Systems, 1999, Trieste, Italy.

   [RFC1075]       Waitzman, D., C. Partridge, and S. Deering,
                   "Distance Vector Multicast Routing Protocol", RFC
                   1075, November, 1988.


   [RFC1142]       Oran, D. Editor, "OSI IS-IS Intra-domain Routing
                   Protocol", RFC 1142, February, 1990.

   [RFC1771]       Rekhter, Y., and T. Li, "A Border Gateway
                   Protocol 4 (BGP-4)", RFC 1771, March 1995.



Meyer, et. al.                                  Section 15.1.  [Page 21]


INTERNET-DRAFT             Expires: April 2004              October 2003


   [RFC1958]       Carpenter, B., "Architectural principles of the
                   Internet", Editor. RFC 1958, June 1996.


   [RFC1997]       Chandra, R., P. Traina, and T. Li,  "BGP
                   Communities Attribute", RFC 1997, August, 1996.

   [RFC2138]       Rigney, C., et. al., "Remote Authentication Dial
                   In User Service (RADIUS)", RFC 2138, April, 1997.

   [RFC2328]       Moy, J., "OSPF Version 2", RFC 2328, April, 1998.

   [RFC2453]       Malkin, G., "RIP Version 2", RFC 2453, November,
                   1998.

   [RFC2460]       Deering, S. and R. Hinden, "Internet Protocol,
                   Version 6 (IPv6) Specification", RFC 2460,
                   December, 1998.

   [RFC2547BIS]    Rosen, E., et. al., "BGP/MPLS IP VPNs",
                   draft-ietf-l3vpn-rfc2547bis-00.txt, May, 2003,
                   Work in Progress.

   [RFC2858]       Bates, T., et. al., "Multiprotocol Extensions
                   for BGP-4", RFC 2858, June 2000.

   [RFC3439]       Bush, R. and D. Meyer, "Some Internet
                   Architectural Guidelines and Philosophy", RFC
                   3439, December, 2002.

   [SAFI]          http://www.iana.org/assignments/safi-namespace


   [VLPS]          Kompella, K., et. al. "Virtual Private LAN
                   Service", draft-ietf-l2vpn-vpls-bgp-00.txt,
                   Work in Progress.

   [VPWS]          Kompella, K. et.al. "Layer 2 VPNs Over Tunnels",
                   draft-kompella-ppvpn-l2vpn-03.txt, April
                   2003. Work in Progress.











Meyer, et. al.                                  Section 15.1.  [Page 22]


INTERNET-DRAFT             Expires: April 2004              October 2003


15.2.  Informative References



   [IETFOL]        https://www1.ietf.org/mailman/listinfo/routing-discussion

   [RFC2119]       Bradner, S., "Key words for use in RFCs to
                   Indicate Requirement Levels", RFC 2119, March,
                   1997.

   [RFC2026]       Bradner, S., "The Internet Standards Process --
                   Revision 3", RFC 2026/BCP 9, October, 1996.

   [RFC2028]       Hovey, R. and S. Bradner, "The Organizations
                   Involved in the IETF Standards Process", RFC
                   2028/BCP 11, October, 1996.

   [RFC2434]       Narten, T., and H. Alvestrand, "Guidelines for
                   Writing an IANA Considerations Section in RFCs",
                   RFC 2434/BCP 26, October 1998.

   [RVBIB]         http://www.routeviews.org/papers

   [WILLINGER2002] Willinger, W., and J. Doyle, "Robustness and the
                   Internet: Design and evolution", 2002.


























Meyer, et. al.                                  Section 15.2.  [Page 23]


INTERNET-DRAFT             Expires: April 2004              October 2003


16.  Editor's Address


   David Meyer
   Email: dmm@1-4-5.net


17.  Full Copyright Statement

   Copyright (C) The Internet Society (2003). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

















Meyer, et. al.                                    Section 17.  [Page 24]