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

Thu Apr 6 06:53:44 EDT 2006

Yes.

Internet
kevin at gannons.net

Sent by: kgannon at gmail.com
06/04/2006 11:44

To
Christian MACNEVIN
cc
oboehmer, cisco-nsp
Subject
Re: [c-nsp] mpls-te - dynamic latency?

Does the traffic selection need to be based on something more than
the source/destination address ?

Regards
Kevin

On 4/6/06, christian.macnevin at uk.bnpparibas.com <
christian.macnevin at uk.bnpparibas.com> wrote:
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'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. 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.

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

Internet
oboehmer at cisco.com

06/04/2006 08:36

To
Christian MACNEVIN
cc
cisco-nsp
Subject
RE: [c-nsp] mpls-te - dynamic latency?

Christian,

this looks indeed like a complex requirement, and likely not very 
scalable (i.e. if you have many remote sites requiring to go to a
central site this way).
One option could be the use of OER on the CE to offload the path
selection to the CE. The CE is presented with multiple exit points (not 
sure if this is possible), and the CE would use the path with the lowest
latency/delay (using an IP-SLA/SAA probe).

The best option would be to re-engineer your core so it provides the
same good service everywhere ;-) 

                 oli

christian.macnevin at uk.bnpparibas.com
<mailto:christian.macnevin at uk.bnpparibas.com > wrote on Wednesday, April
05, 2006 4:15 PM:

> Ok, I've looked at this a little bit more, and I'm not sure TE will
> do what we want entirely.
>
> For a multihomed site, we need to be able to select the mpls exit 
> point based on the type of traffic being sent.
> From the point of view of the vpn, TE is essentially a layer 2
> concept (the cloud is invisible, so essentially we're
> just figuring out how we treat the layer 2 link it sees between PEs). 
> The exit point is a layer 3 concept, and the
> application flow itself is layer 4.
>
> Assuming two entry points to the mpls cloud and two exit points, it's
> looking like we'll need to manipulate the preferred 
> exit point to a multihomed network using BGP (one entry PE preferring
> the exit PE with the lowest latency link to the core, the other PE
> preferring the one with the highest latency). If we want to guarantee 
> the path between the entry and exit PEs,
> we can use TE. In order to make sure the traffic gets to the right
> entry PE (one fast, one slow) we'll need to use PBR
> coupled to an HSRP address for each type. 
>
> Basically, it's getting nasty.
>
> Are any of my assumptions so far wrong? Is there a faster way of
> solving this?
>
>
>
>
>
> Internet
> oboehmer at cisco.com
>
> 04/04/2006 23:15
>
>
> To
>                Christian MACNEVIN
> cc
>                cisco-nsp
> Subject
>                RE: [c-nsp] mpls-te - dynamic latency? 
>
>
>
>
>
>
>> Well, we'll be migrating from eigrp, not ospf, so yes, we do need
>> is-is :)
>
> Oh, ok, right, you obviously need ISIS or OSPF..
>
>> And as far as ds-te goes, I guess I need to understand that feature a
>> little better to comment whether I feel I need
>> it just yet, But the end goal (whether it's that feature or not) is
>> that we'd the tunnel to be as visible to the routing protocol as poss
>> (autoroute i guess) and be routing traffic into those tunnels based
>> on dscp markings. If I can  avoid 'invisible' mechanisms like pbr, 
>> than I will.
>
> Aaron mentioned CBTS, which is able to achieve this without PBR or
> anything, but it requires parallel tunnels between head and tail, then
> you could use autoroute and CBTS to send the traffic over the 
> respective
> tunnel.
> DS-TE doesn't help you here at all, DS-TE essentially just makes sure
> we
> don't send too much delay-sensitive traffic over links by using
> distinct
> BW pools. It does not address forwarding traffic down the tunnel in 
> any
> way.
>
>> Also, it's not just a matter of making sure the low latency path is
>> chosen, but that non-latency-dependent traffic will use the other
>> link.
>
> With this objective in mind, I guess parallel tunnels with CBTS will
> do
> what you want.
>
>> As for using the affinity bits, cheers, I'll look more into that.
>
> You definitly need this to make sure that the "voice" tunnel only uses 
> those links and the best-effort tunnel uses other links. It obviously
> requires discipline when setting up the links..
>
> Multi-Topology Routing would be another option, but this feature is
> not
> there yet..
>
>                 oli
>
>
>
> This message and any attachments (the "message") is
> intended solely for the addressees and is confidential. 
> If you receive this message in error, please delete it and
> immediately notify the sender. Any use not in accord with
> its purpose, any dissemination or disclosure, either whole
> or partial, is prohibited except formal approval. The internet 
> can not guarantee the integrity of this message.
> BNP PARIBAS (and its subsidiaries) shall (will) not
> therefore be liable for the message if modified.
>
>
************************************************************************ 
**********************
>
> BNP Paribas Private Bank London Branch is authorised
> by CECEI & AMF and is regulated by the Financial Services
> Authority for the conduct of its investment business in 
> the United Kingdom.
>
> BNP Paribas Securities Services London Branch is authorised
> by CECEI & AMF and is regulated by the Financial Services
> Authority for the conduct of its investment business in 
> the United Kingdom.
>
> BNP Paribas Fund Services UK Limited is authorised and
> regulated by the Financial Services Authority

_______________________________________________
cisco-nsp mailing list   cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/