Subject: BGP TE Draft
From: Ben Abarbanel <[email-masked]>
To: [email-masked]
Date: Fri, 28 Apr 2000 14:53:17 -0400

Attached is my BGP TE Draft.

After today I am relocating to a new company, so please if you want to
correspond send comments to
[email-masked].

Thank You,
Ben Abarbanel

--
Remember
========
"Don't be afraid to try something new. Amateurs built the Arc,
professionals built Titanic"

 Network Working Group                                  Ben Abarbanel,
 Internet Draft 				            Senthil Venkatachalam
 Document: draft-ietf-abarbanel-bgp4-te.txt             Alcatel U.S.A
 Expiration Date:                                     September, 2000

 Category: Informational

                   BGP-4 support for Traffic Engineering

Status of this Memo

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

     This document is an Internet-Draft and is in full conformance with all
     provisions of Section 10 of RFC2026 except that the right to produce
     derivative works is not granted.

     This document is an Internet-Draft and is NOT offered in accordance
     with Section 10 of RFC2026, and the author does not provide the IETF
     with any rights other than to publish as an Internet-Draft

     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.

Abstract

     Currently, constraint based (CR) routing and traffic engineering 
     (TE) models do not take into consideration the big picture view of IP
     traffic traversing multiple autonomous systems (AS). Most of the
     traffic and constraint routing is based on IGP protocols such as
     OSPF/ISIS, etc. The resulting view of the Internet is limited to 
     one autonomous system and areas or systems within it. Hence, the 
     routing/forwarding functions do not select the optimum path for 
     packets that need to traverse several autonomous systems. 
     
     The proposal in this draft is that the BGP protocol can be utilized 
     to choose the best BGP routes based on traffic engineered (TE) 
     constraint weights. This information can be propagated between all 
     BGP peers and calculated by the BGP AS border routers before it is 
     deployed to their forwarding tables.

draft-ietf-abarbanel-bgp4-te.txt                                   [page 2]

1. Conventions used in this document

     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 [].

2. Overview

     The Internet is composed of many autonomous systems(AS). BGP acts as
     the road map for selecting the best paths across these systems. Today's
     Internet infrastructure does not consider the Internet as one
     homogenous system but a collection of systems. Where each system is
     managed autonomously by an (ISP) provider. These providers tend to
     filter or block routes from each other. This in itself creates a
     non-optimum routing. Constraint based routing adds a level of traffic
     influence by defining the path (all the hops along the way) that a
     packet should take. It does this very well within an autonomous system
     and within the limitation of an OSPF/ISIS areas/levels. The area
     border routers inside the AS will need to compute the best path to
     other areas until the packet arrives at its destination within the
     autonomous system or leaves the AS to the next Autonomous System. The
     choice of which AS to select is based purely on a one dimensional
     level, by looking at the minimum number of AS hops to a given
     destination or providing various weights and preferences, that are
     local to the AS. The BGP Multi Exit Discriminator (MED)
     provides some level of inter-AS metric but is still limited to the
     adjacent AS.

     The approach discussed here is to view the Internet as one homogenous
     entity with many AS's. Each of the AS's can have a summary weight
     assigned to it based on a given traffic engineering criteria. This
     weight can be a type of quality of service, such as maximum IGP
     bandwidth available, maximum number of IGP hops, maximum IGP delay
     across the AS from one IBGP router to the other IBGP router, maximum
     bandwidth for a service class A, B, C, etc. These criteria levels are
     summarized by the IGP for a given network destination in a given AS
     and exported to BGP. The summarization within an AS can be achieved
     using IGP constraint based routing algorithms used within link state
     protocols such as OSPF and ISIS. In the case of OSPF, a new opaque LSA
     is defined to propagate the summarized weights between OSPF areas.

     This draft is organized as follows. Section 3 details the approach at the
     BGP level between ASs and Section 4 discusses the approach at the
     IGP level within an AS. The various traffic engineering weights are
     discussed in Section 5. The following sections deal with the redistribution 
     of the traffic engineering weight information from IGP to BGP,     
     configuration issues, route flapping, and ISP issues.  The BGP and IGP   
     approaches together will provide a comprehensive traffic engineering    
     routing system across the internet.

 

draft-ietf-abarbanel-bgp4-te.txt                                   [page 3]

3. BGP Level

The method used to propagate constraint summarization weights for each AS is to define a new attribute which contains QOS like sub fields that can include such          parameters as bandwidth, number of hops, delay, various QOS service classes, and so on. In addition, historical NLRI information is contained. These sub fields will be termed TE weights and each BGP router would propagate this information to its peers. Making it possible for any router that handles the data to have a traffic engineering view of all the paths and their associated TE Weights for a given route to a given router.
 
When the BGP RIB database is loaded with TE Weight information, a TE capable BGP router would compute based on TE manual configurations criteria the best BGP route for a given destination. The BGP Route Selection process is extended to support a TE way of prioritizing the best routes for any configured destination. In which the order and preference of the routes can be changed to give the TE weight attribute a higher priority than other attributes. Different TE Weight types could be manually assigned a different level of priority in order to strategize a system where the BGP route selection criteria could be further optimized.

3.1 BGP Routes Originating in Local AS
    Routes that originated within the same AS will not be calculated for
    TE weights since there is no BGP optimization that can be achieved.
    In this case, all TE Weight calculations are strictly done at the IGP
    level. As a rule, IBGP routers will not propagate to other IBGP routers   
    the new TE Weight attribute for routes that originated in the same AS. 
    Routes that came from other EBGP peers could contain the new TE Weight 
    attribute which will be propagated to IBGP peers.

3.2 Route Reflector Functionality 
    When a Route Reflector receives an update messages with the Aggregated TE 
    Weight attribute it will simply add it to the BGP RIB for local use and 
    propagate it to other IBGP peers without modifying any of the fields.   

3.3 When to Add TE Weight to BGP Update messages
    When an IBGP router receives an update message from another IBGP router for 
    a (route) destination outside its own AS, it will consult the local FIB
    database for its reachability via the corresponding update message BGP Next 
    Hop.  Using this BGP Next Hop it will check the associated TE summary weight 
    provided in the FIB by the extended IGP constraint routing calculations. It      
    will add or compare the IGP TE summary weight with the Aggregated TE Weight 
    that was propagated in the update message and create the next level   
    Aggregated TE weight. Next, it will add the Aggregated TE weight to the 
    local BGP RIB and use it for the BGP route selection process. 
    In addition, the current router will propagate the new Aggregated TE weight 
    value to all of its EBGP peers except the one that introduced the route.    
 draft-ietf-abarbanel-bgp4-te.txt                                   [page 4]

    Propagation, aggregating BGP TE Weights, and deploying into the BGP RIB  
    and FIB tables is performed from one router to the next such that the only  
    TE weight that is detected by any router along an AS path is accurate enough
    to cover the TE measurements from a given router to the route's point of 
    origin.

3.4 Route Aggregation Impacts
    As routes are propagated from one AS to the next, it is possible that
    providers have configured their routers to aggregate more specific routes 
    into general ones. This condition will cause the specific routes and their  
    TE Weight attributes to get lost or reduced in accuracy.  In order to keep 
    track of this information, it is proposed that the specific routes and their
    TE Weights be contained in the new TE Weight attribute fields. It would be 
    possible at any router along the route propagation paths to determine the   
    detail accuracy of the TE weights that made up the super aggregate TE    
    Weight. 

    Example 1: A single AS-Path with no route aggregation, and TE weights 
               are aggregated.

      In AS1            In AS2               Arriving in Dest AS3
    N1N2,AS1,TE1 ----> N1N2,AS2,(TE1+TE2) ----> N1N2,TE12  

    In AS3 all we need is the routes(N1N2) and the TE weight TE12, which is the 
    aggregate of TE1 and TE2.

    Example 2: Aggregating routes from multiple AS-Paths, and TE weights
               are super aggregated too.

      In AS1            In AS2             In Dest AS3
    N1N2,AS1,TE1 ----> N1N2,AS2,(TE1+TE2) --> N1N2,TE12 --> see below 

      In AS4            In AS5             In Dest AS3
    N3N4,AS5,TE5 ----> N3N4,AS5,(TE5+TE6) --> N3N4,TE56 --> see below

    At this point in AS3, routes N1N2 and N3N4 are aggregated together
    to form super aggregate route N13N24, 
    with the aggregated TE weight of (TE12+TE56) = Super aggregated TE WEIGHT 
    TE1256.

    In order to keep track of which routes made up TE12 and TE56 we keep 
    two TE Weight paths in the super aggregated route N13N24 as follows:

    N13N24/TE1256 = (N1N2/TE12, N3N4/TE56) in the TE Weight Attribute field.
 
    This list of historical routes can be as large as the number of route 
    aggregation points that are performed along the AS-Paths.

    *Note: For each list of historical routes and TE weights, there will be 
           one or several TE Weight types. See section 3.5 for details.

draft-ietf-abarbanel-bgp4-te.txt                                   [page 5]

3.5 TE Weight Calculation Impacts
    As was seen in section 3.4, routes and TE Weights are aggregated together 
    into less specific information and as a result the TE weights become more 
    and more global. This affect creates sub optimal data for choosing the best   
    path across a series of ASs. If there is an historical trace of route and TE 
    weights that created the global aggregated route, than its possible to make 
    more accurate decision in choosing the best BGP route. This is done during 
    the route selection process which is run for the same route from multiple 
    BGP peers. With the information in the TE Weight Attribute its possible to 
    look inside an aggregated route and more precisely see its composition 
    (sub-aggregation of routes and more specific TE weights) and determine the 
    best TE route and related BGP Next Hop.  

3.6 TE Weight Attribute Format 
    The BGP update message will contain a new Optional Transitive attribute 
    called TE Weight (type code ?). This contains one or several aggregated 
    TE Weight types and their historical sub aggregated routes and TE weights. 
    The amount of aggregation would depend on the number of AS's the route
    had traversed from the point of origin to the current router.
   
    A TE Weight type must have the same consistency/granularity throughout all
    the routers that have the software to aggregate, compute, and propagate it 
    further.  

        |-- Optional(1) or well known(0) 
        | |-- transitive(1) or non-transitive(0)
        | | |-Attr Flags 
        | | |              1                   2                   3   
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
       +-|-|-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-++    
       |1|1|   FLAGS  | Attr Type (?) | Number TE Weight Lists        |
       +-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-++
       +==============|===============|===============|===============+
       +    1st Super Aggregated TE Weight list entry                 |
       +==============|===============|===============|===============+
       | Number of TE | TE Weight     | 1st Super Aggregated TE Weight|
       | Weight types |  Type 1       |  Value                        |
       +-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-++
       | 2nd TE Weight | 2nd Super Aggregated TE Weight |nth TE Weight|
       |  Type        |     Value                     |type           |
       +-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-++
       |nth Super Aggregated TE Weight| Number of Aggregated Route    |
       |    Value                     |    Prefixes                   |
       +-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-++
       |route prefix 1| 1st Aggregated IP Route prefix                |
       |length        |             1st, 2nd, 3rd   byte              |
       +-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-++ 
       |1st route pref| route prefix n| nth Aggregated IP route prefix|
       | 4th byte     | length        |   1st, and 2nd byte           |
       +-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-++
       |nth Aggregated IP route prefix|                               |
       | 3rd and 4th byte             |          ...                  |
       +-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-++

       draft-ietf-abarbanel-bgp4-te.txt                            [page 6]

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
       +-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-++    
       +==============|===============|===============|===============+
       +    nth Super Aggregated TE Weight list entry                 |
       +==============|===============|===============|===============+
       | Number of TE | TE Weight     | 1st Super Aggregated TE Weight|
       | Weight types |  Type 1       |  Value                        |
       +-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-++
       | 2nd TE Weight| 2nd Super Aggregated TE Weight |nth TE Weight |
       |  Type        |     Value                     |type           |
       +-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-++
       |nth Super Aggregated TE Weight| Number of Aggregated Route    |
       |    Value                     |    Prefixes                   |
       +-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-++
       |route prefix 1| 1st Aggregated IP Route prefix                |
       |length        |             1st, 2nd, 3rd   byte              |
       +-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-++ 
       |1st route pref| route prefix n| nth Aggregated IP route prefix|
       | 4th byte     | length        |   1st, and 2nd byte           |
       +-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-++
       |nth Aggregated IP route prefix|                               |
       | 3rd and 4th byte             |          ...                  |
       +-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-++

       - Each TE Weight type could be:

         o Maximum Bandwidth Available
         o Maximum Number of IGP Hops
         o Maximum Transit Delay
         o Color
         o Etc.

       - Each TE Weight value can be in units relevant to its use:
         o For maximum bandwidth could be Megabits/second.
         o For Maximum transit delay could be in milliseconds.

       - Aggregated IP Route Prefix: Defines the aggregation of several routes 
          into a single route for a given AS.
   
       - Route Prefix Length: The number of significant bits from the   
          left side or high order byte of the IP address. As defined in CIDR.

           Example:  IP address 10.20.30.40, High order Byte is the 10.
                       
       - Super Aggregated TE Weight: Each TE weight will have a different 
          algorithm for aggregation and meaning. See section 5.0 for details.
    
 3.7 Phasing TE Weights 
     The use of TE weights can be manually configured on a destination (route)                    
     basis, and thus it will be possible to enable/disable TE Weights on any BGP   
     route. The functionality can be easily phased into an AS where some
     BGP routers are TE Weight capable and others are not. The new attribute 
     will be Optional and Transitive which implies that older BGP routers will   
     be required to propagate the new attribute in update messages to their 
     peers. 
  draft-ietf-abarbanel-bgp4-te.txt                            [page 7]

    When not all of the BGP routers along a given TE Path support the TE Weight
    attribute, the TE weight calculations is not done there and the best BGP
    route selection computation will be less than optimal.
 
 4. IGP TE Constraints based Calculations and AS Summarization for TE

    The IGP level routing protocol used is generally either OSPF or ISIS.
    The basic OSPF and ISIS protocols allow routing based on a static
    metric. These protocols can be extended to take into consideration
    various traffic engineering criteria such as unreserved bandwidth,
    delay, colors, OSPF metric, etc. The approach detailed below is
    oriented more toward OSPF, but will be readily extended to ISIS.

    If the IGP inside a routing domain is OSPF, the AS is divided into
    areas - each of which is a collection of routers and networks. The
    routers within an area know the complete topology of the area by means
    of LSA database synchronization with their neighbors at all times.
    Through the use of the opaque LSAs [8], it is possible to maintain the
    traffic engineering topology (in addition to the regular network
    topology) and hence perform route calculations based on traffic
    engineering criteria within an area inside an AS that runs OSPF.
    However, this restricts the traffic engineering calculations to within
    an area.

    To determine the traffic engineering weight to any network or router
    in the AS, the approach proposed for OSPF is to define a new opaque
    LSA for traffic engineering that summarizes the traffic engineering
    weights of every network from the perspective of an area border router
    (ABR), for each area in the AS. This traffic engineering summary LSA
    is analogous to the summary LSA in OSPF. More details on this work can
    be found in [9].

    The destination network could either lie in the same area as the ASBR,
    or in a different area. If the destination network and the ASBR are in
    the same area, the opaque traffic engineering LSAs as defined in [8]
    for the area will suffice to calculate the traffic engineering metric
    to the destination network. If the destination network lies in a
    different area than the ASBR, the weight is a combination (such as
    simple addition, or max) of the weight to the ABR and the weight
    described in the traffic engineering summary LSA originated by the ABR
    that contains the destination network. In this manner, the traffic
    engineering weights for all the networks in an AS can be computed.
    Hence the ASBRs will also be able to determine the aggregate traffic
    engineering weights across the AS to other ASBRs and use this in the
    BGP advertisements.

 5. Weights

    The traffic engineering weights act as a cost or distance function,
    describing the quality of a path to a destination network 
    in traffic engineering terms. The traffic engineering weights 
    currently proposed are:

draft-ietf-abarbanel-bgp4-te.txt                                   [page 8]

        1. Available Bandwidth (in bits/sec)
        2. Unreserved Bandwidth (in each of several classes)
        3. Colors (or class types) (8 types)
        4. Transit Delay  (in milliseconds)
        5. IGP Metric
        6. Hops

    These traffic engineering weights can be dynamically measured or
    statically configured for each interface in a node. These weights can 
    be propagated within an IGP area using the opaque traffic engineering 
    LSA. The area border routers (ABRs) can summarize the traffic engineering   
    weights to destination networks in their area and flood this information 
    into the backbone through the use of the traffic engineering summary LSA as 
    proposed in [9]. The summary LSAs can then be flooded by other ABRs into 
    their areas.

    Any ASBR can then determine the traffic engineering weight to a destination
    network by examining its traffic engineering database and performing 
    a simple dijkstra like calculation by the IGP. This calculation can 
    be true dijkstra if the weight is additive (delay, hops and IGP metric),
    or dijkstra like if the weight is a min-max constraint (available 
    bandwidth, unreserved bandwidth, and colors). Depending on the level of 
    processing desired, the number of supported weights should be
    configured. 

    These calculations result in a value for each traffic engineering 
    weight for each destination network in the AS and for each ASBR across 
    the AS. These weights from the IGP are then exported into BGP to be
    exchanged with its peers. 

    The following two subsections deal specifically with the treatment of the    
    available bandwidth and delay traffic engineering weights, during the   
    calculations:

    Maximum Available Bandwidth: 
      IBGP/IGP router within a given AS will pick the smallest available 
      Bandwidth link from the ingress to the egress of the IBGP to IBGP path and   
      use that value as the summary TE weight. Next the egress IGP will export 
      this information to BGP which will use and propagate it to its EBGP peers 
      as the first aggregated TE Weight value. As the route is propagate to each 
      IBGP peer in another AS, the Aggregated TE weight value in the message is 
      compared with the summary TE weight for the BGP Next Hop router defined in   
      the message. Whichever value is the smaller of the two, will be considered 
      the next level of aggregation value and propagated further to the next AS.   
      This mechanism will continue till the route reaches the furthest points in 
      the Internet. This way the smallest available bandwidth value will be used 
      as the overall Aggregated TE Weight value for any given route along the 
      TE path.  
  
   Maximum Delay: 
      IBGP/IGP router within a given AS will obtain the delay from the ingress
      to the egress of the IBGP to IBGP path and use that value as the summary 
      TE "delay" weight. Next the egress IGP will export this information to BGP
draft-ietf-abarbanel-bgp4-te.txt                                   [page 9]

     who will use and propagate it to its EBGP peers as the first aggregated 
     TE Weight "delay" value. As the route is propagate to each IBGP peer in 
     another AS, the Aggregated TE weight value in the message is added with 
     the summary TE "delay" weight for the BGP Next Hop router defined in the 
     message. The sum of the two is considered the next level of aggregation 
     value and propagated further to the next AS. This mechanism will
     continue till the route reaches the furthest points in the Internet.   

    *Note: See section 3.4 for Route Aggregation Impacts which must be followed 
           in order for this mechanism to be optimal. As mentioned in section 
           3.4, historical routes/TE Weights are carried in this new attribute
           for routes that are aggregated several times.

6. TE Weights Redistributed from the IGP to BGP

   In order for a given router to inherit the TE weights from IGP, a
   mechanism must be provided to do that. What is proposed is that the
   standard FDB database contain TE summary weight fields based in each
   route entry, with their TE weight type, TE weight value and
   associated AS number. In other words, in all the BGP routers, the
   running IGP will inject the TE summary weight information into the FDB
   database and signal BGP to import it to its BGP RIB database for
   propagation to other BGP peers.

7. Configuring the TE feature for BGP and IGP.

In order to minimize the amount of information produced by the TE weight parameters across the entire Internet as described in section 3.6, it is recommended that the TE weight be configured on at the network route's point
of origin. Implying that the AS router that originated the route into BGP will 
add the TE Weight attribute and all transit routers that propagate this route 
will perform the TE Weight processing when they see the TE Weight Attribute.
This way it will be possible to limit the amount of TE Weight information being
propagated across the Internet.
     
What is needed to manually configure the BGP Best Route Selection criteria:

I. To Enable TE Weight Feature for a given network

a. Define all network addresses to be enabled for TE Weight functionality.
Once enabled all transit BGP routers will process the TE Weight
aggregation and propagate the TE Weight attribute to their peers.

draft-ietf-abarbanel-bgp4-te.txt                                   [page 10]

II. To manually configure the BGP Best Route Selection criteria in each
Router along the BGP path.

a. TE Weight Type
      o Maximum Bandwidth Available (Megabits/sec)
      o Unreserved Bandwidth (in each of several classes)
      o Maximum Number of IGP Hops
      o IGP Metric
      o Maximum Transit Delay (in Milliseconds)
      o Color (or class types) (8 types)
      o Etc.

b. TE Weight Priority
       1st choice = Make this TE Weight the first choice  
                    for best BGP route selection criteria
       2nd choice = Make this TE Weight the 2nd choice
                    for best BGP route selection criteria
       nth choice = Make this TE Weight the 2nd choice
                    for best BGP route selection criteria

c. Example of BGP TE AS-Path Topology

 

    
          Figure 1. BGP TE AS-Path Topology

     [See Image]

 draft-ietf-abarbanel-bgp4-te.txt                                   [page 11]

        Table 1. Router R1 BGP TE Weight Table

   +-+-+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+++-+-+-+-+-+-+-+-+-+-+-+-++
   |Entry #  | Route  |  BGP Next Hop |  Aggregated TE Weight   |
   +-+-+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+++-+-+-+-+-+-+-+-+-+-+-+-++
   |    1    | NET1   |  R7 via R3    |  30 MB                  |
   +-+-+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+-+-+-+-+-+-
   |    2    | *NET1  |  R5 via R2    |  70 MB                  |
   +-+-+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+-+-+-+-+-+-
   |    3    | NET1   |  R10 via R3   |  60 MB                  |
   +-+-+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+-+-+-+-+-+-
   |    4    | NET1   |  R11 via R4   |  30 MB                  |
   +-+-+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+-+-+-+-+-+-
   |    5    | NET2   |  R11 via R4   |  30 MB                  |
   +-+-+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+-+-+-+-+-+-
   |    6    | NET2   |  R10 via R3   |  60 MB                  |
   +-+-+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+-+-+-+-+-+-
   |    7    | NET2   |  R7 via R3    |  30 MB                  |
   +-+-+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+-+-+-+-+-+-
   |    8    | NET2   |  R5 via R2    |  70 MB                  |
   +-+-+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+-+-+-+-+-+-

   *Note: Although we show only one TE weight type under each AS subfield
   it is possible to have multiple type of TE weights and have
   them prioritized by manual configurations in each BGP router.

   In the Figure 1. We see that R1 is the current router receiving Update
   messages from R2, R3, and R4. All the Update message contain

   The new BGP TE AS-Path Attribute with the weights as shown in Table 1.
   From this data, we see that for NET1, Entry #2 is the best choice
   amongst other NET1 entries, because it guarantees that we get 70MB
   bandwidth from AS2 and AS5. Assumption, operator had configured the TE
   AS Path (bandwidth) weight as the highest priority criteria.

   Also for NET2 entries, entry #8 is the best choice, even though it
   includes more AS hops, but it guarantees that at least 70MB of
   bandwidth will be available. This case shows, how sometimes
   sacrificing more AS hops for guaranteed service could work.

 8. Route Flapping and Impacts on Aggregated BGP TE Weights

    In the real world route flapping is a normal occurrence. It is
    expected that the router performing TE Weight Aggregation will be notified
    by the IGP that routes have gone down/up and it will be required to
    recalculate the aggregated TE Weight. Obviously, when a new aggregated TE
    weight is defined for an aggregated route, the router performing this
    calculation will be required to deploy it to its BGP peers.

 9. ISP Issues and Dependencies
    TBD

draft-ietf-abarbanel-bgp4-te.txt                                   [page 12]

 10. Conclusion

     As has been seen, the Internet is a complex Web of systems within systems,             
     scalability issues have been and will be the number one concern for all   
     major design proposals. This approach tries to bring together the loose and           
     uncooperating systems of providers into a homogenous plan of reference.
     If this spec has initiated a catalyst for change in this direction than it 
     has met its objective.

 11. Security Considerations

     The new BGP TE Weight attribute does not change the underlying security 
     issues inherent in the existing BGP design.

 12. References

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

    [2] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., McManus, J.,
        "Requirements for Traffic Engineering Over MPLS", RFC 2702, September
        1999.

    [3] Awduche, D., Rekhter, Y., Drake, J., Coltun, R., "Multi-Protocol
        Lambda Switching: Combining MPLS Traffic Engineering Control With
        Optical Crossconnects", draft-awduche-mpls-te-optical-01.txt.

    [4] Jamoussi, B. "Constraint-Based LSP Setup using LDP", Work in
        Progress, Internet Draft <draft-ietf-mpls-cr-ldp-03.txt>, September
        1999.

    [5] Braden, R., Zhang, L., Berson, S., Herzog, S., "Resource
        ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", 
        RFC 2205, September 1997.

    [6] Awduche, D. et al "Extensions to RSVP for LSP Tunnels", Work in
        Progress, Internet Draft <draft-ietf-mpls-rsvp-lsp-tunnel-04.txt,
        September 1999.

    [7] Tang, Z. et al "Extensions to CR-LDP for Path Establishment in
        Optical Networks", Internet Draft <draft-tang-crldp-optical-00.txt>
        September 2000.

    [8] Katz, D. and Yeung D., "Traffic Engineering Extensions to OSPF",
        Internet Draft <draft-katz-yeung-ospf-traffic-00.txt>

    [9] Venkatachalam, Senthil and Abarbanel, B., "Traffic Engineering
        Summary Extensions to OSPF", work in progress.
draft-ietf-abarbanel-bgp4-te.txt                                   [page 13]

    [10] Villamizar, "BGP Route Flap Damping", RFC2439, November 1998

 13.Acknowledgments

 14. Author's Addresses

     Ben Abarbanel
     Alcatel USA
     45195 Business Court, Suite 400
     Dulles, VA 20166
     email: [email-masked]
     home email: [email-masked]

     Senthil Venkatachalam
     Alcatel USA
     45195 Business Court, Suite 400
     Dulles, VA 20166
     email: [email-masked]