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

From: "Daniel King" <[email-masked]>
Date: Wed, 6 Sep 2006 22:32:31 +0100

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

---

From: JP Vasseur <[email-masked]>
Date: Wed, 20 Sep 2006 10:13:00 -0400

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.