[j-nsp] Link aggregation and RSVP

[Danny Vernals]

Hi Kris,

Link aggregation is generally a good idea with RSVP.  It's easier to
pack LSPs into one big chunk of bandwidth than to pack into multiples
of smaller bandwidths.

You'll need to turn on aggressive pre-emption as this enables the
transit LSR to signal ingress LSRs to move LSPs off a link when the
available bandwidth reduces i.e. in case of a link failure.

Also beware of bundling links that have a large difference in RTD.
Jitter shouldn't be a problem as hashing is per flow or per IP but you
loose the ability of favouring lower latency links via IGP metric when
there is bandwidth available in the network.

Depending on your topology you might run into some problems with
hashing but this can be solved with indexed next-hop (hash on permuted
list of the different levels of ECMP rather than hashing at each
level).

Cheers!

Danny

On Thu, May 6, 2010 at 4:09 AM, Kris Price <juniper-nsp at punk.co.nz> wrote:
> Hi all,
>
> The subject is using link aggregation with RSVP. Or just generally the
> subject of how best to handle multiple parallel links between adjacent
> routers in a MPLS network. I'm hoping the list can provide guidance on the
> best practise for this, or point me to useful material.
>
> The context is outside of a data centre, in the core of a national carrier
> network (P/P and P/PE links).
>
> Link aggregation is the simplest option, but I am weary there may be
> problems with this approach. E.g. with the hashing algorithms and how this
> might impact on reported versus actual bandwidth for constrained LSP set up.
> Or with fast reroute, or failover from primary to secondary LSPs, when one
> of the links in the bundle fails.
>
> Thoughts, insights, experiences, pointers, appreciated.
>
> Cheers
> Kris
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>