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

[JP Vasseur <[e-mail]>]

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:[e-mail]]
>> Sent: Wednesday, August 15, 2007 2:09 PM
>> To: PAPADIMITRIOU Dimitri; [e-mail]; [e-mail]
>> 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:[e-mail]]
>>> Envoyé : mardi 14 août 2007 21:04
>>> À : [e-mail]; [e-mail]
>>> Objet : RE: [Pce] New PCE working group I-Ds
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: Adrian Farrel [mailto:[e-mail]]
>>>> Sent: Sunday, August 12, 2007 5:32 PM
>>>> To: [e-mail]
>>>> 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.

>
>>> - 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.

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
>>>> [e-mail]
>>>> https://www1.ietf.org/mailman/listinfo/pce
>>>>
>>>
>>>
>>> _______________________________________________
>>> Pce mailing list
>>> [e-mail]
>>> https://www1.ietf.org/mailman/listinfo/pce
>>>
>>
>
>
> _______________________________________________
> Pce mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/pce


_______________________________________________
Pce mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/pce