Re: [RRG] Traffic Engineering scenarios

[Jason Schiller <schiller@uu.net>]

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                       schiller@uu.net
UUNET / Verizon                         jason.schiller@verizonbusiness.com

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 <Olivier.Bonaventure@uclouvain.be>
> To: Randall Atkinson <rja@extremenetworks.com>
> Cc: IRTF Routing RG <rrg@psg.com>
> Subject: Re: [RRG] Traffic Engineering scenarios
> 
> Randall,
> 
> > 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.
> 
> 
> 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
> 
> --
> to unsubscribe send a message to rrg-request@psg.com 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
> 



--
to unsubscribe send a message to rrg-request@psg.com 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