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

[JP Vasseur <[e-mail]>]

Hi,

On Aug 16, 2007, at 3:17 AM, dimitri papadimitriou wrote:

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

If the ISIS group leads to the conclusion of using multiple ISIS  
instances
TE related info may be carried within a separate instance, which is  
fine.
As far as the PCED is concerned, the mode of operation is for now
compliant to RFC4971. This may also apply to OSPF at some point
by the way (at least this has been briefly discussed). Anyway, this is
not a PCE related discussion. As far as this ID is concerned, this
won't impact its contents since it is carried within the ISIS Router  
capability.

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

You're mixing two issues: the fact that the PCEs announce different
OF does not by itself lead to oscillation. What you describe above
is an example of different use case in normal and failure scenarios
which is perfectly fine if the PCE has been configured for doing so.

JP.

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


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