The MPLS WG Archive

[JP Vasseur <jvasseur@cisco.com>]

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