[c-nsp] mpls-te - dynamic latency?

Oliver Boehmer (oboehmer) oboehmer at cisco.com
Thu Apr 6 11:26:14 EDT 2006


christian.macnevin at uk.bnpparibas.com
<mailto:christian.macnevin at uk.bnpparibas.com> wrote on Thursday, April
06, 2006 12:22 PM:

> Not dealt with african providers before have you? :) Unfortunately,
> VSAT is a fact of life for many, and the shortage 
> of fat pipes in the big continent requires live/live configs. Much as
> I hated it at first, we gotta move on and find a way. 

I know, I know, hence the ";-)" behind my comment..

> I've been looking at the MTR stuff, and frankly it looks like a dream
> come true. Chetan tells me we're looking at 2007 for 
> the first release though, so we're going to need some black magic in
> the meantime.

sounds about right, and you need this on all platforms involved..

> Incidentally, I'd recommend a few 
> people take a look at this, because others must be suffering some of
> the same pain we are, and if this looks like a solution 
> to others as well, it'd be good if Cisco realised customers had
> interest in the availability of application-layer routing
> capabilities without the evil.

Ack, and this is where MFR could fit in (as far as I understood, don't
know too much about MTR)..

> Looking at OER, it seems like it'll still only work on destination
> prefix - ie: no layer 4 awareness. Not true? 

Right, OER modifies the RIB, hence it operates on L3.

The question is whether you have any option moving this from L4 to L3 by
using distinct prefixes/addresses for your sensitive traffic. Then you
can use routing mechanisms to steer the traffic either way (I think I
made an error mentioning PBR with TE on a PE, don't think this will
work). 

PE-PE TE tunnels with a modification of the BGP next-hop could do the
trick here. As a rough idea:
- create a new loopback address on each PE
- Full mesh of PE-PE TE-Tunnels with two path-options: #1 goes via
explit-path along the low-delay links,  #2 uses any path in case #1 is
not available. no autoroute, no FA, enable LDP on the tunnel
- statically route the loopback to the tunnel
- set the BGP next-hop for the "voice" BGP prefixes to the new loopback
routed via the Tunnel. you could do this next-hop rewrite based on acl,
community, etc.. it could get more complicated if you have multi-homed
sites (you do) and you are using RRs as the new next-hop obviously
depends on which remote PE advertised the prefix..

	oli



More information about the cisco-nsp mailing list