RE : [Pce] New PCE working group I-Ds

>> PCE_1 advertizing OF_1 attracts all demands in normal
>> conditions while PCE_2 advertizing OF_2 attracts demands
>> after failure/re-routing or other rare event
>>
>> hence, you would then be balancing between both PCEs
>> after failure and when reverting and back again if the
>> failure occur once more (e.g. flapping)
>>
>> i am not saying this will happen but heterogeneity in
>> OF advertized may lead to unbalanced request between
>> PCEs
>
> Which might precisely be a deployment objective.

>then how do you ensure that prevent the oscillation effect ?

The failure example you provide is solved by fixing flapping with a dampening mechanism, this is not a PCE issue by the way...

Would you please provide a practical example where heterogeneity leads to oscillations?

Regards,

JL

De: dimitri papadimitriou
Date: jeu. 16/08/2007 09:17
À: JP Vasseur
Cc: pce@ietf.org
Objet : Re: [Pce] New PCE working group I-Ds

hi

JP Vasseur wrote:
> Hi,
> 
> Chair hat off
> 
> On Aug 15, 2007, at 4:22 PM, PAPADIMITRIOU Dimitri wrote:
> 
>> hi j-l
>>
>>> -----Original Message-----
>>> From: LE ROUX Jean-Louis RD-CORE-LAN
>>> [mailto:jeanlouis.leroux@orange-ftgroup.com]
>>> Sent: Wednesday, August 15, 2007 2:09 PM
>>> To: PAPADIMITRIOU Dimitri; adrian@olddog.co.uk; pce@ietf.org
>>> Subject: RE: [Pce] New PCE working group I-Ds
>>>
>>> Hi Dimitri,
>>>
>>> Thanks for these comments.
>>>
>>> Please see inline,
>>>
>>>
>>>> -----Message d'origine-----
>>>> De : PAPADIMITRIOU Dimitri
>>>> [mailto:Dimitri.Papadimitriou@alcatel-lucent.be]
>>>> Envoyé : mardi 14 août 2007 21:04
>>>> À : zzx-adrian@olddog.co.uk; pce@ietf.org
>>>> Objet : RE: [Pce] New PCE working group I-Ds
>>>>
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Adrian Farrel [mailto:adrian@olddog.co.uk]
>>>>> Sent: Sunday, August 12, 2007 5:32 PM
>>>>> To: pce@ietf.org
>>>>> Subject: [Pce] New PCE working group I-Ds
>>>>>
>>>>> Hi,
>>>>>
>>>>> The meeting in Chicago was broadly in support of adopting
>>>> two I-Ds as
>>>>> working group drafts:
>>>>>
>>>>> - Encoding of Objective Functions in Path Computation
>>> Element (PCE)
>>>>>   communication and discovery protocols
>>>>>   draft-leroux-pce-of-01.txt
>>>>
>>>> ok, three comments though:
>>>>
>>>> - units B-R is from def. speed(bps)-res.capacity(b) -> ?
>>>> please check
>>>
>>> B is in bps and R is in bps.
>>> B-R is the actual bandwidth consumption on the link, in bps.
>>> We will clarify the units in next revision.
>>
>> i thought that capacity/residual bandwidth was expressed in b
>> and you were using the term speed for bps - pls check
>>
>>>> - still unclear to me whether isis pce disc. will or not use a
>>>>   separate inst. (cf. gen-app discussion at isis working group)
>>>
>>> ISIS pce disc relies on procedures defined in 4971.
>>> This is a deployment issue to use same or separate instances.
>>
>> do you assume that you would leave such choice possible ? i
>> was left with the impression after last isis mtg discussion
>> that there is a real incentive for making this a recommended
>> behavior
> 
> Just to avoid confusion: the PCED is being carried within the ISIS
> Router Capability TLV, the processing of which is defined in RFC4971.

indeed, i am not referring to 4971 at such, i am referring to the
fact that if exchanging non-routing info w/ is-is result in recommending 
separated instance then the ISIS PCE disc. w-g doc becomes a prime 
candidate for such recommendation. just a matter of consistency.

>>>> - question about oscillation effects resulting from opposed obj.
>>>>   adv. from diff. pce's
>>>
>>> Would you please clarify and provide an example?
>>
>> PCE_1 advertizing OF_1 attracts all demands in normal
>> conditions while PCE_2 advertizing OF_2 attracts demands
>> after failure/re-routing or other rare event
>>
>> hence, you would then be balancing between both PCEs
>> after failure and when reverting and back again if the
>> failure occur once more (e.g. flapping)
>>
>> i am not saying this will happen but heterogeneity in
>> OF advertized may lead to unbalanced request between
>> PCEs
> 
> Which might precisely be a deployment objective.

then how do you ensure that prevent the oscillation effect ?

thanks,
-d.
> Thanks.
> 
> JP.
> 
>>
>> thanks,
>> -d.
>>
>>> Regards,
>>>
>>> JL
>>>
>>>>
>>>>> - Diff-Serv Aware Class Type Object for Path Computation Element
>>>>>   Communication Protocol draft-sivabalan-pce-dste-01.txt
>>>>
>>>> architectural impact to be clarified before moving forward i
>>>> think that the important disc. point is whether such info
>>>> obtained from TED or via other means
>>>>
>>>> also from <http://www3.ietf.org/proceedings/07mar/minutes/pce.txt>
>>>>
>>>> * 13) Diff-Serv Aware Class Type Object for Path Computation Element
>>>> * Communication Protocol
>>>> * draft-sivabalan-pce-dste-00.txt (Jon Parker - 5mn) [95]
>>>> *
>>>> * Pce does not know class pool.
>>>> * Dimitri: in interprovider context, how do you assure global
>>>> significance?
>>>> * Jon: this is an issue not tackled here.
>>>> * Adrian: how PCE has knowledge class pool ? You would
>>>> suggest to build this knowledge based on IGP
>>>> * flooded information ?
>>>> * JP: please respin the draft tackling issue raised by Dimitri
>>>> * Not many people red the draft
>>>>
>>>> -> draft still does not seem to address that issue.
>>>>
>>>>> Can you please indicate your opinion.
>>>>>
>>>>>
>>>>> Now that the inter-AS requirements work is stable, the
>>>> authors of two
>>>>> I-Ds related to the use of PCE for P2MP path computations
>>>> (Adrian is
>>>>> one of the
>>>>> authors) have asked us to look at adopting this work. We
>>>> think that a
>>>>> little more discussion is needed first, and have asked them
>>>> to present
>>>>> the I-Ds in Vancouver so that we can make a decision immediately
>>>>> afterwards. Please have a look at the I-Ds and send your
>>>> comments to
>>>>> the mailing list.
>>>>>
>>>>> - PCC-PCE Communication Requirements for Point to Multipoint
>>>>>   Multiprotocol Label Switching Traffic Engineering (MPLS-TE)
>>>>>   draft-yasukawa-pce-p2mp-req-02.txt
>>>>>
>>>>> - Applicability of the Path Computation Element (PCE) to
>>>>>    Point-to-Multipoint (P2MP) Multiprotocol Label Switching (MPLS)
>>>>>    and Generalized MPLS (GMPLS) Traffic Engineering (TE)
>>>>>    draft-yasukawa-pce-p2mp-app-00.txt
>>>>>
>>>>> Thanks,
>>>>> JP and Adrian
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Pce mailing list
>>>>> Pce@lists.ietf.org
>>>>> https://www1.ietf.org/mailman/listinfo/pce
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Pce mailing list
>>>> Pce@lists.ietf.org
>>>> https://www1.ietf.org/mailman/listinfo/pce
>>>>
>>>
>>
>>
>> _______________________________________________
>> Pce mailing list
>> Pce@lists.ietf.org
>> https://www1.ietf.org/mailman/listinfo/pce
> 
> 
> _______________________________________________
> Pce mailing list
> Pce@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/pce
> 
> .
> 

_______________________________________________
Pce mailing list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce