Re: [mpls] WG Last Call on draft-ietf-mpls-number-0-bw-te-lsps-02.txt
JP Vasseur <jvasseur@cisco.com> Wed, 20 September 2006 14:13 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ2p0-0004uW-Ci; Wed, 20 Sep 2006 10:13:06 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ2oy-0004uM-Sb for mpls@ietf.org; Wed, 20 Sep 2006 10:13:04 -0400
Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ2ox-0003pL-FN for mpls@ietf.org; Wed, 20 Sep 2006 10:13:04 -0400
Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 20 Sep 2006 07:13:03 -0700
X-IronPort-AV: i="4.09,192,1157353200"; d="scan'208"; a="42683493:sNHT36912196"
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8KED3RJ029475; Wed, 20 Sep 2006 10:13:03 -0400
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k8KECwuU018678; Wed, 20 Sep 2006 10:13:03 -0400 (EDT)
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Sep 2006 10:13:02 -0400
Received: from [10.86.104.178] ([10.86.104.178]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Sep 2006 10:13:01 -0400
In-Reply-To: <3D1918258E6DE14DAAABBD34D53D293408D5A6@cortex.aria-networks.com>
References: <3D1918258E6DE14DAAABBD34D53D293408D5A6@cortex.aria-networks.com>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <41B6DE71-7322-42A0-B5E1-C1597CDA8E39@cisco.com>
Content-Transfer-Encoding: 7bit
From: JP Vasseur <jvasseur@cisco.com>
Subject: Re: [mpls] WG Last Call on draft-ietf-mpls-number-0-bw-te-lsps-02.txt
Date: Wed, 20 Sep 2006 10:13:00 -0400
To: Daniel King <daniel.king@aria-networks.com>
X-Mailer: Apple Mail (2.752.2)
X-OriginalArrivalTime: 20 Sep 2006 14:13:01.0884 (UTC) FILETIME=[E1EB77C0:01C6DCBE]
DKIM-Signature: a=rsa-sha1; q=dns; l=4585; t=1158761583; x=1159625583; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:JP=20Vasseur=20<jvasseur@cisco.com> |Subject:Re=3A=20[mpls]=20WG=20Last=20Call=20on=20draft-ietf-mpls-number-0-bw-te- lsps-02.txt |To:Daniel=20King=20<daniel.king@aria-networks.com>; X=v=3Dcisco.com=3B=20h=3DfkV2y+EVEGcpQTA/1apBr/YmWrg=3D; b=UivkvHp+vF4WbooryWVs3ZerZ8G8ta2TPSpKEjQ3nOtJC6HBdU0JacA1XJjDT4VWTbaJbZjd AWyjaoI1n3T6M5y4BNKyq2tq8Sa+ht2CrUXtUPZy/0CZDQm7IZkMiS83;
Authentication-Results: rtp-dkim-2.cisco.com; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b
Cc: mpls@ietf.org
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 Daniel, I just replied to Adrian's email with a new text that should address your comments. We'd prefer not to discuss the traffic assignment aspect since it is a local decision that can be governed by a number of criterion (out of the scope). Thanks for your comments. JP. On Sep 6, 2006, at 5:32 PM, Daniel King wrote: > 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 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