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

[Oliver Boehmer (oboehmer)]

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