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

[kevin gannon]

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/
>