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