Subject: [RRG] Traffic Engineering scenarios

From: Randall Atkinson <[email-masked]>
Date: Tue, 19 Feb 2008 09:56:10 -0800

On occasions when I have talked with IP service providers about
traffic engineering, I have heard very different inputs from each
ISP.

It would be very helpful, I think, for the sundry ISP-aware folks
here to write up I-Ds on the various TE deployment scenarios
that they care about, what issues those TE deployments seek
to solve, and so forth.

I am sure it would help educate me.  I suspect it might well
educate others also.  Getting more information about TE usage
practices out for everone to read would seem very helpful.

Yours,

Ran
[email-masked]

--
to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg

---

From: Olivier Bonaventure <[email-masked]>
Date: Tue, 19 Feb 2008 20:39:02 +0100

Randall,

> that they care about, what issues those TE deployments seek

Jason Schiller did this exercice some years ago, see :

http://www.nanog.org/mtg-0505/pdf/schiller.pdf

We have used these case studies to develop a new service that would 
allow network operators to influence the paths selected by hosts in a 
shim6 environment, or ITR in a LISP environment. Please find below the 
abstract of the two drafts. The will appear on the IETF mirrors. In the 
meantime, they can be retrieved from http://inl.info.ucl.ac.be/publications

      Title           : The case for an informed path selection service
      Author(s)       : O. Bonaventure, D. Saucez, B. Donnet
      Filename        : draft-bonaventure-informed-path-selection-00.txt

With today's peer-to-peer applications, more and more content is
available from multiple sources.  In tomorrow's Internet hosts will
have multiple paths to reach one destination host with the deployment
of dual-stack IPv4/IPv6 hosts, but also with new techniques such as
shim6 or other locator/identifier mechanisms being discussed within
the IRTF RRG.  All these hosts will need to rank paths in order to
select the best paths to reach a given destination/content.  In this
draft, we propose an informed path selection service that would be
queried by hosts and would rank paths based on policies and
performance metrics defined by the network operator to meet his
traffic engineering objectives.  A companion document describes a
protocol that implements this service.

      Title           : IDIPS : ISP-Driven Informed Path Selection
      Author(s)       : D. Saucez, et al.
      Filename        : draft-saucez-idips-00.txt

This draft describes a simple network-based protocol to facilitate
Path Selection and to improve traffic engineering capabilities in
multihomed corporate networks.  With this protocol, any network
device that requires to select a path among a list of different paths
asks a Traffic Engineering service called IDIPS (ISP-Driven Informed
Path Selection) to obtain an ordered list of the possible paths.  The
ordering is constructed according to policies and performance
requirements of both the host and network provider.

Olivier

-- 
http://inl.info.ucl.ac.be , Universite catholique de Louvain, Belgium

---

From: Randall Atkinson <[email-masked]>
Date: Tue, 19 Feb 2008 12:35:29 -0800

________________________________________
From: Olivier Bonaventure [[email-masked]]
Sent: 19 February 2008 14:39
To: Randall Atkinson
Cc: IRTF Routing RG
Subject: Re: [RRG] Traffic Engineering scenarios

% Jason Schiller did this exercice some years ago, see :
%
% http://www.nanog.org/mtg-0505/pdf/schiller.pdf

Thanks !

It would still be useful for other folks to write up their
uses.  TE use seems to vary widely from one ISP to
another -- and also over time.  So getting a broader
range documented here would be nice. :-)

---

From: Jason Schiller <[email-masked]>
Date: Wed, 20 Feb 2008 14:03:39 -0500 (EST)

RAN,

The presentation sited in the thread focuses on end-site TE.
http://www.nanog.org/mtg-0505/pdf/schiller.pdf

I also did a presentation at the IAB Routig and Address workshop that is a
condensed version with a short section on transit provider TE.

http://www.iab.org/about/workshops/routingandaddressing/schiller-IAB-TE-cases.pdf

On the IAB preso, there was not a lot of time, so very few slides, I
don't think anyone has the audio, and it looks like the PPT is not posted
so the animation is broken.  Below is an email summary of the discussion
around these slides.

If people think it useful to otherwise document, discuss, or represent
these I'd be happy to put together a somewhat long presentation, have a
discussion, of collaborate on a document (time and travel permitting).

The high level summary on the transit provider TE is:
=== Slide 15 ===
Transit ASes generally honor the in bound preferences of their customers
who pay them for service.  Once the customer sends the traffic to the ISP
it is the ISP's job to forward the traffic closer to the destination.  If
multiple equally good paths are available, the ISP can use TE to make some
paths more or less preferred.  The local TE decesion is reflected in the
total end-to-end cost of the path.

=== Slide 16 and 17 ===
Smaller ISPs who purchase transit from one or more up streams often use TE
towards their transit providers.  They may do this to optimize on best
performance, low latency, high reachability, or to squeeze as much traffic
out of their expensive transit links.

Imagine a large South American ISP that has 16 STM-1s to each of its two
transit providers with half of the links on two different cable
systems.  Imagine that the STM-1s are expensive and as a result, in
general, the ISP wants to load them ass full as possible.  Additionally,
one of the oceanic cable systems has better performance, and one of the
two up stream providers has better service and support.  It is important
some critical customers be guaranteed to be on the better performing cable
system and be delivered to the higher performance and better supported up
stream provider.  

=== Slide 18 & 19 ===
Most larger transit providers do not purchase transit, and instead Peer
with all of the large ASes in the DFZ.  If a Peering point becomes over
loaded, the transit provider will attempt to push traffic away from the
hot Peering point.  This can be accomplished by adding some additional IGP
distance to that particular Peer on the hot Peering point.  In the even
that the destination is multi-homed equally as well to the Peer which is
running hot, and another Peer at the same location, then the traffic will
migrate over to the other Peer.  In the event that the destination is not
multi-homed equally well, then some of the traffic will exit out of the
next nearest Peering point for this Peer.

__Jason

==========================================================================
Jason Schiller                                               (703)886.6648
Senior Internet Network Engineer                         fax:(703)886.0512
Public IP Global Network Engineering                       [email-masked]
UUNET / Verizon                         [email-masked]

The good news about having an email address that is twice as long is that
it increases traffic on the Internet.

On Tue, 19 Feb 2008, Olivier Bonaventure wrote:

> Date: Tue, 19 Feb 2008 20:39:02 +0100
> From: Olivier Bonaventure <[email-masked]>
> To: Randall Atkinson <[email-masked]>
> Cc: IRTF Routing RG <[email-masked]>

---

From: Pekka Savola <[email-masked]>
Date: Thu, 21 Feb 2008 11:06:52 +0200 (EET)

> system and be delivered to the higher performance and better supported up

Maybe one thing that should be noted in this context about transit 
contracts (I guess this is pretty common, but not sure): 1) you have 
to pay for the higher of up/downlink, and 2) you have a contracted 
basic rate which you will pay whether you have traffic on the link or 
not (and then the rate you pay for exceeding that).

If you want to optimize costs (and optimization could be very 
significant here), you may need to 1) balance both in/outbound traffic 
to a particular transit ISP to be as close to each other as possible, 
and 2) be able to put roughly the desired amount of load on different 
transit providers.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings