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
- [mpls] WG Last Call on draft-ietf-mpls-number-0-b… Loa Andersson
- Re: [mpls] WG Last Call on draft-ietf-mpls-number… Adrian Farrel
- Re: [mpls] WG Last Call on draft-ietf-mpls-number… Loa Andersson
- Re: [mpls] WG Last Call on draft-ietf-mpls-number… Adrian Farrel
- Re: [mpls] WG Last Call on draft-ietf-mpls-number… Daniel King
- Re: [mpls] WG Last Call on draft-ietf-mpls-number… Dimitri.Papadimitriou
- Re: [mpls] WG Last Call on draft-ietf-mpls-number… Loa Andersson
- Re: [mpls] WG Last Call on draft-ietf-mpls-number… JP Vasseur
- Fwd: [mpls] WG Last Call on draft-ietf-mpls-numbe… JP Vasseur
- Re: [mpls] WG Last Call on draft-ietf-mpls-number… JP Vasseur