Subject: [mpls-tp] Query on number of working LSPs in a MPLS-TP tunnel

From: venkatesan mahalingam <[email-masked]>
Date: Tue, 20 Jul 2010 20:09:40 +0530

Hi MPLS-TP Group,

As per draft *draft-ietf-mpls-tp-identifiers-02* section *2**.  Named
Entities*
   Note that we have borrowed the term tunnel from RSVP-TE (RFC
3209<http://tools.ietf.org/html/rfc3209>
)
   [2 <http://tools.ietf.org/html/draft-ietf-mpls-tp-identifiers-02#ref-2>]
where it is used to describe an entity that provides a connection
   between a source and destination LSR. * The tunnel in turn is
   instantiated by one or more LSPs, where the additional LSPs are used
   for protection or re-grooming of the tunnel.*
**
<VM> Can't we have more than one working LSPs in a tunnel? What we infer
from the above draft contents is that, only one working LSP can exist in a
tunnel and other LSPs in a tunnel are used for protection or re-grooming of
the tunnel.
IMO, we can have multiple working LSPs in a MPLS-TP tunnel for
load-balancing purposes.
-- 
Best Regards,
Venkatesan Mahalingam.

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 20 Jul 2010 20:17:41 -0400

In message <[email-masked]>
venkatesan mahalingam writes:
> <VM> Can't we have more than one working LSPs in a tunnel? What we
> infer from the above draft contents is that, only one working LSP can
> exist in a tunnel and other LSPs in a tunnel are used for protection
> or re-grooming of the tunnel.

A tunnel can have many working LSP, generally only two except in a
somewhat degenerate case.  If a tunnel is rerouted for some reason,
such as CLI change or any other reason, then using make-before-break
(as defined in RFC 3209), the new LSP is created while the old LSP is
still up and running.  After traffic has been moved to the new working
LSP, the old working LSP is deleted.  If protection is used, the old
working LSP will have a protection LSP and the new working LSP may
have a different protection LSP before the old LSP pair is deleted.

The somewhat degenerate case is where a further change is required
before the make-before-break reroute completes.  In this case a newer
working LSP is created but the signaling to take down the prior
reroute LSP may not have been completed so state can be retained.  In
a more degenerate case, this happens many times and there could be
many working LSP.  An example would be CLI increasing the bandwidth
reservation amount slightly every msec of less, but long enough
between commands for a path message to go out.

> IMO, we can have multiple working LSPs in a MPLS-TP tunnel for

That would be separate tunnels that are then concatenated using link
bundling.  Any individual tunnel could be rerouted using
make-before-break rerouting.

OTOH, Kireeti's new draft defines a new way to do RSVP-TE ECMP LSP.
(draft-kompella-mpls-rsvp-ecmp-00).  I don't think I like that
proposal since I think link bundling can already cover this, but I
await hearing what the advantages are in another week.

Curtis