[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [mpls] Re: CCAMP Last call on draft-deoliveira-diff-te-preemption-06.txt
Hi -
let's then discuss the policy selection further - are these
not dependent on the objectives - rather than be selected /
defined independently - ?
this question is fundamental to the understanding of the
obtained results - i mean it may simply that with another
simple "policy" both would have result in the same outcome
i see here a potential discussion item for next f2f meeting -
do you agree ?
thanks,
- d.
Jaudelice Cavalcante de Oliveira <jau@cbis.ece.drexel.edu>
15/01/2007 20:23
To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
cc: mpls@lists.ietf.org, ccamp@ops.ietf.org, Ross Callon
<rcallon@juniper.net>, owner-ccamp@ops.ietf.org, JP Vasseur
<jvasseur@cisco.com>
Subject: Re: [mpls] Re: CCAMP Last call on
draft-deoliveira-diff-te-preemption-06.txt
Hi Dimitri,
On Jan 12, 2007, at 4:31 PM, Dimitri.Papadimitriou@alcatel-lucent.be
wrote:
> hi -
>
> thanks for the reply - not sure you ever got the following response
> back
>
> ----- Forwarded by Dimitri PAPADIMITRIOU/BE/ALCATEL on 12/01/2007
> 22:30
> -----
> Dimitri PAPADIMITRIOU
> 07/01/2007 11:43
> To: Jaudelice Cavalcante de Oliveira
> <jau@cbis.ece.drexel.edu>
>
> Hi
>
> thanks for the answer - i am still looking at the reason
> why the PN selection process is driven by a uniform policy
> which looks like an arbitrary choice
>
> HBlock aims at minimizing the blocking probability
> PN aims at minimizing the system perturbation
>
> to have a fair analysis policy should be applied uniformly
> and non-uniformly to both cases
>
Both policies were applied in the same manner. The difference is in
the selection of LSPs for preemption (largest or smallest). We chose
to keep the policies simple.
I appreciate your feedback. I'd be happy to meet with you and discuss
it further at the next IETF meeting as well.
Many thanks,
Jau.
> much thanks,
> - d.
>
> --
>
>
>
>
> Jaudelice Cavalcante de Oliveira <jau@cbis.ece.drexel.edu>
> 05/01/2007 00:11
>
> To: Dimitri.Papadimitriou@alcatel-lucent.be
> cc: mpls@lists.ietf.org, JP Vasseur <jvasseur@cisco.com>,
> ccamp@ops.ietf.org, Jaudelice Cavalcante de Oliveira
> <jau@cbis.ece.drexel.edu>, Ross Callon <rcallon@juniper.net>,
> owner-ccamp@ops.ietf.org
> Subject: [mpls] Re: CCAMP Last call on
> draft-deoliveira-diff-te-preemption-06.txt
>
>
> Hi Dimitri,
>
> Thank you for your comment.
>
> On Dec 18, 2006, at 3:47 AM, Dimitri.Papadimitriou@alcatel-lucent.be
> wrote:
>
>> adrian -
>>
>> in HBlock case the average wasted bw is a factor 10 smaller than
>> for any
>> other scheme (without significantly lowering the worst case, still an
>> order of 10)
>
> Indeed. This can be seen in table 2. In this case, selection of LSPs
> much larger than
> the required bandwidth did not occur often. The worst case value does
> not reflect the
> frequency with which a high bandwidth LSP was selected (which was
> very rarely in
> this case, therefore the low "wasted" bandwidth).
>
>> the only noticeable difference with PN is exactly that one (which is
>> induced by the possibility left to Hblock to have two selection
>> depending
>> on heavy vs normal loaded link) - hence it would be interesting to
>> know
>> the dependency on the min/max LSP bw and distribution (scenario
>> dependancy) and have a similar PN approach (non-uniform selection)
>
> Note that PN has the objective of preempting a small number of LSPs
> of the lowest
> priority (therefore ordering by decreasing bandwidth), while HBlock
> aims at minimizing
> the blocking probability, therefore selecting smaller LSPs which will
> be more likely to be
> rerouted once preempted. This is the main difference between the two
> policies: Given a set
> of LSPs with the same priority, PN picks the largest (in the interest
> of picking few) and HBlock
> picks smaller ones (even if more than one, in the interest of being
> able to reroute them easily).
>
> I hope this helps,
>
> Thanks,
>
> Jaudelice.
>
>>
>> thanks,
>> - d.
>>
>>
>>
>>
>>
>>
>> "Adrian Farrel" <adrian@olddog.co.uk>
>> Sent by: owner-ccamp@ops.ietf.org
>> 14/12/2006 18:02
>> Please respond to "Adrian Farrel"
>>
>> To: <ccamp@ops.ietf.org>
>> cc: <jau@cbis.ece.drexel.edu>, "Ross Callon"
>> <rcallon@juniper.net>, "Brungard, Deborah A, ALABS"
>> <dbrungard@att.com>,
>> <mpls@lists.ietf.org>
>> Subject: Re: CCAMP Last call on
>> draft-deoliveira-diff-te-preemption-06.txt
>>
>>
>> Hi,
>>
>> I have been explicitly asked to lengthen this last call so as to
>> allow
>> time
>> for a review.
>>
>> Unusual, but not unreasonable.
>>
>> The last call is extended to noon on Sunday 17th December.
>>
>> Thanks,
>> Adrian
>> ----- Original Message -----
>> From: "Adrian Farrel" <adrian@olddog.co.uk>
>> To: <ccamp@ops.ietf.org>
>> Cc: <jau@cbis.ece.drexel.edu>; "Ross Callon" <rcallon@juniper.net>;
>> "Brungard, Deborah A, ALABS" <dbrungard@att.com>;
>> <mpls@lists.ietf.org>
>> Sent: Wednesday, November 29, 2006 11:06 AM
>> Subject: CCAMP Last call on draft-deoliveira-diff-te-
>> preemption-06.txt
>>
>>
>>> Hi,
>>>
>>> This draft has been developed independently and has recently been
>> brought
>>> to the IESG for advancement as an individual submission to become an
>>> Informational RFC. I have done a first-level review and this latest
>>> revision includes updates to reflect my comments.
>>>
>>> Since the material here concerns preemption and the suggested
>>> ways to
>>> operate an MPLS-TE or GMPLS network, we are running a quick last
>>> call on
>>
>>> the CCAMP mailing list to ensure that no-one has any objections.
>>>
>>> Please send your comments to the CCAMP list no later than noon
>>> GMT on
>> 13th
>>> December 2006.
>>>
>>> Thanks,
>>> Adrian
>>> ----- Original Message -----
>>> From: <Internet-Drafts@ietf.org>
>>> To: <i-d-announce@ietf.org>
>>> Sent: Tuesday, November 28, 2006 8:50 PM
>>> Subject: I-D ACTION:draft-deoliveira-diff-te-preemption-06.txt
>>>
>>>
>>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>>> directories.
>>>>
>>>>
>>>> Title : LSP Preemption Policies for MPLS Traffic Engineering
>>>> Author(s) : J. de Oliveira, et al.
>>>> Filename : draft-deoliveira-diff-te-preemption-06.txt
>>>> Pages : 19
>>>> Date : 2006-11-28
>>>>
>>>> When the establishment of a higher priority (Traffic Engineering
>>>> Label Switched Path) TE LSP requires the preemption of a set of
>>>> lower
>>>> priority TE LSPs, a node has to make a local decision to select
>>>> which
>>>>
>>>> TE LSPs will be preempted. The preempted LSPs are then
>>>> rerouted by
>>>> their respective Head-end Label Switch Router (LSR). This
>>>> document
>>>> presents a flexible policy that can be used to achieve different
>>>> objectives: preempt the lowest priority LSPs; preempt the minimum
>>>> number of LSPs; preempt the set of TE LSPs that provide the
>>>> closest
>>>> amount of bandwidth to the required bandwidth for the
>>>> preempting TE
>>>> LSPs (to minimize bandwidth wastage); preempt the LSPs that
>>>> will have
>>>> the maximum chance to get rerouted. Simulation results are
>>>> given and
>>>> a comparison among several different policies, with respect to
>>>> preemption cascading, number of preempted LSPs, priority, wasted
>>>> bandwidth and blocking probability is also included.
>>>>
>>>> A URL for this Internet-Draft is:
>>>>
>> http://www.ietf.org/internet-drafts/draft-deoliveira-diff-te-
>> preemption-06.txt
>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>
>
> _______________________________________________
> 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 mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls