Subject: [RADIR] Section 4.1: Traffic Engineering

From: Thomas Narten <[email-masked]>
Date: Thu, 31 May 2007 15:11:43 -0400

Here is an attempt at 4.1. This comes from the RAWS report, plus
wordsmithing.

   Traffic engineering (TE) is the act of arranging for certain
   Internet traffic to use or avoid certain network paths (that is, TE
   attempts to place traffic where capacity exists, or where some set
   of parameters of the path is more favorable to the traffic being
   placed there).

   Inbound TE is performed by announcing a more specific route along
   the preferred path that "catches" the desired traffic and channels
   it away from the path it would take otherwise (i.e., via a larger
   aggregate).  At the BGP level, if the address range requiring TE is
   a portion of a larger address aggregate, network operators
   implementing TE are forced to de-aggregate otherwise aggregatable
   prefixes in order to steer the traffic of the particular address
   range to specific paths.

   TE is performed by both ISPs and customer networks, for three
   primary reasons:

   o  First, to match traffic with network capacity,
      or to spread the traffic load across multiple links (frequently
      referred to as "load balancing").

   o  Second, to reduce costs by shifting traffic to lower cost paths or
      by balancing the incoming and outgoing traffic volume to maintain
      appropriate peering relations.

   o Finally, TE is sometimes deployed to enforce certain forms of
      policy (e.g., government traffic may not be permitted to transit
      through other countries).

   TE impacts route scaling in two ways. First, inbound TE can result
   in additional prefixes being advertised into the DFZ. Second,
   Network operators usually achieve traffic engineering by "tweaking"
   the processing of routing protocols to achieve desired results,
   e.g., by sending updates at an increased rate.

   In today's highly competitive environment, providers require TE to
   maintain good performance and low cost in their networks.  

Thomas

_______________________________________________
RADIR mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/radir

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 31 May 2007 14:07:46 -0700

>    prefixes in order to steer the traffic of the particular address

Given that we talk about Inbound TE it would be good to also add some 
text about Outbound TE, even if it is just to say that it isn't a 
significant source of deaggregation.
Jason had sent some text which I think included words about outbound TE.

    Erik