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

[christian.macnevin at uk.bnpparibas.com]

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