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