Re: [RRG] Traffic Engineering scenarios
Jason Schiller <schiller@uu.net> Wed, 20 February 2008 19:03 UTC
Envelope-to: rrg-data@psg.com
Delivery-date: Wed, 20 Feb 2008 19:05:24 +0000
Date: Wed, 20 Feb 2008 14:03:39 -0500
From: Jason Schiller <schiller@uu.net>
Subject: Re: [RRG] Traffic Engineering scenarios
To: Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be>
Cc: Randall Atkinson <rja@extremenetworks.com>, IRTF Routing RG <rrg@psg.com>
Message-id: <Pine.GSO.4.20.0802201151150.29661-100000@meno.corp.us.uu.net>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset="US-ASCII"
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
- [RRG] Traffic Engineering scenarios Randall Atkinson
- Re: [RRG] Traffic Engineering scenarios Olivier Bonaventure
- RE: [RRG] Traffic Engineering scenarios Randall Atkinson
- Re: [RRG] Traffic Engineering scenarios Jason Schiller
- Re: [RRG] Traffic Engineering scenarios Pekka Savola