Re: [mpls] WG Last Call on draft-ietf-mpls-number-0-bw-te-lsps-02.txt

"Daniel King" <daniel.king@aria-networks.com> Thu, 07 September 2006 03:16 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLANB-0005iq-2c; Wed, 06 Sep 2006 23:16:13 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLAN9-0005hM-BO for mpls@ietf.org; Wed, 06 Sep 2006 23:16:11 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GL61w-00026G-BU for mpls@ietf.org; Wed, 06 Sep 2006 18:38:00 -0400
Received: from mail1.noc.data.net.uk ([80.68.34.48]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GL53g-0002KC-Of for mpls@ietf.org; Wed, 06 Sep 2006 17:35:51 -0400
Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail1.noc.data.net.uk with esmtp (Exim 3.36 #2) id 1GL50z-0000mq-00 for mpls@ietf.org; Wed, 06 Sep 2006 22:32:57 +0100
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
Subject: Re: [mpls] WG Last Call on draft-ietf-mpls-number-0-bw-te-lsps-02.txt
Date: Wed, 06 Sep 2006 22:32:31 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Message-ID: <3D1918258E6DE14DAAABBD34D53D293408D5A6@cortex.aria-networks.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Re: [mpls] WG Last Call on draft-ietf-mpls-number-0-bw-te-lsps-02.txt
Thread-index: AcbR+/Vw1zM2Bst5TV2mM2Wf5cvAZg==
From: Daniel King <daniel.king@aria-networks.com>
To: mpls@ietf.org
X-Spam-Score: -2.6 (--)
X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248
Cc:
X-BeenThere: mpls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/mpls>
List-Post: <mailto:mpls@lists.ietf.org>
List-Help: <mailto:mpls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@lists.ietf.org?subject=subscribe>
Errors-To: mpls-bounces@lists.ietf.org

Hi Guys,

I believe there are some situations where balancing the number of zero
bandwidth LSPs across the network may be very helpful. Certainly one
example arises where there are lots of zero bandwidth LSPs and
statistical techniques may be used to predict the aggregate load of the
LSPs on a link. I might think of other situations, including where the
only use of zero bandwidth LSPs is for FRR. 

For me the point that is not sufficiently clear from the current text is
that the load balancing does not just apply to the placement of new
unconstrained LSPs. I think it's important to highlight that the
information can also be used to determine onto which LSPs to place
traffic in the traffic classification function.

In order to clarify the purpose of the I-D and to address Adrian's
point, I would like to suggest the following change to the I-D in the
Introduction (section 1).

OLD
   With MPLS Traffic Engineering a usual rerouting criteria is the
   discovery of a better path for a TE LSP where a better path is
   defined as a path with a lower cost according to a specific metric;
   other metric such that the percentage of reserved bandwidth or the
   number of hops can also be used.  Unfortunately, for instance in the
   presence of ECMPs (Equal Cost Multi-Paths) in symmetrical networks
   when unconstrained TE LSP are used, such metrics are usually
   ineffective and may lead to poorly load balanced traffic.  If the
   number of unconstrained TE LSPs traversing each link in the network
   is known, various algorithms can be designed so as to efficiently
   load balance the traffic carried onto such unconstrained TE LSPs.  As
   currently defined in [RFC3630] and [I-D.ietf-isis-te-bis] the
   information related to the number of unconstrained TE LSP(s) is not
   available.  This document specifies a new Link-type Traffic
   Engineering sub-TLV used to indicate the number of unconstrained TE
   LSP signalled across a link.

NEW
   With MPLS Traffic Engineering a usual rerouting criteria is the
   discovery of a better path for a TE LSP where a better path is
   defined as a path with a lower cost according to a specific metric;
   other metric such that the percentage of reserved bandwidth or the
   number of hops can also be used.  Unfortunately, for instance in the
   presence of ECMPs (Equal Cost Multi-Paths) in symmetrical networks
   when unconstrained TE LSP are used, such metrics are usually
   ineffective and may lead to poorly load balanced traffic.  If the
   number of unconstrained TE LSPs traversing each link in the network
   is known, various algorithms can be designed so as to efficiently
   load balance the traffic carried onto such unconstrained TE LSPs.

   These algorithms can be used to determine the routes of new
   unconstrained LSPs, or can re-route existing LSPs. The algorithms
   are not limited to simple balancing of the number of zero bandwidth
   LSPs - they can also make use of statistical assumptions about the
   LSPs loads in order to ensure even traffic loading.

   Further, the knowledge of the number of zero bandwidth LSPs
   traversing each link in the network can be used by traffic
   classification algorithms to select which flows will be placed on
   which LSPs with some understanding of the likely loading within the
   network.

   Lastly, FRR failure procedures may select between two or more
   available backup tunnels according to the predicted load within the
   network.

   As currently defined in [RFC3630] and [I-D.ietf-isis-te-bis] the
   information related to the number of unconstrained TE LSP(s) is not
   available. This document specifies a new Link-type Traffic
   Engineering sub-TLV used to indicate the number of unconstrained TE
   LSP signalled across a link.


Thanks,
Dan

Daniel King
Aria Networks
www.aria-networks.com

_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls