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:[EMAIL PROTECTED]
Sent: Wednesday, August 15, 2007 2:09 PM
To: PAPADIMITRIOU Dimitri; [EMAIL PROTECTED]; [EMAIL PROTECTED]
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:[EMAIL PROTECTED]
Envoyé : mardi 14 août 2007 21:04
À : [EMAIL PROTECTED]; [EMAIL PROTECTED]
Objet : RE: [Pce] New PCE working group I-Ds



-----Original Message-----
From: Adrian Farrel [mailto:[EMAIL PROTECTED]
Sent: Sunday, August 12, 2007 5:32 PM
To: [EMAIL PROTECTED]
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
[email protected]
https://www1.ietf.org/mailman/listinfo/pce



_______________________________________________
Pce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pce




_______________________________________________
Pce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pce
_______________________________________________
Pce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pce
.


_______________________________________________
Pce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pce

Reply via email to