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

Curtis Villamizar <curtis@occnc.com> Wed, 21 July 2010 00:17 UTC

Return-Path: <curtis@occnc.com>
X-Original-To: mpls-tp@core3.amsl.com
Delivered-To: mpls-tp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E2543A6925 for <mpls-tp@core3.amsl.com>; Tue, 20 Jul 2010 17:17:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.426
X-Spam-Level:
X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zxq3e9GMRv6s for <mpls-tp@core3.amsl.com>; Tue, 20 Jul 2010 17:17:27 -0700 (PDT)
Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id 332C73A67FA for <mpls-tp@ietf.org>; Tue, 20 Jul 2010 17:17:27 -0700 (PDT)
Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id o6L0HfIW072545; Tue, 20 Jul 2010 20:17:41 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com)
Message-Id: <201007210017.o6L0HfIW072545@harbor.orleans.occnc.com>
To: venkatesan mahalingam <venkatflex@gmail.com>
From: Curtis Villamizar <curtis@occnc.com>
In-reply-to: Your message of "Tue, 20 Jul 2010 20:09:40 +0530." <AANLkTilLSRwdDlrcxqvew2gTEOVqMoQcewWXEAqWM04z@mail.gmail.com>
Date: Tue, 20 Jul 2010 20:17:41 -0400
Sender: curtis@occnc.com
Cc: mpls-tp@ietf.org
Subject: Re: [mpls-tp] Query on number of working LSPs in a MPLS-TP tunnel
X-BeenThere: mpls-tp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: curtis@occnc.com
List-Id: MPLS-TP Mailing list <mpls-tp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls-tp>, <mailto:mpls-tp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls-tp>
List-Post: <mailto:mpls-tp@ietf.org>
List-Help: <mailto:mpls-tp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls-tp>, <mailto:mpls-tp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Jul 2010 00:17:28 -0000

In message <AANLkTilLSRwdDlrcxqvew2gTEOVqMoQcewWXEAqWM04z@mail.gmail.com>
venkatesan mahalingam writes:
>  
>  
> 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.

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
> load-balancing purposes.

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.

> -- 
> Best Regards,
> Venkatesan Mahalingam.

Curtis