From pce-bounces@ietf.org Tue Apr 1 10:14:02 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1EE528C21D; Tue, 1 Apr 2008 10:14:02 -0700 (PDT) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BD8C3A6985 for ; Tue, 1 Apr 2008 10:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id duDVt+1XXF0q for ; Tue, 1 Apr 2008 10:13:59 -0700 (PDT) Received: from hu-out-0506.google.com (hu-out-0506.google.com [72.14.214.227]) by core3.amsl.com (Postfix) with ESMTP id 6D0483A6D78 for ; Tue, 1 Apr 2008 10:13:58 -0700 (PDT) Received: by hu-out-0506.google.com with SMTP id 31so323183huc.14 for ; Tue, 01 Apr 2008 10:13:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=sBF2lBWXzFaNpPXb+zTI146M7YTJ27ZP8rm70RlJxpA=; b=gFhm9CqrsPWqpICJdlcrcLGZJJpBTIXhNvJLyQisKK6l63Zf5y2RhAzKwEYKAxnPyyuU6KhHfHaSQ6EQvz0ICVXrhJyGsZ1BskGs3XH9eN5kDHHFQWJMPkQ2RHqIR6BER+ZbmbGu44PKKat8/y5QJbn6UdlZbY6uq8ogLOp/KZ8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=aC8c/I3NoAkIjdTbos/ae6sDD7nQ72mO6y2LYDu3+iF61r923YxUeZwksdKp7Zpyke/oj/P4uV0FhpkDEe5ZDTSqhG2OKcb/Et24m5HU1Qjkul9EImg/fwiw8NgspN2N9m9CdTyTorZHuH80Wk0HTSUt6QkGYtvFuFo2QklIR6c= Received: by 10.86.71.1 with SMTP id t1mr5565623fga.7.1207070036148; Tue, 01 Apr 2008 10:13:56 -0700 (PDT) Received: by 10.86.87.20 with HTTP; Tue, 1 Apr 2008 10:13:56 -0700 (PDT) Message-ID: <406e32c00804011013l4285e893mee907ca43291f19d@mail.gmail.com> Date: Tue, 1 Apr 2008 13:13:56 -0400 From: "Peng He" To: "Meral Shirazipour" In-Reply-To: <1207063668.47f2547480648@www.imp.polymtl.ca> MIME-Version: 1.0 Content-Disposition: inline References: <023201c89373$818ca760$0300a8c0@your029b8cecfe> <1206999947.47f15b8b3331f@www.imp.polymtl.ca> <406e32c00803311535y718ce934yf0eaa94496a945f4@mail.gmail.com> <1207022210.47f1b28255332@www.imp.polymtl.ca> <406e32c00804010615i27d33ea2nec0e98446841d912@mail.gmail.com> <1207063668.47f2547480648@www.imp.polymtl.ca> Cc: "pce@ietf.org" Subject: Re: [Pce] Remaining BRPC last call comment X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org Interesting discussion, please see inline... On Tue, Apr 1, 2008 at 11:27 AM, Meral Shirazipour wrote: > Hi, > I see your point but please see counterarguments inline... > > > > Please see inline... > > > > On Mon, Mar 31, 2008 at 11:56 PM, Meral Shirazipour > > wrote: > > > Hi, > > > Please see inline... > > > > > > > > > > I agree with Adrian, the domain-sequence should be indicated > > > > explicitly and kept consistency when passing through. > > > > > > Again, I believe this is a plus but not a must. > > > Some PCCs might not even have the capability to come up with such a= domain > > > sequence information. > > > > > > > > > > Well, it is not a must that PCCs know the domain sequence, but I think > > it is a must that somebody (e.g, either PCCs or PCEs) know it clearly > > and follow it during the process of path computation. I strongly > > support '"the series of domains is known a priori" means that it is > > known before path computation starts.', which is actually one of the > > very basic assumption of PCE architecture. Based on this assumption, > > PCE architecture is able to compute optimal inter-domain (area or AS) > > path. It should not be the task for PCEs to decide which (next) domain > > to go freely although sometime it might see the next domain is the > > best from its viewpoint. > > > > Since given a domain sequence, there might be several PCE sequences > > matched (different combinations), it is a one-to-many matching, I > > agree with Adrian that "PCEP needs to be able to indicate the > > sequence of domains that should be traversed". > > If the idea is just to add this functionality into PCEP and enable it to > communicate the complete domain sequence, I approve. Ok. > However I completely disapprove that all path computation should provide= this > information 'apriori'... This would imply that some entity (PCE or other= ) is > capable of coming up with this optimal? domain sequence... This in turn = implies > that this entity has a global view of the network! Yes and maybe. > From my understanding, the > non-existence of such entity was the whole purpose of coming up with the= PCE > architecture which would mainly function in a distributed fashion. > Yes. > By coming up with such a constraint on all path computations (constraint= of > knowing the domain sequence), we will then have to come up with the deta= ils of > such entity, and I am afraid that to be functional this entity will have= to > anyways implement many of the existing functionalities of the existing P= CE > work. > > That's why most PCE drafts didn't talk about this 'entity' and claimed "it is out of the scope of this document" now. > > > > > But I don't understand "each PCE along the path would decide of t= he > > > > "best next domain" to traverse next" , I suppose the domain-seque= nce > > > > is kind of 'global optimality' by all means; then how does a PCE > > > > decide the 'best next domain', how do you define the term 'best'= , and > > > > it might be 'local optimality' in most times as Adrian's example > > > > indicates. > > > Of course the term "best" would be of local significance, if the PCE > > making the > > > decision does not have a global end to end view. > > > > > > > > > > > On the other hand, I think it remains crucial to be able to i= ndicate > > the > > > > > domain(s) to exclude in the sequence of domains (for diversity= or > > > > political > > > > > reasons). > > > > > > > > If the domain-sequence is decided by all means, then it might al= ready > > > > exclude the unwanted domain(s) I guess. > > > > > > Again I don't agree here. Not all PCCs will be able to come up wit= h the > > domain > > > sequence information. However, and mostly for diversity reasons, th= ey will > > know > > > the domains/PCEs they want to avoid. > > > > Similar example could be: they might want to include (not exclude) > > some domains for some reasons. > > Then we could just add to PCEP enough to be able to signal domains to ex= clude > and/or to exclude from the path. That should solve the problem. Yes :) > > > >I believe such domain-level decision > > should be decided by 'something' that is outside of PCE architecture. > > This 'something' provides the domain sequence (might not be optimal), > > Why opt for non optimal when PCEs deciding of the next domain could end = up with > a 'more' optimal path ? > > If you don't have a global view, you can not claim any "more" optimal path just by local computation in general; it might be less optimal from the global view. Currently, the optimality of PCE architecture is based on giving an exact domain sequence passing through. If no such domain sequence given, the optimality of the computation results by PCE architecture can not be guaranteed. Of course it is expected that a globally-distributed optimization process can be deployed in PCE-based architecture, in which no global view maintained, no domain sequence given before each path computation, only limited-and-non-confidential domain-specified info is exchanged among these various distributed sub-process. However, no such process being found yet, even in some theoretical work (e.g., using Nash bargaining and decomposition). > > then PCEs can compute optimal path following this domain sequence. > > PCEs should not have the right/capability to decide which domain(s) to > > go currently. > > By removing this right from PCEs we will somehow partly force the local = path > computation in the PCE's domain. Maybe not a problem... > > > >And it is not a must for PCCs to know this also. > > If it is not the PCC nor the PCE, then another entity has to be describe= d for > this task, and this is just redundant work for no real reason. > PCCs and PCEs should not have the right to decide the domain-level path, at least for now. However, if a global-distributed-optimization process I described above is found, there might be some changes. > Again I agree that it would be 'nice' to add this feature to PCEP, but I > completely disagree that it should be 'mandatory' for all path computati= ons. > Making it mandatory would even go against the global/distributed vision = the PCE > architectures has given to interested parties since it beginnings in 200= 4-2005. There is no any limitation on any research work on this topic. 'mandatory' applied to current practical status I guess. Regards, Peng > > > Regards, > > Peng > > Regards, > Meral > > > > > > > > > > > Regards, > > > > Peng > > > > > > > > > > Regards, > > > Meral > > > > > > > > > > > > > > > > On Mon, Mar 31, 2008 at 5:45 PM, Meral Shirazipour > > > > wrote: > > > > > Hi Adrian, > > > > > I do not disagree with you that it would be a plus to be able= to > > > > 'sometimes' > > > > > indicate the sequence of domains we want the path to go throug= h; > > however I > > > > > understood that in most cases, each PCE along the path would d= ecide > > of the > > > > > "best next domain" to traverse next. > > > > > > > > > > On the other hand, I think it remains crucial to be able to i= ndicate > > the > > > > > domain(s) to exclude in the sequence of domains (for diversity= or > > > > political > > > > > reasons). > > > > > > > > > > Regards, > > > > > Meral > > > > > > > > > > > > > > > > > > > > Selon Adrian Farrel : > > > > > > > > > > > > > > > > > > > > > Hi JP, > > > > > > Thanks for convergence. > > > > > > > > > > > > There is just one remaining issue for discussion. > > > > > > I've reproduced the thread here, but all the discussion is a= t the > > end. > > > > > > > > > > > > Cheers, > > > > > > Adrian > > > > > > > > > > > > >>>> Section 5 > > > > > > >>>> > > > > > > >>>> Is it assumed that PCE(i) knows which domain the reques= ting > > > > > > >>>> PCE(i-1) represents? > > > > > > >>>> The reverse is obviously true because PCE(i-1) must sel= ect > > > > > > >>>> PCE(i) on this basis, but it seems to me that the PCReq= could > > > > > > >>>> useful identify the neighboring (upstream) domain. This= would > > > > > > >>>> be particularly useful in the case of a requesting PCE = that > > > > > > >>>> represents multiple domains since it will allow PCE(i) = to know > > > > > > >>>> which are the BN-en(i) nodes. > > > > > > >>>> > > > > > > >>>> Conversely, if PCE(i) has computation capabilities for > > multiple > > > > > > >>>> domains, it will need to be told which for domain(i) it= should > > act. > > > > > > >>>> So we either need protocol extensions (requesting domai= n, > > > > > > >>>> computation domain) or we need to be told how to use ex= isting > > > > > > >>>> protocol fields for this purpose. > > > > > > >>>> > > > > > > >>>> Furthermore :-( how although the sequence of domains is= known > > > > > > >>>> (a priori) by the PCC, we need some way to convey the s= equence > > > > > > >>>> in the PCReq so that PCE(i) knows that the next domain = in the > > > > > > >>>> sequence is domain(i+1). > > > > > > >>>> If this can be achieved by existing protocol mechanism,= you > > need > > > > > > >>>> to describe the procedures. If it can't be done, we need > > protocol > > > > > > >>>> extensions. > > > > > > >>> > > > > > > >>> We make the assumption that the sequence of domains is p= re- > > > > > > >>> determined or discovered by some means that is outside o= f the > > > > > > >>> scope of this document. > > > > > > >>> You're right that we do not say that the sequence of PCE= is > > also > > > > > > >>> predetermined or discovery by some means. Do you want us= to > > > > > > >>> explicitly add this assumption? > > > > > > >>> > > > > > > >>> Consider the two following cases: > > > > > > >>> 1) Inter-area: obvious > > > > > > >>> 2) Inter-AS: if the sequences of domain and related PCEs= are > > known, > > > > > > >>> there is no need for protocol extensions except if we wa= nt to > > > > enforce > > > > > > >>> the sequence of PCEs, which can be done thanks to the PC= E-ID > > > > > > >>> object defined in > > > > > > >>> > > http://www.ietf.org/internet-drafts/draft-ietf-pce-monitoring-01.txt > > > > > > >>> We could include the PCE-ID object definition in BRPC an= d add > > > > > > >>> some text here. > > > > > > >>> Thoughts? > > > > > > >> > > > > > > >> Well, I have no problems with "the sequence of domains is= known > > a > > > > > > >> priori." In fact, I strongly support it. > > > > > > >> > > > > > > >> However, to whom is this sequence known? > > > > > > >> > > > > > > >> Yes, if the ingress PCC or PCE knows the PCEs responsible= for > > each > > > > > > >> domain, then it could provide a list of such PCEs. But th= is is > > more > > > > > > >> information than is implied in "the sequence of domains".= My > > > > assumption > > > > > > >> is that the default position is that PCE(i) will select > > PCE(i+1). > > > > > > > > > > > > > > This is what we referred to as =B3discovered by some means= =B2 indeed. > > > > > > > > > > > > > >> But how does PCE(i) know that the next domain is domain(i= +1)? > > How > > > > > > >> is the a priori knowledge passed to PCE(i)? > > > > > > > > > > > > > > By some means out of the scope of the document. > > > > > > > Example: inter-area + PCE on the ABR + PCE discovery > > > > > > > (RFC 5088/5089). > > > > > > > There are other mechanisms available but out of the scope = of this > > > > > > > document. > > > > > > > > > > > > > >> This is important, because knowing the sequence of PCEs i= s not > > enough > > > > > > >> to know the sequence of domains. A PCE may serve more tha= n one > > > > > > >> domain. > > > > > > > > > > > > OK > > > > > > The difference in our view point is, I think, what we mean b= y "the > > > > series of > > > > > > domains is known a priori." Let's use ASes as the example, b= ecause > > it is > > > > > > slightly more complex. > > > > > > Here comes some ASCII Art (TM) > > > > > > > > > > > > > > > > > > --------- > > > > > > | AS-B | > > > > > > --------- | | --------- > > > > > > | AS-A |----| |----| AS-D | > > > > > > | | | | | | > > > > > > | PCC |----| |----| Egress | > > > > > > | | --------- | | > > > > > > | | | | | | > > > > > > | | --------- | | > > > > > > | |----| AS-C |----| | > > > > > > | | | | | | > > > > > > | |----| |----| | > > > > > > --------- | | --------- > > > > > > | | > > > > > > --------- > > > > > > > > > > > > Here we have 4 ASes and we want to get from the PCC to the E= gress. > > > > > > The ASes are interconnected as shown. > > > > > > Let's assume that there are five PCEs. PCE-A, PCE-B, PCE-C a= nd > > PCE-D > > > > have > > > > > > obvious scope. > > > > > > PCE-E is special, it is capable of computing paths in AS-B a= nd > > AS-C. > > > > > > > > > > > > So, in my book, "the series of domains is known a priori" me= ans > > that it > > > > is > > > > > > known before path computation starts. That means, either the= PCC > > knows > > > > the > > > > > > series of ASes (say, ABD) or the sequence is known by PCE-A. > > > > > > > > > > > > In the former case, we need a way for the PCC to pass that > > information > > > > to > > > > > > PCE-A. Note that this is not a sequence of PCEs. It is a seq= uence > > of > > > > > > domains. > > > > > > > > > > > > Let's suppose that PCE-A now knows the series of domains, AB= D. Let > > us > > > > assume > > > > > > that it selects PCE-B as the next PCE in the series. How doe= s it > > > > communicate > > > > > > to PCE-B that the series of domains is ABD and not ABCD? One > > possible > > > > way to > > > > > > do this, would be to signal the series of PCEs (PCE-A, PCE-B, > > PCE-D). > > > > But > > > > > > that has some implication of a one-to-one relationship betwe= en PCEs > > and > > > > > > domains. > > > > > > > > > > > > So suppose PCE-A selects PCE-E as the next PCE in the series= . How > > does > > > > PCE-E > > > > > > know the pre-determined series of domains? How does it know = that it > > has > > > > been > > > > > > asked to find a path across AS-B and not AS-C? Do we suppose= that > > this a > > > > > > priori knowledge permeates the ether? Or is it passed along = with > > the > > > > > > request? Note that the sequence of PCEs PCE-A, PCE-E, PCE-D = does > > not > > > > help > > > > > > because we could still select a path through domains ABCD. > > > > > > > > > > > > So, I think that PCEP needs to be able to indicate the seque= nce of > > > > domains > > > > > > that should be traversed. The additional ability to indicate= the > > > > sequence of > > > > > > PCEs is a great supplement. > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Pce mailing list > > > > > > Pce@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/pce > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Pce mailing list > > > > > Pce@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/pce > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Tue Apr 1 12:00:56 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B67128C566; Tue, 1 Apr 2008 12:00:56 -0700 (PDT) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 852C43A6EEC for ; Tue, 1 Apr 2008 12:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mWaFCBEk3-8S for ; Tue, 1 Apr 2008 12:00:53 -0700 (PDT) Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by core3.amsl.com (Postfix) with ESMTP id 2148828C566 for ; Tue, 1 Apr 2008 12:00:06 -0700 (PDT) Received: from localhost (imp-4-1.polymtl.ca [132.207.4.76]) by smtp.polymtl.ca (8.13.8/8.13.8) with ESMTP id m31J01E5018899; Tue, 1 Apr 2008 15:00:02 -0400 Received: from bas1-sthubert21-1279581895.dsl.bell.ca (bas1-sthubert21-1279581895.dsl.bell.ca [76.68.222.199]) by www.imp.polymtl.ca (IMP) with HTTP for ; Tue, 01 Apr 2008 15:00:00 -0400 Message-ID: <1207076400.47f286309d834@www.imp.polymtl.ca> Date: Tue, 01 Apr 2008 15:00:00 -0400 From: Meral Shirazipour To: Peng He References: <023201c89373$818ca760$0300a8c0@your029b8cecfe> <1206999947.47f15b8b3331f@www.imp.polymtl.ca> <406e32c00803311535y718ce934yf0eaa94496a945f4@mail.gmail.com> <1207022210.47f1b28255332@www.imp.polymtl.ca> <406e32c00804010615i27d33ea2nec0e98446841d912@mail.gmail.com> <1207063668.47f2547480648@www.imp.polymtl.ca> <406e32c00804011013l4285e893mee907ca43291f19d@mail.gmail.com> In-Reply-To: <406e32c00804011013l4285e893mee907ca43291f19d@mail.gmail.com> MIME-Version: 1.0 User-Agent: Internet Messaging Program (IMP) 3.2.3 X-Originating-IP: 76.68.222.199 X-Poly-FromMTA: (imp-4-1.polymtl.ca [132.207.4.76]) at Tue, 1 Apr 2008 19:00:01 +0000 Cc: "pce@ietf.org" Subject: Re: [Pce] Remaining BRPC last call comment X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org Hi, Very interesting indeed=85 If I sum up all this, you are saying that we s= hould make =91mandatory=92 that the initiating domain specifies the complete doma= in sequence. I am arguing that this should be possible but not =91mandatory=92. My arguments among others are for instance: 1- Not all initiating domains can come up with this information 2- Some initiating domains might actually want to rely on the PCE architect= ure to choose the best sequence of domains (by maybe just including the info on domains to include/exclude) 3- Having the PCE=92s choose the next domain could end up being the optimal solution or at least the best possible solution as each domain/PCE has more information on its neighboring domains than the entity in the initialing do= main would have on the entire PCE/domains in the sequence. And if we argue that such entity would have a global view of the domains and could indeed come up with an optimal sequence, then why not have this entity calculate the whole path and forget about the PCE architecture! Since such entity cannot exist (according to the whole discussions resultin= g in the PCE architecture), I do not see why we should force such practice if ha= ving the PCEs choose the next domain in sequence does not necessarily give any w= orse performance. As for all drafts considering the topic of finding the PCE sequence as out = of scope, I do not believe that they were insinuating that a separate 'entity' would do this job. I actually see this as they are leaving this decision for a maybe later deployment issue, where one could decide to a- rely on PCEs in the PCE architecture to choose the next domain <> b- rely on an external entity (or any other means) to come up with the comp= lete or partial domain sequence to be signaled with the path computation. That being said, again I agree that the PCEP should be able to carry domain information in different forms: e.g. 1-the complete domain/PCE sequence = 2-domains to include 3-domains to exclude. Regards, Meral Selon Peng He : > Interesting discussion, please see inline... > > On Tue, Apr 1, 2008 at 11:27 AM, Meral Shirazipour > wrote: > > Hi, > > I see your point but please see counterarguments inline... > > > > > > > Please see inline... > > > > > > On Mon, Mar 31, 2008 at 11:56 PM, Meral Shirazipour > > > wrote: > > > > Hi, > > > > Please see inline... > > > > > > > > > > > > > I agree with Adrian, the domain-sequence should be indicated > > > > > explicitly and kept consistency when passing through. > > > > > > > > Again, I believe this is a plus but not a must. > > > > Some PCCs might not even have the capability to come up with such= a > domain > > > > sequence information. > > > > > > > > > > > > > > Well, it is not a must that PCCs know the domain sequence, but I thi= nk > > > it is a must that somebody (e.g, either PCCs or PCEs) know it clearly > > > and follow it during the process of path computation. I strongly > > > support '"the series of domains is known a priori" means that it is > > > known before path computation starts.', which is actually one of the > > > very basic assumption of PCE architecture. Based on this assumption, > > > PCE architecture is able to compute optimal inter-domain (area or AS) > > > path. It should not be the task for PCEs to decide which (next) doma= in > > > to go freely although sometime it might see the next domain is the > > > best from its viewpoint. > > > > > > Since given a domain sequence, there might be several PCE sequences > > > matched (different combinations), it is a one-to-many matching, I > > > agree with Adrian that "PCEP needs to be able to indicate the > > > sequence of domains that should be traversed". > > > > If the idea is just to add this functionality into PCEP and enable it = to > > communicate the complete domain sequence, I approve. > > Ok. > > > However I completely disapprove that all path computation should provi= de > this > > information 'apriori'... This would imply that some entity (PCE or oth= er) > is > > capable of coming up with this optimal? domain sequence... This in turn > implies > > that this entity has a global view of the network! > > Yes and maybe. > > > From my understanding, the > > non-existence of such entity was the whole purpose of coming up with t= he > PCE > > architecture which would mainly function in a distributed fashion. > > > > Yes. > > > By coming up with such a constraint on all path computations (constrai= nt > of > > knowing the domain sequence), we will then have to come up with the > details of > > such entity, and I am afraid that to be functional this entity will ha= ve > to > > anyways implement many of the existing functionalities of the existing= PCE > > work. > > > > > > That's why most PCE drafts didn't talk about this 'entity' and claimed > "it is out of the scope of this document" now. > > > > > > > > But I don't understand "each PCE along the path would decide of= the > > > > > "best next domain" to traverse next" , I suppose the > domain-sequence > > > > > is kind of 'global optimality' by all means; then how does a PCE > > > > > decide the 'best next domain', how do you define the term 'bes= t', > and > > > > > it might be 'local optimality' in most times as Adrian's example > > > > > indicates. > > > > Of course the term "best" would be of local significance, if the = PCE > > > making the > > > > decision does not have a global end to end view. > > > > > > > > > > > > > > On the other hand, I think it remains crucial to be able to > indicate > > > the > > > > > > domain(s) to exclude in the sequence of domains (for diversi= ty > or > > > > > political > > > > > > reasons). > > > > > > > > > > If the domain-sequence is decided by all means, then it might > already > > > > > exclude the unwanted domain(s) I guess. > > > > > > > > Again I don't agree here. Not all PCCs will be able to come up w= ith > the > > > domain > > > > sequence information. However, and mostly for diversity reasons, = they > will > > > know > > > > the domains/PCEs they want to avoid. > > > > > > Similar example could be: they might want to include (not exclude) > > > some domains for some reasons. > > > > Then we could just add to PCEP enough to be able to signal domains to > exclude > > and/or to exclude from the path. That should solve the problem. > > Yes :) > > > > > > > >I believe such domain-level decision > > > should be decided by 'something' that is outside of PCE architecture. > > > This 'something' provides the domain sequence (might not be optimal), > > > > Why opt for non optimal when PCEs deciding of the next domain could en= d up > with > > a 'more' optimal path ? > > > > > > If you don't have a global view, you can not claim any "more" optimal > path just by local computation in general; it might be less optimal > from the global view. > > Currently, the optimality of PCE architecture is based on giving an > exact domain sequence passing through. If no such domain sequence > given, the optimality of the computation results by PCE architecture > can not be guaranteed. > > Of course it is expected that a globally-distributed optimization > process can be deployed in PCE-based architecture, in which no global > view maintained, no domain sequence given before each path > computation, only limited-and-non-confidential domain-specified info > is exchanged among these various distributed sub-process. However, no > such process being found yet, even in some theoretical work (e.g., > using Nash bargaining and decomposition). > > > > > then PCEs can compute optimal path following this domain sequence. > > > PCEs should not have the right/capability to decide which domain(s) = to > > > go currently. > > > > By removing this right from PCEs we will somehow partly force the local > path > > computation in the PCE's domain. Maybe not a problem... > > > > > > >And it is not a must for PCCs to know this also. > > > > If it is not the PCC nor the PCE, then another entity has to be descri= bed > for > > this task, and this is just redundant work for no real reason. > > > > PCCs and PCEs should not have the right to decide the domain-level > path, at least for now. However, if a global-distributed-optimization > process I described above is found, there might be some changes. > > > Again I agree that it would be 'nice' to add this feature to PCEP, but= I > > completely disagree that it should be 'mandatory' for all path > computations. > > Making it mandatory would even go against the global/distributed vision > the PCE > > architectures has given to interested parties since it beginnings in > 2004-2005. > > > There is no any limitation on any research work on this topic. > 'mandatory' applied to current practical status I guess. > > > Regards, > Peng > > > > > > Regards, > > > Peng > > > > Regards, > > Meral > > > > > > > > > > > > > > > > > Regards, > > > > > Peng > > > > > > > > > > > > > Regards, > > > > Meral > > > > > > > > > > > > > > > > > > > > > On Mon, Mar 31, 2008 at 5:45 PM, Meral Shirazipour > > > > > wrote: > > > > > > Hi Adrian, > > > > > > I do not disagree with you that it would be a plus to be ab= le > to > > > > > 'sometimes' > > > > > > indicate the sequence of domains we want the path to go thro= ugh; > > > however I > > > > > > understood that in most cases, each PCE along the path would > decide > > > of the > > > > > > "best next domain" to traverse next. > > > > > > > > > > > > On the other hand, I think it remains crucial to be able to > indicate > > > the > > > > > > domain(s) to exclude in the sequence of domains (for diversi= ty > or > > > > > political > > > > > > reasons). > > > > > > > > > > > > Regards, > > > > > > Meral > > > > > > > > > > > > > > > > > > > > > > > > Selon Adrian Farrel : > > > > > > > > > > > > > > > > > > > > > > > > > Hi JP, > > > > > > > Thanks for convergence. > > > > > > > > > > > > > > There is just one remaining issue for discussion. > > > > > > > I've reproduced the thread here, but all the discussion is= at > the > > > end. > > > > > > > > > > > > > > Cheers, > > > > > > > Adrian > > > > > > > > > > > > > > >>>> Section 5 > > > > > > > >>>> > > > > > > > >>>> Is it assumed that PCE(i) knows which domain the > requesting > > > > > > > >>>> PCE(i-1) represents? > > > > > > > >>>> The reverse is obviously true because PCE(i-1) must > select > > > > > > > >>>> PCE(i) on this basis, but it seems to me that the PCR= eq > could > > > > > > > >>>> useful identify the neighboring (upstream) domain. Th= is > would > > > > > > > >>>> be particularly useful in the case of a requesting PCE > that > > > > > > > >>>> represents multiple domains since it will allow PCE(i= ) to > know > > > > > > > >>>> which are the BN-en(i) nodes. > > > > > > > >>>> > > > > > > > >>>> Conversely, if PCE(i) has computation capabilities for > > > multiple > > > > > > > >>>> domains, it will need to be told which for domain(i) = it > should > > > act. > > > > > > > >>>> So we either need protocol extensions (requesting dom= ain, > > > > > > > >>>> computation domain) or we need to be told how to use > existing > > > > > > > >>>> protocol fields for this purpose. > > > > > > > >>>> > > > > > > > >>>> Furthermore :-( how although the sequence of domains = is > known > > > > > > > >>>> (a priori) by the PCC, we need some way to convey the > sequence > > > > > > > >>>> in the PCReq so that PCE(i) knows that the next domai= n in > the > > > > > > > >>>> sequence is domain(i+1). > > > > > > > >>>> If this can be achieved by existing protocol mechanis= m, > you > > > need > > > > > > > >>>> to describe the procedures. If it can't be done, we n= eed > > > protocol > > > > > > > >>>> extensions. > > > > > > > >>> > > > > > > > >>> We make the assumption that the sequence of domains is > pre- > > > > > > > >>> determined or discovered by some means that is outside= of > the > > > > > > > >>> scope of this document. > > > > > > > >>> You're right that we do not say that the sequence of P= CE > is > > > also > > > > > > > >>> predetermined or discovery by some means. Do you want = us > to > > > > > > > >>> explicitly add this assumption? > > > > > > > >>> > > > > > > > >>> Consider the two following cases: > > > > > > > >>> 1) Inter-area: obvious > > > > > > > >>> 2) Inter-AS: if the sequences of domain and related PC= Es > are > > > known, > > > > > > > >>> there is no need for protocol extensions except if we = want > to > > > > > enforce > > > > > > > >>> the sequence of PCEs, which can be done thanks to the > PCE-ID > > > > > > > >>> object defined in > > > > > > > >>> > > > http://www.ietf.org/internet-drafts/draft-ietf-pce-monitoring-01.txt > > > > > > > >>> We could include the PCE-ID object definition in BRPC = and > add > > > > > > > >>> some text here. > > > > > > > >>> Thoughts? > > > > > > > >> > > > > > > > >> Well, I have no problems with "the sequence of domains = is > known > > > a > > > > > > > >> priori." In fact, I strongly support it. > > > > > > > >> > > > > > > > >> However, to whom is this sequence known? > > > > > > > >> > > > > > > > >> Yes, if the ingress PCC or PCE knows the PCEs responsib= le > for > > > each > > > > > > > >> domain, then it could provide a list of such PCEs. But = this > is > > > more > > > > > > > >> information than is implied in "the sequence of domains= ". > My > > > > > assumption > > > > > > > >> is that the default position is that PCE(i) will select > > > PCE(i+1). > > > > > > > > > > > > > > > > This is what we referred to as =B3discovered by some mea= ns=B2 > indeed. > > > > > > > > > > > > > > > >> But how does PCE(i) know that the next domain is > domain(i+1)? > > > How > > > > > > > >> is the a priori knowledge passed to PCE(i)? > > > > > > > > > > > > > > > > By some means out of the scope of the document. > > > > > > > > Example: inter-area + PCE on the ABR + PCE discovery > > > > > > > > (RFC 5088/5089). > > > > > > > > There are other mechanisms available but out of the scop= e of > this > > > > > > > > document. > > > > > > > > > > > > > > > >> This is important, because knowing the sequence of PCEs= is > not > > > enough > > > > > > > >> to know the sequence of domains. A PCE may serve more t= han > one > > > > > > > >> domain. > > > > > > > > > > > > > > OK > > > > > > > The difference in our view point is, I think, what we mean= by > "the > > > > > series of > > > > > > > domains is known a priori." Let's use ASes as the example, > because > > > it is > > > > > > > slightly more complex. > > > > > > > Here comes some ASCII Art (TM) > > > > > > > > > > > > > > > > > > > > > --------- > > > > > > > | AS-B | > > > > > > > --------- | | --------- > > > > > > > | AS-A |----| |----| AS-D | > > > > > > > | | | | | | > > > > > > > | PCC |----| |----| Egress | > > > > > > > | | --------- | | > > > > > > > | | | | | | > > > > > > > | | --------- | | > > > > > > > | |----| AS-C |----| | > > > > > > > | | | | | | > > > > > > > | |----| |----| | > > > > > > > --------- | | --------- > > > > > > > | | > > > > > > > --------- > > > > > > > > > > > > > > Here we have 4 ASes and we want to get from the PCC to the > Egress. > > > > > > > The ASes are interconnected as shown. > > > > > > > Let's assume that there are five PCEs. PCE-A, PCE-B, PCE-C= and > > > PCE-D > > > > > have > > > > > > > obvious scope. > > > > > > > PCE-E is special, it is capable of computing paths in AS-B= and > > > AS-C. > > > > > > > > > > > > > > So, in my book, "the series of domains is known a priori" > means > > > that it > > > > > is > > > > > > > known before path computation starts. That means, either t= he > PCC > > > knows > > > > > the > > > > > > > series of ASes (say, ABD) or the sequence is known by PCE-= A. > > > > > > > > > > > > > > In the former case, we need a way for the PCC to pass that > > > information > > > > > to > > > > > > > PCE-A. Note that this is not a sequence of PCEs. It is a > sequence > > > of > > > > > > > domains. > > > > > > > > > > > > > > Let's suppose that PCE-A now knows the series of domains, = ABD. > Let > > > us > > > > > assume > > > > > > > that it selects PCE-B as the next PCE in the series. How d= oes > it > > > > > communicate > > > > > > > to PCE-B that the series of domains is ABD and not ABCD? O= ne > > > possible > > > > > way to > > > > > > > do this, would be to signal the series of PCEs (PCE-A, PCE= -B, > > > PCE-D). > > > > > But > > > > > > > that has some implication of a one-to-one relationship bet= ween > PCEs > > > and > > > > > > > domains. > > > > > > > > > > > > > > So suppose PCE-A selects PCE-E as the next PCE in the seri= es. > How > > > does > > > > > PCE-E > > > > > > > know the pre-determined series of domains? How does it know > that it > > > has > > > > > been > > > > > > > asked to find a path across AS-B and not AS-C? Do we suppo= se > that > > > this a > > > > > > > priori knowledge permeates the ether? Or is it passed along > with > > > the > > > > > > > request? Note that the sequence of PCEs PCE-A, PCE-E, PCE-D > does > > > not > > > > > help > > > > > > > because we could still select a path through domains ABCD. > > > > > > > > > > > > > > So, I think that PCEP needs to be able to indicate the > sequence of > > > > > domains > > > > > > > that should be traversed. The additional ability to indica= te > the > > > > > sequence of > > > > > > > PCEs is a great supplement. > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Pce mailing list > > > > > > > Pce@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/pce > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Pce mailing list > > > > > > Pce@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/pce > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Tue Apr 1 13:12:40 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BEE828C2DB; Tue, 1 Apr 2008 13:12:40 -0700 (PDT) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8E9A28C2F8 for ; Tue, 1 Apr 2008 13:12:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.181 X-Spam-Level: X-Spam-Status: No, score=-4.181 tagged_above=-999 required=5 tests=[AWL=2.418, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5MaJXndDVfg for ; Tue, 1 Apr 2008 13:12:38 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id F266728C169 for ; Tue, 1 Apr 2008 13:12:37 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 01 Apr 2008 13:12:37 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m31KCbOV016014; Tue, 1 Apr 2008 13:12:37 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m31KCKMn012025; Tue, 1 Apr 2008 20:12:36 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Apr 2008 16:12:36 -0400 Received: from 10.86.104.186 ([10.86.104.186]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Tue, 1 Apr 2008 20:12:35 +0000 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Tue, 01 Apr 2008 16:12:34 -0400 From: JP Vasseur To: Adrian Farrel , Message-ID: Thread-Topic: Remaining BRPC last call comment Thread-Index: AciUNLjR9xzdHAAnEd2yPgANk8WjQA== In-Reply-To: <023201c89373$818ca760$0300a8c0@your029b8cecfe> Mime-version: 1.0 X-OriginalArrivalTime: 01 Apr 2008 20:12:36.0510 (UTC) FILETIME=[BA5063E0:01C89434] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=548; t=1207080757; x=1207944757; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20Remaining=20BRPC=20last=20call=20commen t |Sender:=20; bh=ATngTXIKSlMxvNHt86tWgJ3SwFBS2tlKotoi5ozq50I=; b=SGwin3ZknCjlSQL3B+ld1/adCL5QM4QFtag2T1xZC7+Z3hvKH4mlpugFaX oQifgZguuNa5rE2ICYnjb3aB8GRKjOCQkyf06AeKZYXDPoU2+Q+AkLKsqt6c id8pVKIpBATLYL9MIxIoho1RVYqsiYP7CVBEsK9+NMXeUZwO0XTMU=; Authentication-Results: sj-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [Pce] Remaining BRPC last call comment X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org Hi Adrian, [snip] > > So, I think that PCEP needs to be able to indicate the sequence of domains > that should be traversed. The easy way to handle this is by using the IRO object specified in PCEP. I can add: "The sequence of domains to be traversed MAY be encoded in the IRO so that it is available to all PCEs." The additional ability to indicate the sequence of > PCEs is a great supplement. Which can be done thanks to the PCE-ID object defined in draft-ietf-pce-monitoring. Thanks. Cheers. JP. > > _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Tue Apr 1 13:23:39 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BFC83A6A14; Tue, 1 Apr 2008 13:23:39 -0700 (PDT) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F25503A6DF8 for ; Tue, 1 Apr 2008 13:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.554 X-Spam-Level: X-Spam-Status: No, score=-3.554 tagged_above=-999 required=5 tests=[AWL=1.649, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hp3zPwx8Qp5b for ; Tue, 1 Apr 2008 13:23:27 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 1543B28C588 for ; Tue, 1 Apr 2008 13:21:16 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 01 Apr 2008 13:21:15 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m31KLFb1009920; Tue, 1 Apr 2008 13:21:15 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m31KL817026719; Tue, 1 Apr 2008 20:21:15 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Apr 2008 16:21:13 -0400 Received: from 10.86.104.186 ([10.86.104.186]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Tue, 1 Apr 2008 20:21:12 +0000 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Tue, 01 Apr 2008 16:21:08 -0400 From: JP Vasseur To: Meral Shirazipour , Peng He Message-ID: Thread-Topic: [Pce] Remaining BRPC last call comment Thread-Index: AciUNesvKXoOeAApEd2yPgANk8WjQA== In-Reply-To: <1207063668.47f2547480648@www.imp.polymtl.ca> Mime-version: 1.0 X-OriginalArrivalTime: 01 Apr 2008 20:21:13.0132 (UTC) FILETIME=[EE3EA6C0:01C89435] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=14033; t=1207081275; x=1207945275; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Pce]=20Remaining=20BRPC=20last=20call= 20comment |Sender:=20; bh=qkdXHjLRz00NdLYil1YLrjhd9KsdgPbuK+fseHob8vE=; b=yQHR5+eF8qy6I6xk6xJYDGfdozmVeGsgKM3XdUsObxyr3FBmcgZyzbzOum OVOSuW5uJLGHXD1irnBIDbX/e6e9927JG5V+a90f9i4p0kj3l/bzUAlV0sE/ AxON1DhxW/; Authentication-Results: sj-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: "pce@ietf.org" Subject: Re: [Pce] Remaining BRPC last call comment X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org Hi, > From: Meral Shirazipour > Date: Tue, 01 Apr 2008 11:27:48 -0400 > To: Peng He > Cc: "pce@ietf.org" > Subject: Re: [Pce] Remaining BRPC last call comment > = > Hi, > I see your point but please see counterarguments inline... > = >> Please see inline... >> = >> On Mon, Mar 31, 2008 at 11:56 PM, Meral Shirazipour >> wrote: >>> Hi, >>> Please see inline... >>> = >>> = >>>> I agree with Adrian, the domain-sequence should be indicated >>>> explicitly and kept consistency when passing through. >>> = >>> Again, I believe this is a plus but not a must. >>> Some PCCs might not even have the capability to come up with such a do= main >>> sequence information. >>> = >>> = >> = >> Well, it is not a must that PCCs know the domain sequence, but I think >> it is a must that somebody (e.g, either PCCs or PCEs) know it clearly >> and follow it during the process of path computation. I strongly >> support '"the series of domains is known a priori" means that it is >> known before path computation starts.', which is actually one of the >> very basic assumption of PCE architecture. Based on this assumption, >> PCE architecture is able to compute optimal inter-domain (area or AS) >> path. It should not be the task for PCEs to decide which (next) domain >> to go freely although sometime it might see the next domain is the >> best from its viewpoint. >> = >> Since given a domain sequence, there might be several PCE sequences >> matched (different combinations), it is a one-to-many matching, I >> agree with Adrian that "PCEP needs to be able to indicate the >> sequence of domains that should be traversed". > = > If the idea is just to add this functionality into PCEP and enable it to > communicate the complete domain sequence, I approve. > However I completely disapprove that all path computation should provide = this > information 'apriori'... This would imply that some entity (PCE or other)= is > capable of coming up with this optimal? domain sequence... This in turn > implies > that this entity has a global view of the network! From my understanding,= the > non-existence of such entity was the whole purpose of coming up with the = PCE > architecture which would mainly function in a distributed fashion. > = Absolutely. > By coming up with such a constraint on all path computations (constraint = of > knowing the domain sequence), we will then have to come up with the detai= ls of > such entity, and I am afraid that to be functional this entity will have = to > anyways implement many of the existing functionalities of the existing PCE > work. > = > = >>>> But I don't understand "each PCE along the path would decide of the >>>> "best next domain" to traverse next" , I suppose the domain-sequence >>>> is kind of 'global optimality' by all means; then how does a PCE >>>> decide the 'best next domain', how do you define the term 'best', and >>>> it might be 'local optimality' in most times as Adrian's example >>>> indicates. >>> Of course the term "best" would be of local significance, if the PCE >> making the >>> decision does not have a global end to end view. >>> = >>> = >>>>> On the other hand, I think it remains crucial to be able to indicate >> the >>>>> domain(s) to exclude in the sequence of domains (for diversity or >>>> political >>>>> reasons). >>>> = >>>> If the domain-sequence is decided by all means, then it might already >>>> exclude the unwanted domain(s) I guess. >>> = >>> Again I don't agree here. Not all PCCs will be able to come up with t= he >> domain >>> sequence information. However, and mostly for diversity reasons, they = will >> know >>> the domains/PCEs they want to avoid. >> = >> Similar example could be: they might want to include (not exclude) >> some domains for some reasons. > = > Then we could just add to PCEP enough to be able to signal domains to exc= lude > and/or to exclude from the path. That should solve the problem. See my reply ... The ability to include some domains is already in PCEP. And the ability to exclude domain is in http://www.ietf.org/internet-drafts/draft-ietf-pce-pcep-xro-05.txt > = >> I believe such domain-level decision >> should be decided by 'something' that is outside of PCE architecture. >> This 'something' provides the domain sequence (might not be optimal), > = > Why opt for non optimal when PCEs deciding of the next domain could end up > with > a 'more' optimal path ? > = >> then PCEs can compute optimal path following this domain sequence. >> PCEs should not have the right/capability to decide which domain(s) to >> go currently. > = > By removing this right from PCEs we will somehow partly force the local p= ath > computation in the PCE's domain. Maybe not a problem... > = >> And it is not a must for PCCs to know this also. > = > If it is not the PCC nor the PCE, then another entity has to be described= for > this task, and this is just redundant work for no real reason. > = > Again I agree that it would be 'nice' to add this feature to PCEP, but I > completely disagree that it should be 'mandatory' for all path computatio= ns. For sure and this is what BRPC says already. > Making it mandatory would even go against the global/distributed vision t= he > PCE > architectures has given to interested parties since it beginnings in > 2004-2005. Thanks. JP. > = >> Regards, >> Peng > = > Regards, > Meral > = > = >>> = >>>> Regards, >>>> Peng >>>> = >>> = >>> Regards, >>> Meral >>> = >>> = >>> = >>> = >>>> On Mon, Mar 31, 2008 at 5:45 PM, Meral Shirazipour >>>> wrote: >>>>> Hi Adrian, >>>>> I do not disagree with you that it would be a plus to be able to >>>> 'sometimes' >>>>> indicate the sequence of domains we want the path to go through; >> however I >>>>> understood that in most cases, each PCE along the path would decide >> of the >>>>> "best next domain" to traverse next. >>>>> = >>>>> On the other hand, I think it remains crucial to be able to indicate >> the >>>>> domain(s) to exclude in the sequence of domains (for diversity or >>>> political >>>>> reasons). >>>>> = >>>>> Regards, >>>>> Meral >>>>> = >>>>> = >>>>> = >>>>> Selon Adrian Farrel : >>>>> = >>>>> = >>>>> = >>>>>> Hi JP, >>>>>> Thanks for convergence. >>>>>> = >>>>>> There is just one remaining issue for discussion. >>>>>> I've reproduced the thread here, but all the discussion is at the >> end. >>>>>> = >>>>>> Cheers, >>>>>> Adrian >>>>>> = >>>>>>>>>> Section 5 >>>>>>>>>> = >>>>>>>>>> Is it assumed that PCE(i) knows which domain the requesting >>>>>>>>>> PCE(i-1) represents? >>>>>>>>>> The reverse is obviously true because PCE(i-1) must select >>>>>>>>>> PCE(i) on this basis, but it seems to me that the PCReq could >>>>>>>>>> useful identify the neighboring (upstream) domain. This would >>>>>>>>>> be particularly useful in the case of a requesting PCE that >>>>>>>>>> represents multiple domains since it will allow PCE(i) to know >>>>>>>>>> which are the BN-en(i) nodes. >>>>>>>>>> = >>>>>>>>>> Conversely, if PCE(i) has computation capabilities for >> multiple >>>>>>>>>> domains, it will need to be told which for domain(i) it should >> act. >>>>>>>>>> So we either need protocol extensions (requesting domain, >>>>>>>>>> computation domain) or we need to be told how to use existing >>>>>>>>>> protocol fields for this purpose. >>>>>>>>>> = >>>>>>>>>> Furthermore :-( how although the sequence of domains is known >>>>>>>>>> (a priori) by the PCC, we need some way to convey the sequence >>>>>>>>>> in the PCReq so that PCE(i) knows that the next domain in the >>>>>>>>>> sequence is domain(i+1). >>>>>>>>>> If this can be achieved by existing protocol mechanism, you >> need >>>>>>>>>> to describe the procedures. If it can't be done, we need >> protocol >>>>>>>>>> extensions. >>>>>>>>> = >>>>>>>>> We make the assumption that the sequence of domains is pre- >>>>>>>>> determined or discovered by some means that is outside of the >>>>>>>>> scope of this document. >>>>>>>>> You're right that we do not say that the sequence of PCE is >> also >>>>>>>>> predetermined or discovery by some means. Do you want us to >>>>>>>>> explicitly add this assumption? >>>>>>>>> = >>>>>>>>> Consider the two following cases: >>>>>>>>> 1) Inter-area: obvious >>>>>>>>> 2) Inter-AS: if the sequences of domain and related PCEs are >> known, >>>>>>>>> there is no need for protocol extensions except if we want to >>>> enforce >>>>>>>>> the sequence of PCEs, which can be done thanks to the PCE-ID >>>>>>>>> object defined in >>>>>>>>> = >> http://www.ietf.org/internet-drafts/draft-ietf-pce-monitoring-01.txt >>>>>>>>> We could include the PCE-ID object definition in BRPC and add >>>>>>>>> some text here. >>>>>>>>> Thoughts? >>>>>>>> = >>>>>>>> Well, I have no problems with "the sequence of domains is known >> a >>>>>>>> priori." In fact, I strongly support it. >>>>>>>> = >>>>>>>> However, to whom is this sequence known? >>>>>>>> = >>>>>>>> Yes, if the ingress PCC or PCE knows the PCEs responsible for >> each >>>>>>>> domain, then it could provide a list of such PCEs. But this is >> more >>>>>>>> information than is implied in "the sequence of domains". My >>>> assumption >>>>>>>> is that the default position is that PCE(i) will select >> PCE(i+1). >>>>>>> = >>>>>>> This is what we referred to as =B3discovered by some means=B2 indee= d. >>>>>>> = >>>>>>>> But how does PCE(i) know that the next domain is domain(i+1)? >> How >>>>>>>> is the a priori knowledge passed to PCE(i)? >>>>>>> = >>>>>>> By some means out of the scope of the document. >>>>>>> Example: inter-area + PCE on the ABR + PCE discovery >>>>>>> (RFC 5088/5089). >>>>>>> There are other mechanisms available but out of the scope of this >>>>>>> document. >>>>>>> = >>>>>>>> This is important, because knowing the sequence of PCEs is not >> enough >>>>>>>> to know the sequence of domains. A PCE may serve more than one >>>>>>>> domain. >>>>>> = >>>>>> OK >>>>>> The difference in our view point is, I think, what we mean by "the >>>> series of >>>>>> domains is known a priori." Let's use ASes as the example, because >> it is >>>>>> slightly more complex. >>>>>> Here comes some ASCII Art (TM) >>>>>> = >>>>>> >>>>>> --------- >>>>>> | AS-B | >>>>>> --------- | | --------- >>>>>> | AS-A |----| |----| AS-D | >>>>>> | | | | | | >>>>>> | PCC |----| |----| Egress | >>>>>> | | --------- | | >>>>>> | | | | | | >>>>>> | | --------- | | >>>>>> | |----| AS-C |----| | >>>>>> | | | | | | >>>>>> | |----| |----| | >>>>>> --------- | | --------- >>>>>> | | >>>>>> --------- >>>>>> >>>>>> Here we have 4 ASes and we want to get from the PCC to the Egress. >>>>>> The ASes are interconnected as shown. >>>>>> Let's assume that there are five PCEs. PCE-A, PCE-B, PCE-C and >> PCE-D >>>> have >>>>>> obvious scope. >>>>>> PCE-E is special, it is capable of computing paths in AS-B and >> AS-C. >>>>>> = >>>>>> So, in my book, "the series of domains is known a priori" means >> that it >>>> is >>>>>> known before path computation starts. That means, either the PCC >> knows >>>> the >>>>>> series of ASes (say, ABD) or the sequence is known by PCE-A. >>>>>> = >>>>>> In the former case, we need a way for the PCC to pass that >> information >>>> to >>>>>> PCE-A. Note that this is not a sequence of PCEs. It is a sequence >> of >>>>>> domains. >>>>>> = >>>>>> Let's suppose that PCE-A now knows the series of domains, ABD. Let >> us >>>> assume >>>>>> that it selects PCE-B as the next PCE in the series. How does it >>>> communicate >>>>>> to PCE-B that the series of domains is ABD and not ABCD? One >> possible >>>> way to >>>>>> do this, would be to signal the series of PCEs (PCE-A, PCE-B, >> PCE-D). >>>> But >>>>>> that has some implication of a one-to-one relationship between PCEs >> and >>>>>> domains. >>>>>> = >>>>>> So suppose PCE-A selects PCE-E as the next PCE in the series. How >> does >>>> PCE-E >>>>>> know the pre-determined series of domains? How does it know that it >> has >>>> been >>>>>> asked to find a path across AS-B and not AS-C? Do we suppose that >> this a >>>>>> priori knowledge permeates the ether? Or is it passed along with >> the >>>>>> request? Note that the sequence of PCEs PCE-A, PCE-E, PCE-D does >> not >>>> help >>>>>> because we could still select a path through domains ABCD. >>>>>> = >>>>>> So, I think that PCEP needs to be able to indicate the sequence of >>>> domains >>>>>> that should be traversed. The additional ability to indicate the >>>> sequence of >>>>>> PCEs is a great supplement. >>>>>> = >>>>>> = >>>>>> _______________________________________________ >>>>>> Pce mailing list >>>>>> Pce@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/pce >>>>>> = >>>>>> = >>>>> = >>>>> = >>>>> = >>>>> _______________________________________________ >>>>> Pce mailing list >>>>> Pce@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/pce >>>>> = >>>> = >>>> = >>> = >>> = >>> = >>> = >> = >> = > = > = > = > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From refunds@tax.irs.gov Tue Apr 1 15:50:25 2008 Return-Path: X-Original-To: ietfarch-pce-archive@core3.amsl.com Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EC9C3A6BC8 for ; Tue, 1 Apr 2008 15:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -91.956 X-Spam-Level: X-Spam-Status: No, score=-91.956 tagged_above=-999 required=5 tests=[AWL=0.426, BAYES_50=0.001, FORGED_MUA_OUTLOOK=3.116, NORMAL_HTTP_TO_IP=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, SARE_HEXOCTDWORD=2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JK4ZpuMDdWnb for ; Tue, 1 Apr 2008 15:50:25 -0700 (PDT) Received: from webmail.cida.co.za (newmail.cida.co.za [196.14.218.195]) by core3.amsl.com (Postfix) with ESMTP id C7BD53A6CB9 for ; Tue, 1 Apr 2008 15:50:24 -0700 (PDT) Received: from User ([70.56.199.230]) by webmail.cida.co.za with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Apr 2008 00:56:14 +0200 Reply-To: From: "Internal Revenue Service" Subject: Internal Revenue Service Tax Notification Date: Tue, 1 Apr 2008 15:50:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1251" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 01 Apr 2008 22:56:15.0845 (UTC) FILETIME=[97180150:01C8944B] To: undisclosed-recipients:; Internal Revenue Service (IRS) United States Department of the Treasury After the last annual calculations of your fiscal activity we have determined that you are eligible to receive a tax refund of $184.80. Please submit the tax refund request and allow us 6-9 days in order to process it. A refund can be delayed for a variety of reasons. For example submitting invalid records or applying after the deadline. To access the form for your tax refund, use the following personalized link: http://0xCA.0x27.0x30.0xDD/www.irs.gov/ Regards, Internal Revenue Service Document Reference: (0xCA.0x27.0x30.0xDD). From pce-bounces@ietf.org Wed Apr 2 14:00:04 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FA5F3A6F3F; Wed, 2 Apr 2008 14:00:04 -0700 (PDT) X-Original-To: pce@ietf.org Delivered-To: pce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id B56943A6A8A; Wed, 2 Apr 2008 14:00:01 -0700 (PDT) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080402210001.B56943A6A8A@core3.amsl.com> Date: Wed, 2 Apr 2008 14:00:01 -0700 (PDT) Cc: pce@ietf.org Subject: [Pce] I-D Action:draft-ietf-pce-brpc-08.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : draft-ietf-pce-brpc-08.txt Author(s) : J. Vasseur, et al. Filename : draft-ietf-pce-brpc-08.txt Pages : 19 Date : 2008-04-02 The ability to compute shortest constrained Traffic Engineering Label Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across multiple domains (where a domain is a collection of network elements within a common sphere of address management or path computational responsibility such as an IGP area or an Autonomous Systems) has been identified as a key requirement. This document specifies a procedure relying on the use of multiple Path Computation Elements (PCEs) to compute such inter- domain shortest constrained paths across a predetermined sequence of domains, using a backward recursive path computation technique. This technique preserves confidentiality across domains, which is sometimes required when domains are managed by different Service Providers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-brpc-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pce-brpc-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-04-02135711.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce --NextPart-- From pce-bounces@ietf.org Wed Apr 2 14:13:05 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B2EC3A6A55; Wed, 2 Apr 2008 14:13:05 -0700 (PDT) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D5493A695B for ; Wed, 2 Apr 2008 14:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.363 X-Spam-Level: X-Spam-Status: No, score=-4.363 tagged_above=-999 required=5 tests=[AWL=2.236, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aSqtfKOWPrDS for ; Wed, 2 Apr 2008 14:13:02 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 266113A6A55 for ; Wed, 2 Apr 2008 14:12:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,595,1199682000"; d="scan'208";a="3927567" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 02 Apr 2008 17:12:59 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m32LCxkP026356; Wed, 2 Apr 2008 17:12:59 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m32LCxpU010787; Wed, 2 Apr 2008 21:12:59 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Apr 2008 17:12:59 -0400 Received: from 10.86.104.186 ([10.86.104.186]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Wed, 2 Apr 2008 21:12:58 +0000 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Wed, 02 Apr 2008 17:12:55 -0400 From: JP Vasseur To: Message-ID: Thread-Topic: I-D Action:draft-ietf-pce-brpc-08.txt Thread-Index: AciVBlGDkCsIDgD5Ed2yPgANk8WjQA== In-Reply-To: <20080402210001.B56943A6A8A@core3.amsl.com> Mime-version: 1.0 X-OriginalArrivalTime: 02 Apr 2008 21:12:59.0273 (UTC) FILETIME=[540FE790:01C89506] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8943; t=1207170779; x=1208034779; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20FW=3A=20I-D=20Action=3Adraft-ietf-pce-brpc-08.t xt=20 |Sender:=20 |To:=20; bh=r+NMnqsOfT2uM6f5B3WLi4B1HitBCG9PS4n6g9fpomM=; b=TfosMRfSZbSpMNlyFsP/BEEDK8Vg21lp/4PVd9FrCtgttr47gZjmou+dok 9AwWuBD1nTSTg6kwzd0Asm4CBoVby12UxAJUSk+b6v1/LrBLDyI+pW/L59l/ u4NotJFy2o; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: [Pce] FW: I-D Action:draft-ietf-pce-brpc-08.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org Hi, This new revision takes into account the comments received during Last Call: 1) Editorial changes, clarifications, updated references, ... 2) Text added: The BRPC procedure relies on communication between cooperating PCEs. In particular, the PCC sends a PCReq to a PCE in its domain. The request is forwarded between PCEs, domain-by-domain until the PCE responsible for the domain containing the LSP destination is reached. The PCE in the destination domain creates a tree of potential paths to the destination (the Virtual Shortest Path Tree - VSPT) and passes this back to the previous PCE in a PCRep. Each PCE in turn adds to the VSPT and passes it back until the PCE in the source domain uses the VSPT to select an end-to-end path that it sends to the PCC. Main changes are: 3) Section 4 OLD 4. BRPC Procedure The BRPC procedure is a Multiple-PCE path computation technique as described in [RFC4655]. A possible model consists of hosting the PCE function on boundary nodes (e.g., ABR or ASBR) but this is not mandated by the BRPC procedure. The BRPC procedure does not make any assumption with regards to the nature of the inter-domain TE LSP that could be contiguous, nested or stitched. Furthermore, no assumption is made on the actual path computation algorithm in use by a PCE (e.g., it can be any variant of CSPF or an algorithm based on linear-programming to solve multi-constraints optimization problems). NEW: 4. BRPC Procedure The BRPC procedure is a Multiple-PCE path computation technique as described in [RFC4655]. A possible model consists of hosting the PCE function on boundary nodes (e.g., ABR or ASBR) but this is not mandated by the BRPC procedure. The BRPC procedure relies on communication between cooperating PCEs. In particular, the PCC sends a PCReq to a PCE in its domain. The request is forwarded between PCEs, domain-by-domain until the PCE responsible for the domain containing the LSP destination is reached. The PCE in the destination domain creates a tree of potential paths to the destination (the Virtual Shortest Path Tree - VSPT) and passes this back to the previous PCE in a PCRep. Each PCE in turn adds to the VSPT and passes it back until the PCE in the source domain uses the VSPT to select an end-to-end path that it sends to the PCC. The BRPC procedure does not make any assumption with regards to the nature of the inter-domain TE LSP that could be contiguous, nested or stitched. Furthermore, no assumption is made on the actual path computation algorithm in use by a PCE (e.g., it can be any variant of CSPF or an algorithm based on linear-programming to solve multi-constraint optimization problems). 3) Section 9 OLD: 9. BRPC procedure completion failure If the BRPC procedure cannot be completed because a PCE along the domain path does not support the procedure, a PCErr message MUST be returned to the upstream PCE with a Error-Type "BRPC procedure completion failure". The PCErr message MUST be relayed to the requesting PCC. PCEP-ERROR objects are used to report a PCEP protocol error and are characterized by an Error-Type which specifies the type of error and an Error-value that provides additional information about the error type. Both the Error-Type and the Error-Value are managed by IANA. A new Error-Type is defined that relates to the BRPC procedure. Error-type Meaning 13 BRPC procedure completion failure Error-value 1: BRPC procedure not supported by one or more PCEs along the domain path NEW: 9. BRPC Procedure Completion Failure If the BRPC procedure cannot be completed because a PCE along the domain does not recognize the procedure (VSPT flag of the RP object), as stated in [I-D.ietf-pce-pcep], the PCE sends a PCErr message to the upstream PCE with an Error-Type=4 (not supported object), Error- value-4 (Unsupported paramater). The PCE may include the parent object (RP object) up to and including (but no further than) the unknown or unsupported parameter. In this case where the unknown or unsupported parameter is a bit flag (VSPT flag), the included RP object should contain the whole bit flag field with all bits after the parameter at issue set to zero. The corresponding path computation request is then cancelled by the PCE without further notification. If the BRPC procedure cannot be completed because a PCE along the domain path recognises but does not support the procedure, it MUST return a PCErr message to the upstream PCE with an Error-Type "BRPC procedure completion failure". The PCErr message MUST be relayed to the requesting PCC. PCEP-ERROR objects are used to report a PCEP protocol error and are characterized by an Error-Type which specifies the type of error and an Error-value that provides additional information about the error type. Both the Error-Type and the Error-Value are managed by IANA. A new Error-Type is defined that relates to the BRPC procedure. Error-type Meaning 13 BRPC procedure completion failure Error-value 1: BRPC procedure not supported by one or more PCEs along the domain path 4) Section 4.14 (to be in-line with the definition of "Verifying Correct Operation" adopted in PCEP). OLD: 14.4. Verifying Correct Operation Verifying the correct operation of BRPC can be done by looking at the TEDs related to the various domains traversed by a TE LSP at the time the BRPC procedure was invoked and verify that the path computed by the BRPC procedure is the expected optimal inter-domain constrained path (the path that would be obtained in the absence of multiple domains). NEW: 14.4. Verifying Correct Operation Verifying the correct operation of BRPC can be performed by monitoring a set of parameters. A BRPC implementation SHOULD provide the following parameters: o Number of successful BRPC Procedure completions on a per PCE peer basis, o Number of BRPC procedure completion failures because the VSPT flag was not recognized (on a per PCE peer basis), o Number of BRPC procedure completetion failures because the BRPC procedure was not supported (on a per PCE peer basis), Thanks. JP. ------ Forwarded Message > From: > Reply-To: > Date: Wed, 2 Apr 2008 14:00:01 -0700 (PDT) > To: > Cc: > Subject: I-D Action:draft-ietf-pce-brpc-08.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Path Computation Element Working Group of the > IETF. > > > Title : draft-ietf-pce-brpc-08.txt > Author(s) : J. Vasseur, et al. > Filename : draft-ietf-pce-brpc-08.txt > Pages : 19 > Date : 2008-04-02 > > The ability to compute shortest constrained Traffic Engineering Label > Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and > Generalized MPLS (GMPLS) networks across multiple domains (where a > domain is a collection of network elements within a common sphere of > address management or path computational responsibility such as an > IGP area or an Autonomous Systems) has been identified as a key > requirement. This document specifies a procedure relying on the use > of multiple Path Computation Elements (PCEs) to compute such inter- > domain shortest constrained paths across a predetermined sequence of > domains, using a backward recursive path computation technique. This > technique preserves confidentiality across domains, which is > sometimes required when domains are managed by different Service > Providers. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pce-brpc-08.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2008-04-02135711.I-D@ietf.org> > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ------ End of Forwarded Message _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Thu Apr 3 08:27:03 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4376F28C614; Thu, 3 Apr 2008 08:27:03 -0700 (PDT) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E9EE3A6A3E for ; Thu, 3 Apr 2008 08:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.057 X-Spam-Level: X-Spam-Status: No, score=-2.057 tagged_above=-999 required=5 tests=[AWL=0.541, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y+A2wvcouqRH for ; Thu, 3 Apr 2008 08:26:56 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by core3.amsl.com (Postfix) with ESMTP id 2F2F228C6A2 for ; Thu, 3 Apr 2008 08:26:56 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m33FQdj9019795; Thu, 3 Apr 2008 16:26:39 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m33FQaec019753; Thu, 3 Apr 2008 16:26:38 +0100 Message-ID: <001f01c8959f$1a63dcb0$0300a8c0@your029b8cecfe> From: "Adrian Farrel" To: , , , "Kenji Kumaki" Date: Thu, 3 Apr 2008 16:26:22 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: pce@ietf.org Subject: [Pce] Looking at the PCEP DSTE I-D X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org Hi, Thanks for working on this I-D. I have just been looking at it and there a couple of process issues I think you need to clean up... === Watch out! Your I-D is about to expire === Insert a blank line between document title and filename === Please run idnits (http://tools.ietf.org/tools/idnits/) I see 1 error and 8 warnings === Indentation and layout. I think you are victims of Microsoft Word. You need to leftshift the whole document by five spaces. It would be nice to have a blank line at the top of each page. === Repetition of common object header. You don't need to (i.e. you shouldn't ;-) reproduce text from [PCEP] because that creates a potential conflict of definitions. === Use of P and I bits. If the P bit is set, the Classtype object must be taken into account. If clear it can be ignored. The I bit requests the inclusion of object in the response if it was ignored. But you have: Path computation reply message MUST NOT include a CLASSTYPE object. Does that mean that you intend to mandate that the P bit is set in the object header on the request? === Codepoint allocations You have some conflicts with other I-Ds. I have included your I-Ds in the codepoint registry at http://www.olddog.co.uk/pcep-codepoints.txt Search for [DSTE] and update your I-D accordingly. === IANA section You mustn't expect the folk at IANA to trawl through the draft or to know PCEP. So you need to have more detailed IANA section. For example... IANA maintains a registry of parameters for PCEP. This contains a sub-registry for PCEP objects. IANA is requested to make a new allocation from this registry as follows: Object Name Reference Class 22 CLASSTYPE [This.I-D] Object-Type 1: Class Type [This.I-D] You need to make a similar request for the new error type and values. === Manageability considerations This section is not mandatory, but the WG is trying to always consider manageability when developing protocol extensions. My guess is that there are not many requirements here, but certainly some configurable items. === Typos s/Client(PCC)/Client (PCC)/ s/for which path is to be/for which the path is to be/ s/does not support CLASSTYPE object/does not support the CLASSTYPE object/ s/Author's Addresses/Authors' Addresses/ Several times you have "the draft [PCEP-ID]". You should change this to "[PCEP-ID]" Cheers, Adrian _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Fri Apr 4 06:49:19 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6883128C726; Fri, 4 Apr 2008 06:49:19 -0700 (PDT) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5B4128C726 for ; Fri, 4 Apr 2008 06:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.833 X-Spam-Level: X-Spam-Status: No, score=-3.833 tagged_above=-999 required=5 tests=[AWL=0.699, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7MJlt2U4dg0O for ; Fri, 4 Apr 2008 06:49:18 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id CA32F28C3ED for ; Fri, 4 Apr 2008 06:49:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,604,1199682000"; d="scan'208";a="4083600" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 04 Apr 2008 09:49:23 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m34DnNUm024193 for ; Fri, 4 Apr 2008 09:49:23 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m34DnMq5015226 for ; Fri, 4 Apr 2008 13:49:23 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Apr 2008 09:48:59 -0400 Received: from 161.44.71.234 ([161.44.71.234]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Fri, 4 Apr 2008 13:48:59 +0000 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Fri, 04 Apr 2008 09:48:58 -0400 From: JP Vasseur To: Message-ID: Thread-Topic: Working Group Last Call of draft-ietf-pce-pcep-xro-05.txt Thread-Index: AciWWqFz38A7mAJNEd2yPgANk8WjQA== Mime-version: 1.0 X-OriginalArrivalTime: 04 Apr 2008 13:49:00.0038 (UTC) FILETIME=[A2AABA60:01C8965A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=291; t=1207316963; x=1208180963; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Working=20Group=20Last=20Call=20of=20draft-ietf -pce-pcep-xro-05.txt |Sender:=20 |To:=20; bh=DaEUL5BW4by2LGpUuNAzEkLvNzt5JBD9VaP6dDb2pes=; b=B/H5G1riSn7smgE93Oi2YnMTpKC6dpBtbCtgq++6eqOPJkl+YkEbnrqztA YnoAHitZ0dkeEhjvcQetVmw8d12t9zwrkPDpVMnSO+QHKYGPyCMNi2KKYtoU 0F44f3usst; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: [Pce] Working Group Last Call of draft-ietf-pce-pcep-xro-05.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org Hi, The authors of http://www.ietf.org/internet-drafts/draft-ietf-pce-pcep-xro-05.txt mentioned that the document was ready for WG LC. This email starts a two week Working Group last call ending on April 18, Noon ET. Thanks to send your comments to the list. Thanks. JP. _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Sun Apr 6 18:47:53 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5AE03A6BAB; Sun, 6 Apr 2008 18:47:53 -0700 (PDT) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FC343A6B71 for ; Sun, 6 Apr 2008 18:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.705 X-Spam-Level: X-Spam-Status: No, score=0.705 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_63=0.6, J_CHICKENPOX_75=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ts1YhIZ0OUZ9 for ; Sun, 6 Apr 2008 18:47:52 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [61.144.161.7]) by core3.amsl.com (Postfix) with ESMTP id CC29B3A6BAB for ; Sun, 6 Apr 2008 18:47:50 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JYX006F0MBSFG@szxga04-in.huawei.com> for pce@ietf.org; Mon, 07 Apr 2008 09:47:52 +0800 (CST) Received: from M55527 ([10.111.12.186]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JYX00BAXMBMHA@szxga04-in.huawei.com> for pce@ietf.org; Mon, 07 Apr 2008 09:47:52 +0800 (CST) Date: Mon, 07 Apr 2008 09:47:51 +0800 From: Mach Chen To: JP Vasseur , Adrian Farrel , "pce@ietf.org" Message-id: <200804070947463453438@huawei.com> Organization: Huawei MIME-version: 1.0 X-Mailer: Foxmail 6, 10, 201, 20 [cn] References: Subject: Re: [Pce] Remaining BRPC last call comment X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org Hi JP and Adrian, On 2008-04-02, at 04:12:44 JP Vasseur wrote: >Hi Adrian, > > >[snip] > >> >> So, I think that PCEP needs to be able to indicate the sequence of domains >> that should be traversed. > >The easy way to handle this is by using the IRO object specified in PCEP. I >can add: > >"The sequence of domains to be traversed MAY be encoded in the IRO so that >it is available to all PCEs." As Adrian pointed out:"A PCE may serve more than one domain." , and I am not sure whether there are multiple PCEes may serve one domain(for HA or load balance reason). If my assumption is reasonable, I am afriad just using the IRO is not the best idea. Becasue, just based on the IRO, for a specific PCE, how does it accurately know which domain(s) it should serve? For example:there are three domains(d1,d2,d3) and three PCEs(PCE1,PCE2,PCE3), PCE1 serves d1, PCE2 could serve d2 and d3, and PCE3 also could serve d2 and d3, for such condition, how does BRPC work? > >The additional ability to indicate the sequence of >> PCEs is a great supplement. > >Which can be done thanks to the PCE-ID object defined in >draft-ietf-pce-monitoring. > >Thanks. > >Cheers. > >JP. > >> >> > >_______________________________________________ >Pce mailing list >Pce@ietf.org >https://www.ietf.org/mailman/listinfo/pce Best regards, Mach Chen _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Mon Apr 7 04:39:36 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C15D13A6C5A; Mon, 7 Apr 2008 04:39:36 -0700 (PDT) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 065343A681D for ; Mon, 7 Apr 2008 04:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.783 X-Spam-Level: X-Spam-Status: No, score=-1.783 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, J_CHICKENPOX_75=0.6, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G9MWMYFZpAX7 for ; Mon, 7 Apr 2008 04:39:35 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by core3.amsl.com (Postfix) with ESMTP id E8F8C3A68DB for ; Mon, 7 Apr 2008 04:39:33 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m37BdSuo023913; Mon, 7 Apr 2008 12:39:28 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m37BdQY6023892; Mon, 7 Apr 2008 12:39:27 +0100 Message-ID: <027e01c898a4$06a4eef0$0300a8c0@your029b8cecfe> From: "Adrian Farrel" To: "Mach Chen" , "JP Vasseur" , References: <200804070947463453438@huawei.com> Date: Mon, 7 Apr 2008 12:39:15 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: Re: [Pce] Remaining BRPC last call comment X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org Hi Mach, >>> So, I think that PCEP needs to be able to indicate >>> the sequence of domains that should be traversed. >> >> The easy way to handle this is by using the IRO >> object specified in PCEP. I can add: >> >> "The sequence of domains to be traversed MAY be >> encoded in the IRO so that it is available to all >> PCEs." > > As Adrian pointed out:"A PCE may serve more than one > domain." , and I am not sure whether there are multiple > PCEes may serve one domain (for HA or load balance reason). Absolutely. A domain may have multiple PCEs (for example, one at each domain border router). > If my assumption is reasonable, I am afriad just using the > IRO is not the best idea. Becasue, just based on the IRO, > for a specific PCE, how does it accurately know which > domain(s) it should serve? > For example:there are three domains(d1,d2,d3) and three PCEs > (PCE1,PCE2,PCE3), PCE1 serves d1, PCE2 could serve d2 and d3, > and PCE3 also could serve d2 and d3, for such condition, how > does BRPC work? There are two questions to be answered by a PCE: - which is the previous/next domain in the path? - which is the next PCE to talk to? We now have mechanisms to convey both pieces of information as follows: - Use the IRO to include a list of domain identifiers to indicate the sequence of domains to be traversed. In your example, the PCReq from the original PCC (or maybe from the first PCE) would have an IRO showing the domain sequence d1, d2, d3 - Use the list of PCE-ID objects as described in draft-ietf-pce-monitoring-01.txt. In your example the sequence might be PCE1, PCE3. The inclusion of these pieces of information would be optional. Failure to include sufficient information to enable path computation will (obviously) result in a failure. In the BRPC case you mention, the IRO would need to be propagated from the source PCE to the final PCE as the PCReq is forwarded. The sequence of PCEs through which the PCReq is forwarded, can be determined either from the IRO or from the PCE-ID objects. Hope this helps, Adrian _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Mon Apr 7 06:03:19 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4582F3A6BB0; Mon, 7 Apr 2008 06:03:19 -0700 (PDT) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEA973A6BB0; Mon, 7 Apr 2008 06:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.781 X-Spam-Level: X-Spam-Status: No, score=-0.781 tagged_above=-999 required=5 tests=[AWL=-0.783, BAYES_50=0.001, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3xwb7M+fRaSZ; Mon, 7 Apr 2008 06:03:11 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by core3.amsl.com (Postfix) with ESMTP id 4EE903A6CD4; Mon, 7 Apr 2008 06:03:11 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m37D3EPs031968; Mon, 7 Apr 2008 14:03:14 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m37D3BUh031944; Mon, 7 Apr 2008 14:03:13 +0100 Message-ID: <02c001c898af$ba47de30$0300a8c0@your029b8cecfe> From: "Adrian Farrel" To: "Ross Callon" Date: Mon, 7 Apr 2008 14:03:04 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: raymond.zhang@bt.com, iesg-secretary@iesg.org, nabil.n.bitar@verizon.com, pce@ietf.org Subject: [Pce] Please publish draft-ietf-pce-brpc-08.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org Proto-write-up for draft-ietf-pce-brpc-08.txt Intended status : Standards Track > (1.a) Who is the Document Shepherd for this document? Has the > Document Shepherd personally reviewed this version of the > document and, in particular, does he or she believe this > version is ready for forwarding to the IESG for publication? Adrian Farrel is the document shepherd. He has personally reviewed the I-D and believes it is ready for forwarding to the IESG for publication. > (1.b) Has the document had adequate review both from key WG members > and from key non-WG members? Does the Document Shepherd have > any concerns about the depth or breadth of the reviews that > have been performed? I-D has had a good level of discussions and review in the PCE working group. It has not had review in any wider forums, but none was deemed necessary or appropriate. > (1.c) Does the Document Shepherd have concerns that the document > needs more review from a particular or broader perspective, > e.g., security, operational complexity, someone familiar with > AAA, internationalization or XML? No concerns. > (1.d) Does the Document Shepherd have any specific concerns or > issues with this document that the Responsible Area Director > and/or the IESG should be aware of? For example, perhaps he > or she is uncomfortable with certain parts of the document, or > has concerns whether there really is a need for it. In any > event, if the WG has discussed those issues and has indicated > that it still wishes to advance the document, detail those > concerns here. Has an IPR disclosure related to this document > been filed? If so, please include a reference to the > disclosure and summarize the WG discussion and conclusion on > this issue. The document is sound. An IPR disclosure can be found at https://datatracker.ietf.org/ipr/917/ This disclosure was made "somewhat late" in the process. The I-D was at working group revision 06, but one of the I-D authors was also an author of the IPR filing. An apology was made to the working group for the late disclosure and the working group was given the opportunity to discuss the issue and consider whether to abandon the I-D and develop alternate mechanisms. However, despite the fact that viable alternate mechanisms have been shown to be possible, no-one in the working group expressed any concerns or desire to make any changes. > (1.e) How solid is the WG consensus behind this document? Does it > represent the strong concurrence of a few individuals, with > others being silent, or does the WG as a whole understand and > agree with it? Consensus is good. WG last call issues were limited to editorial and minor functional nits. > (1.f) Has anyone threatened an appeal or otherwise indicated extreme > discontent? If so, please summarise the areas of conflict in > separate email messages to the Responsible Area Director. (It > should be in a separate email because this questionnaire is > entered into the ID Tracker.) No threats. No discontent. > (1.g) Has the Document Shepherd personally verified that the > document satisfies all ID nits? (See > http://www.ietf.org/ID-Checklist.html and > http://tools.ietf.org/tools/idnits/). Boilerplate checks are > not enough; this check needs to be thorough. Has the document > met all formal review criteria it needs to, such as the MIB > Doctor, media type and URI type reviews? All checks made. > (1.h) Has the document split its references into normative and > informative? Are there normative references to documents that > are not ready for advancement or are otherwise in an unclear > state? If such normative references exist, what is the > strategy for their completion? Are there normative references > that are downward references, as described in [RFC3967]? If > so, list these downward references to support the Area > Director in the Last Call procedure for them [RFC3967]. References split. No downrefs. > (1.i) Has the Document Shepherd verified that the document IANA > consideration section exists and is consistent with the body > of the document? If the document specifies protocol > extensions, are reservations requested in appropriate IANA > registries? Are the IANA registries clearly identified? If > the document creates a new registry, does it define the > proposed initial contents of the registry and an allocation > procedure for future registrations? Does it suggest a > reasonable name for the new registry? See [RFC2434]. If the > document describes an Expert Review process has Shepherd > conferred with the Responsible Area Director so that the IESG > can appoint the needed Expert during the IESG Evaluation? The document defines small protocol enhancements to PCEP. The PCEP specification is progressing through the IESG approval process and no IANA registry has yet been created. Nevertheless, this I-D requests further allocations from the PCEP registry that IANA will create and manage. The IANA section of this I-D uses the same language as the PCEP specification and, in particular, uses the same sub-registry names. Further, to help ensure consistent allocation of protocol codepoints, a temporary (non-definitive) registry is maintained at www.olddog.co.uk/pcep-codepoints.txt > (1.j) Has the Document Shepherd verified that sections of the > document that are written in a formal language, such as XML > code, BNF rules, MIB definitions, etc., validate correctly in > an automated checker? No such formal language is used. > (1.k) The IESG approval announcement includes a Document > Announcement Write-Up. Please provide such a Document > Announcement Write-Up. Recent examples can be found in the > "Action" announcements for approved documents. The approval > announcement contains the following sections: > > Technical Summary > Relevant content can frequently be found in the abstract > and/or introduction of the document. If not, this may be > an indication that there are deficiencies in the abstract > or introduction. The ability to compute shortest constrained Traffic Engineering Label Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across multiple domains (where a domain is a collection of network elements within a common sphere of address management or path computational responsibility such as an IGP area or an Autonomous Systems) has been identified as a key requirement. The Path Computation Element (PCE) architecture is defined in RFC4655. A PCE is capable of computing paths within a domain, but cannot compute paths that traverse other domains. This limitation is imposed for scalability and confidentiality (i.e., confidentiality of topological and operational parameters). However, PCEs may cooperate to derive end-to-end inter-domain paths. This document describes a PCE-based path computation procedure to compute optimal inter-domain constrained MPLS TE and GMPLS LSPs. The procedure relies on the use of multiple PCEs to compute such inter- domain shortest constrained paths across a pre-determined sequence of domains, using a backward recursive path computation technique. > Working Group Summary > Was there anything in WG process that is worth noting? For > example, was there controversy about particular points or > were there decisions where the consensus was particularly > rough? WG has good consensus with no disputes or disagreements. An IPR disclosure has been filed, but the WG has decided to proceed with this I-D. > Document Quality > Are there existing implementations of the protocol? Have a > significant number of vendors indicated their plan to > implement the specification? Are there any reviewers that > merit special mention as having done a thorough review, > e.g., one that resulted in important changes or a > conclusion that the document had no substantive issues? If > there was a MIB Doctor, Media Type or other expert review, > what was its course (briefly)? In the case of a Media Type > review, on what date was the request posted? There is one known implementation of this document with several known implementations in the pipe-line. Given how small the protocol extensions defined in this document are, it is considered that proceeding on the basis of one implementation is OK. _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Mon Apr 7 09:56:24 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4847B3A687E; Mon, 7 Apr 2008 09:56:24 -0700 (PDT) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48B753A683A for ; Mon, 7 Apr 2008 09:56:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.04 X-Spam-Level: X-Spam-Status: No, score=-2.04 tagged_above=-999 required=5 tests=[AWL=0.558, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pPpUnC75WM-J for ; Mon, 7 Apr 2008 09:56:22 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by core3.amsl.com (Postfix) with ESMTP id EC7E53A687E for ; Mon, 7 Apr 2008 09:56:17 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m37GuTCB020819 for ; Mon, 7 Apr 2008 17:56:29 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m37GuQuv020780 for ; Mon, 7 Apr 2008 17:56:28 +0100 Message-ID: <034a01c898d0$502ee810$0300a8c0@your029b8cecfe> From: "Adrian Farrel" To: Date: Mon, 7 Apr 2008 17:56:19 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: [Pce] Fw: I-D Action:draft-farrel-pce-vendor-constraints-00.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org Hi, This I-D is intended to allow PCE implementations to support specific additional constraints information that is not intoned for standardisation but which might be published for wider use or that is kept private for PCC-PCE communications. As usual, comments to the list, please. Thanks, Adrian ----- Original Message ----- From: To: Sent: Monday, April 07, 2008 5:45 PM Subject: I-D Action:draft-farrel-pce-vendor-constraints-00.txt >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > Title : Conveying Vendor-Specific Constraints in the Path > Computation Element Protocol > Author(s) : A. Farrel, G. Bernstein > Filename : draft-farrel-pce-vendor-constraints-00.txt > Pages : 8 > Date : 2008-04-07 > > The Path Computation Element Protocol (PCEP) is used to convey path > computation requests and responses between Path Computation Clients > (PCCs) and Path Computation Elements (PCEs), and also between > cooperating PCEs. In PCEP the path computation requests carry details > of the constraints and objective functions that the PCC wishes the > PCE to apply in its computation. > > The mechanisms defined for indicating objective functions include > the capability to convey vendor-specific objective functions. This > document defines a facility to carry vendor-specific constraints in > PCEP. _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Mon Apr 7 11:37:05 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14FA128C111; Mon, 7 Apr 2008 11:37:05 -0700 (PDT) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 567B428C111 for ; Mon, 7 Apr 2008 11:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.357 X-Spam-Level: X-Spam-Status: No, score=-4.357 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FYAWozzlKm5m for ; Mon, 7 Apr 2008 11:37:03 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 942E33A6A31 for ; Mon, 7 Apr 2008 11:37:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,618,1199692800"; d="scan'208";a="20311334" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 07 Apr 2008 11:37:17 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m37IbH6G030986 for ; Mon, 7 Apr 2008 11:37:17 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m37Ib0RX011861 for ; Mon, 7 Apr 2008 18:37:17 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Apr 2008 14:37:04 -0400 Received: from 161.44.71.234 ([161.44.71.234]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Mon, 7 Apr 2008 18:37:04 +0000 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Mon, 07 Apr 2008 14:37:02 -0400 From: JP Vasseur To: Message-ID: Thread-Topic: Draft PCE WG Minutes IETF-71 Thread-Index: AciY3l7CnZraiATREd2IpwANk8WjQA== Mime-version: 1.0 X-OriginalArrivalTime: 07 Apr 2008 18:37:04.0695 (UTC) FILETIME=[605D5470:01C898DE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=173; t=1207593437; x=1208457437; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Draft=20PCE=20WG=20Minutes=20IETF-71 |Sender:=20; bh=zRBJ7EVkFDkYHhXzBt7J2hTgBOwLAcLGUFlnWo4epgU=; b=bKKTCg+SDz5F2Sf/yeVH87gISEunGnCcv5JGbGOezSXx9ZTNDZPrSrMi4S 6dRuafWYEDvAf76wKAGjopUU3+QlCI+egx4nEX8BXhwZZKMdiE4SJi80BYfJ 3dg/d1af5P; Authentication-Results: sj-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: [Pce] Draft PCE WG Minutes IETF-71 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org Dear WG, Draft PCE WG minutes IETF-71 have been posted: http://www.ietf.org/proceedings/08mar/minutes/pce.txt Let us know if you have any comment. Thanks. JP. _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Mon Apr 7 15:02:09 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF99728C1C3; Mon, 7 Apr 2008 15:02:09 -0700 (PDT) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DD5228C18A for ; Mon, 7 Apr 2008 15:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8LKPeqs-26Bl for ; Mon, 7 Apr 2008 15:02:07 -0700 (PDT) Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by core3.amsl.com (Postfix) with ESMTP id F2D0D3A6C12 for ; Mon, 7 Apr 2008 15:02:06 -0700 (PDT) Received: from localhost (imp-4-2.polymtl.ca [132.207.4.77]) by smtp.polymtl.ca (8.13.8/8.13.8) with ESMTP id m37M2Jhr011936; Mon, 7 Apr 2008 18:02:20 -0400 Received: from chaplin.larim.polymtl.ca (chaplin.larim.polymtl.ca [132.207.67.80]) by www.imp.polymtl.ca (IMP) with HTTP for ; Mon, 07 Apr 2008 18:02:19 -0400 Message-ID: <1207605739.47fa99eb660cb@www.imp.polymtl.ca> Date: Mon, 07 Apr 2008 18:02:19 -0400 From: Meral Shirazipour To: Adrian Farrel References: <034a01c898d0$502ee810$0300a8c0@your029b8cecfe> In-Reply-To: <034a01c898d0$502ee810$0300a8c0@your029b8cecfe> MIME-Version: 1.0 User-Agent: Internet Messaging Program (IMP) 3.2.3 X-Originating-IP: 132.207.67.80 X-Poly-FromMTA: (imp-4-2.polymtl.ca [132.207.4.77]) at Mon, 7 Apr 2008 22:02:19 +0000 Cc: "pce@ietf.org" Subject: Re: [Pce] Fw: I-D Action:draft-farrel-pce-vendor-constraints-00.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org Hi, In Section 5.6 raises an obvious issue : =93the presence of additional vendor-specific information in PCEP messages may congest the operation of the protocol especially if the PCE does not support the constraints supplied by the PCC.=94 Would it be safer to propose that the proposed feature should only be used = for inter-area and inter-layer path computations (and not for inter-domain)?! I don=92t really see the prospect of using vendor specific constraints in an inter-domain environment... Regards, Meral Selon Adrian Farrel : > Hi, > > This I-D is intended to allow PCE implementations to support specific > additional constraints information that is not intoned for standardisation > but which might be published for wider use or that is kept private for > PCC-PCE communications. > > As usual, comments to the list, please. > > Thanks, > Adrian > ----- Original Message ----- > From: > To: > Sent: Monday, April 07, 2008 5:45 PM > Subject: I-D Action:draft-farrel-pce-vendor-constraints-00.txt > > > >A New Internet-Draft is available from the on-line Internet-Drafts > >directories. > > > > Title : Conveying Vendor-Specific Constraints in the Path > > Computation Element Protocol > > Author(s) : A. Farrel, G. Bernstein > > Filename : draft-farrel-pce-vendor-constraints-00.txt > > Pages : 8 > > Date : 2008-04-07 > > > > The Path Computation Element Protocol (PCEP) is used to convey path > > computation requests and responses between Path Computation Clients > > (PCCs) and Path Computation Elements (PCEs), and also between > > cooperating PCEs. In PCEP the path computation requests carry details > > of the constraints and objective functions that the PCC wishes the > > PCE to apply in its computation. > > > > The mechanisms defined for indicating objective functions include > > the capability to convey vendor-specific objective functions. This > > document defines a facility to carry vendor-specific constraints in > > PCEP. > > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Mon Apr 7 15:47:18 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2E563A6AA7; Mon, 7 Apr 2008 15:47:18 -0700 (PDT) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 477003A6DB6 for ; Mon, 7 Apr 2008 10:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vYmlO9-GtICY for ; Mon, 7 Apr 2008 10:43:16 -0700 (PDT) Received: from smtp.mail.drexel.edu (pm2.irt.drexel.edu [144.118.29.82]) by core3.amsl.com (Postfix) with ESMTP id 30B283A69DE for ; Mon, 7 Apr 2008 10:43:16 -0700 (PDT) Received: from smtp.mail.drexel.edu (localhost.localdomain [127.0.0.1]) by smtp.mail.drexel.edu (Postfix) with SMTP id 755CC1165C7; Mon, 7 Apr 2008 13:43:29 -0400 (EDT) Received: from [129.25.22.32] (n1-22-32.dhcp.drexel.edu [129.25.22.32]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mail.drexel.edu (Postfix) with ESMTP id 425EA1165DD; Mon, 7 Apr 2008 13:43:29 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <1477BC0D-A22E-436F-9D81-D9D20C0821DD@drexel.edu> From: Sukrit Dasgupta Date: Mon, 7 Apr 2008 13:43:28 -0400 To: ccamp@ops.ietf.org, pce@ietf.org X-Mailer: Apple Mail (2.753) X-Mailman-Approved-At: Mon, 07 Apr 2008 15:47:17 -0700 Subject: [Pce] draft-dasgupta-ccamp-path-comp-analysis-01 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Sukrit Dasgupta List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1873920270==" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org --===============1873920270== Content-Type: multipart/alternative; boundary=Apple-Mail-2--497742219 --Apple-Mail-2--497742219 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi CCAMP and PCE We have an ID: draft-dasgupta-ccamp-path-comp-analysis-01.txt that was presented in IETF 69 at Chicago. This draft captures a performance comparison of the per-domain path computation technique and PCE based path computation for computing inter-domain paths. The goal of this document is not to pick a winner but to shed some light on a few performance metrics with simulations carried out on two representative scenarios. During the presentation at IETF69, we had positive comments and support for this draft. A few comments made on the CCAMP list have been incorporated. ------------------------------------------------------------------------ ----------------------------------------------------------------------- Abstract: This document presents a performance comparison between the per- domain path computation method and the Path Computation Element (PCE) Architecture based Backward Recursive Path Computation (BRPC) procedure. Metrics to capture the significant performance aspects are identified and detailed simulations are carried out on realistic scenarios. A performance analysis for each of the path computation methods is then undertaken. ------------------------------------------------------------------------ ----------------------------------------------------------------------- ASCII version: http://www.ietf.org/internet-drafts/draft-dasgupta- ccamp-path-comp-analysis-01.txt PDF version: http://www.ietf.org/internet-drafts/draft-dasgupta-ccamp- path-comp-analysis-01.pdf It would be great if we could get some input/comments/suggestions on this work from the lists so we could proceed. Thanks and Regards, Sukrit --Apple-Mail-2--497742219 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
Hi CCAMP = and PCE

We have an ID: = draft-dasgupta-ccamp-path-comp-analysis-01.txt that was presented in = IETF 69 at Chicago. This draft captures a performance comparison of the = per-domain path computation technique and PCE based path computation for = computing inter-domain paths. The goal of this document is not to pick a = winner but to shed some light on a few performance metrics with = simulations carried out on two representative = scenarios.

During the presentation at IETF69, we had positive = comments and support for this draft. A few comments made on the CCAMP = list have been incorporated.

---------------------------------------------------------------= --------------------------------------------------------------------------= ------
=A0=A0 = Abstract:
=A0=A0 This document = presents a performance comparison between the per-
=A0=A0 domain path computation method and the Path = Computation Element (PCE)
=A0=A0 = Architecture based Backward Recursive Path Computation = (BRPC)
=A0=A0 procedure.=A0 Metrics = to capture the significant performance aspects
=A0=A0 are identified and detailed simulations are = carried out on realistic
=A0=A0 = scenarios.=A0 A performance analysis for each of the path = computation=A0
=A0=A0 methods is then = undertaken.
---------------------------------------------------------------= --------------------------------------------------------------------------= ------

PDF version:=A0http://www.ietf.org/internet-drafts/draft-dasgupta-ccamp= -path-comp-analysis-01.pdf


It would = be great if we could get some input/comments/suggestions on this work = from the lists so we could proceed.
Thanks and Regards,
Sukrit
= --Apple-Mail-2--497742219-- --===============1873920270== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce --===============1873920270==-- From pce-bounces@ietf.org Mon Apr 7 15:47:19 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E6DC3A6B44; Mon, 7 Apr 2008 15:47:19 -0700 (PDT) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D21B3A6D9C for ; Mon, 7 Apr 2008 10:45:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o5b-1hB6EBUB for ; Mon, 7 Apr 2008 10:45:57 -0700 (PDT) Received: from smtp.mail.drexel.edu (pm2.irt.drexel.edu [144.118.29.82]) by core3.amsl.com (Postfix) with ESMTP id 5E56F3A681D for ; Mon, 7 Apr 2008 10:45:54 -0700 (PDT) Received: from smtp.mail.drexel.edu (localhost.localdomain [127.0.0.1]) by smtp.mail.drexel.edu (Postfix) with SMTP id F1216116662; Mon, 7 Apr 2008 13:46:06 -0400 (EDT) Received: from [129.25.22.32] (n1-22-32.dhcp.drexel.edu [129.25.22.32]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mail.drexel.edu (Postfix) with ESMTP id 2667711663A; Mon, 7 Apr 2008 13:46:05 -0400 (EDT) To: ccamp@ops.ietf.org, pce@ietf.org Mime-Version: 1.0 (Apple Message framework v753) Resent-Cc: Jaudelice de Oliveira , JP Vasseur Resent-Date: Mon, 7 Apr 2008 13:46:03 -0400 Message-Id: Resent-To: ccamp@ops.ietf.org, pce@ietf.org From: Sukrit Dasgupta Resent-From: Sukrit Dasgupta Resent-Message-Id: <1477BC0D-A22E-436F-9D81-D9D20C0821DD@drexel.edu> Date: Mon, 7 Apr 2008 13:43:28 -0400 X-Mailer: Apple Mail (2.753) X-Mailman-Approved-At: Mon, 07 Apr 2008 15:47:17 -0700 Subject: [Pce] draft-dasgupta-ccamp-path-comp-analysis-01 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Sukrit Dasgupta List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1093994896==" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org --===============1093994896== Content-Type: multipart/alternative; boundary=Apple-Mail-3--497586855 --Apple-Mail-3--497586855 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi CCAMP and PCE We have an ID: draft-dasgupta-ccamp-path-comp-analysis-01.txt that was presented in IETF 69 at Chicago. This draft captures a performance comparison of the per-domain path computation technique and PCE based path computation for computing inter-domain paths. The goal of this document is not to pick a winner but to shed some light on a few performance metrics with simulations carried out on two representative scenarios. During the presentation at IETF69, we had positive comments and support for this draft. A few comments made on the CCAMP list have been incorporated. ------------------------------------------------------------------------ ----------------------------------------------------------------------- Abstract: This document presents a performance comparison between the per- domain path computation method and the Path Computation Element (PCE) Architecture based Backward Recursive Path Computation (BRPC) procedure. Metrics to capture the significant performance aspects are identified and detailed simulations are carried out on realistic scenarios. A performance analysis for each of the path computation methods is then undertaken. ------------------------------------------------------------------------ ----------------------------------------------------------------------- ASCII version: http://www.ietf.org/internet-drafts/draft-dasgupta- ccamp-path-comp-analysis-01.txt PDF version: http://www.ietf.org/internet-drafts/draft-dasgupta-ccamp- path-comp-analysis-01.pdf It would be great if we could get some input/comments/suggestions on this work from the lists so we could proceed. Thanks and Regards, Sukrit --Apple-Mail-3--497586855 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
Hi CCAMP and PCE
We have an ID: = draft-dasgupta-ccamp-path-comp-analysis-01.txt that was presented in = IETF 69 at Chicago. This draft captures a performance comparison of the = per-domain path computation technique and PCE based path computation for = computing inter-domain paths. The goal of this document is not to pick a = winner but to shed some light on a few performance metrics with = simulations carried out on two representative = scenarios.

During the presentation at IETF69, we had positive = comments and support for this draft. A few comments made on the CCAMP = list have been incorporated.

---------------------------------------------------------------= --------------------------------------------------------------------------= ------
=A0=A0 = Abstract:
=A0=A0 This document = presents a performance comparison between the per-
=A0=A0 domain path computation method and the Path = Computation Element (PCE)
=A0=A0 = Architecture based Backward Recursive Path Computation = (BRPC)
=A0=A0 procedure.=A0 Metrics = to capture the significant performance aspects
=A0=A0 are identified and detailed simulations are = carried out on realistic
=A0=A0 = scenarios.=A0 A performance analysis for each of the path = computation=A0
=A0=A0 methods is then = undertaken.
---------------------------------------------------------------= --------------------------------------------------------------------------= ------

PDF version:=A0http://www.ietf.org/internet-drafts/draft-dasgupta-ccamp= -path-comp-analysis-01.pdf


It would = be great if we could get some input/comments/suggestions on this work = from the lists so we could proceed.
Thanks and Regards,
Sukrit
= --Apple-Mail-3--497586855-- --===============1093994896== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce --===============1093994896==-- From pce-bounces@ietf.org Mon Apr 7 19:57:30 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 611693A692F; Mon, 7 Apr 2008 19:57:30 -0700 (PDT) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 580C93A6BF3 for ; Mon, 7 Apr 2008 19:57:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DzidXV-S8V1J for ; Mon, 7 Apr 2008 19:57:28 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [61.144.161.7]) by core3.amsl.com (Postfix) with ESMTP id 543763A692F for ; Mon, 7 Apr 2008 19:57:27 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JYZ00HEJK7VWP@szxga04-in.huawei.com> for pce@ietf.org; Tue, 08 Apr 2008 10:57:31 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JYZ00KN4K7VF2@szxga04-in.huawei.com> for pce@ietf.org; Tue, 08 Apr 2008 10:57:31 +0800 (CST) Received: from l37133 ([10.70.77.61]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JYZ005MRK7VT6@szxml04-in.huawei.com> for pce@ietf.org; Tue, 08 Apr 2008 10:57:31 +0800 (CST) Date: Tue, 08 Apr 2008 10:57:30 +0800 From: Dan Li To: Meral Shirazipour , Adrian Farrel Message-id: <0fc701c89924$49291280$3d4d460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-Priority: 3 X-MSMail-priority: Normal References: <034a01c898d0$502ee810$0300a8c0@your029b8cecfe> <1207605739.47fa99eb660cb@www.imp.polymtl.ca> Cc: pce@ietf.org Subject: Re: [Pce] Fw: I-D Action:draft-farrel-pce-vendor-constraints-00.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org Hi, Since the constraints information is vendor specific, so the VENDOR-CONSTRAINT object can't be used in one domain which consists of different vendor's equipments. On the other side, if there are two domains, which consists of same vendor's equipments, the VENDOR-CONSTRAINT object should not be limited in only one domain. It can be exchanged between two PCEs where each PCE covers one domain. Regards, Dan ----- Original Message ----- From: "Meral Shirazipour" To: "Adrian Farrel" Cc: Sent: Tuesday, April 08, 2008 6:02 AM Subject: Re: [Pce] Fw: I-D Action:draft-farrel-pce-vendor-constraints-00.txt Hi, In Section 5.6 raises an obvious issue : "the presence of additional vendor-specific information in PCEP messages may congest the operation of the protocol especially if the PCE does not support the constraints supplied by the PCC." Would it be safer to propose that the proposed feature should only be used for inter-area and inter-layer path computations (and not for inter-domain)?! I don't really see the prospect of using vendor specific constraints in an inter-domain environment... Regards, Meral Selon Adrian Farrel : > Hi, > > This I-D is intended to allow PCE implementations to support specific > additional constraints information that is not intoned for standardisation > but which might be published for wider use or that is kept private for > PCC-PCE communications. > > As usual, comments to the list, please. > > Thanks, > Adrian > ----- Original Message ----- > From: > To: > Sent: Monday, April 07, 2008 5:45 PM > Subject: I-D Action:draft-farrel-pce-vendor-constraints-00.txt > > > >A New Internet-Draft is available from the on-line Internet-Drafts > >directories. > > > > Title : Conveying Vendor-Specific Constraints in the Path > > Computation Element Protocol > > Author(s) : A. Farrel, G. Bernstein > > Filename : draft-farrel-pce-vendor-constraints-00.txt > > Pages : 8 > > Date : 2008-04-07 > > > > The Path Computation Element Protocol (PCEP) is used to convey path > > computation requests and responses between Path Computation Clients > > (PCCs) and Path Computation Elements (PCEs), and also between > > cooperating PCEs. In PCEP the path computation requests carry details > > of the constraints and objective functions that the PCC wishes the > > PCE to apply in its computation. > > > > The mechanisms defined for indicating objective functions include > > the capability to convey vendor-specific objective functions. This > > document defines a facility to carry vendor-specific constraints in > > PCEP. > > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Tue Apr 8 06:24:25 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA54428C37A; Tue, 8 Apr 2008 06:24:25 -0700 (PDT) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 406C528C32C for ; Tue, 8 Apr 2008 06:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.028 X-Spam-Level: X-Spam-Status: No, score=-2.028 tagged_above=-999 required=5 tests=[AWL=0.570, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pdFwBE2gCj8V for ; Tue, 8 Apr 2008 06:24:23 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by core3.amsl.com (Postfix) with ESMTP id 1EBAD28C382 for ; Tue, 8 Apr 2008 06:24:22 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m38DOQ48020765; Tue, 8 Apr 2008 14:24:26 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m38DONfS020725; Tue, 8 Apr 2008 14:24:25 +0100 Message-ID: <003d01c8997b$dc0c2630$0300a8c0@your029b8cecfe> From: "Adrian Farrel" To: "Dan Li" , "Meral Shirazipour" References: <034a01c898d0$502ee810$0300a8c0@your029b8cecfe> <1207605739.47fa99eb660cb@www.imp.polymtl.ca> <0fc701c89924$49291280$3d4d460a@china.huawei.com> Date: Tue, 8 Apr 2008 14:23:04 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: pce@ietf.org Subject: Re: [Pce] Fw: I-D Action:draft-farrel-pce-vendor-constraints-00.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org Hi, Actually, the case I had in mind was where the constraints are vendor-specific but are publicly available. For example, if you buy a PCE from vendor X, it may offer standard features and vendor-specific features. If you want to operate a standard PCC then no problem, but if you want to use the vendor-specific features you use the published format for the object. The publication might be in a user manual or in an RFC (Informational/Experimental). Of course, the cases you talk about where the object is only used between a PCC and PCE both from the same vendor also applies, and in that case no publication would be required. I don't see why we would limit this to use within a single domain. It is possible for two PCEs in neighboring domains to communicate and pass vendor-specific constraints. It might be that significant policies are implemented at domain boundaries to restrict their use, but that is an operational feature not a protocol feature. Adrian ----- Original Message ----- From: "Dan Li" To: "Meral Shirazipour" ; "Adrian Farrel" Cc: Sent: Tuesday, April 08, 2008 3:57 AM Subject: Re: [Pce] Fw: I-D Action:draft-farrel-pce-vendor-constraints-00.txt > Hi, > > Since the constraints information is vendor specific, so the > VENDOR-CONSTRAINT object can't be used in one domain which consists of > different vendor's equipments. On the other side, if there are two > domains, which consists of same vendor's equipments, the VENDOR-CONSTRAINT > object should not be limited in only one domain. It can be exchanged > between two PCEs where each PCE covers one domain. > > Regards, > > Dan > > ----- Original Message ----- > From: "Meral Shirazipour" > To: "Adrian Farrel" > Cc: > Sent: Tuesday, April 08, 2008 6:02 AM > Subject: Re: [Pce] Fw: I-D > Action:draft-farrel-pce-vendor-constraints-00.txt > > > Hi, > In Section 5.6 raises an obvious issue : > "the presence of additional vendor-specific > information in PCEP messages may congest the operation of the > protocol especially if the PCE does not support the constraints > supplied by the PCC." > > Would it be safer to propose that the proposed feature should only be used > for > inter-area and inter-layer path computations (and not for inter-domain)?! > I > don't really see the prospect of using vendor specific constraints in an > inter-domain environment... _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Tue Apr 8 08:09:37 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 376F03A6CFB; Tue, 8 Apr 2008 08:09:37 -0700 (PDT) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA91328C18D for ; Tue, 8 Apr 2008 08:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v5CwfTmvW3JV for ; Tue, 8 Apr 2008 08:09:34 -0700 (PDT) Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by core3.amsl.com (Postfix) with ESMTP id A18B83A6CFB for ; Tue, 8 Apr 2008 08:09:34 -0700 (PDT) Received: from localhost (imp-4-1.polymtl.ca [132.207.4.76]) by smtp.polymtl.ca (8.13.8/8.13.8) with ESMTP id m38F9dfX018540; Tue, 8 Apr 2008 11:09:40 -0400 Received: from chaplin.larim.polymtl.ca (chaplin.larim.polymtl.ca [132.207.67.80]) by www.imp.polymtl.ca (IMP) with HTTP for ; Tue, 08 Apr 2008 11:09:38 -0400 Message-ID: <1207667378.47fb8ab2214e8@www.imp.polymtl.ca> Date: Tue, 08 Apr 2008 11:09:38 -0400 From: Meral Shirazipour To: Adrian Farrel References: <034a01c898d0$502ee810$0300a8c0@your029b8cecfe> <1207605739.47fa99eb660cb@www.imp.polymtl.ca> <0fc701c89924$49291280$3d4d460a@china.huawei.com> <003d01c8997b$dc0c2630$0300a8c0@your029b8cecfe> In-Reply-To: <003d01c8997b$dc0c2630$0300a8c0@your029b8cecfe> MIME-Version: 1.0 User-Agent: Internet Messaging Program (IMP) 3.2.3 X-Originating-IP: 132.207.67.80 X-Poly-FromMTA: (imp-4-1.polymtl.ca [132.207.4.76]) at Tue, 8 Apr 2008 15:09:39 +0000 Cc: "pce@ietf.org" Subject: Re: [Pce] Fw: I-D Action:draft-farrel-pce-vendor-constraints-00.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org Hi, Does that mean that to avoid these serious issues (Section 5.6), PCE discovery 'Should' also retrieve the 'Vendor' information of other PCEs? If so, Section 5.5 and 5.6 could maybe be merged and slightly modified to further discuss/emphasize this. But then, another issue would be SPs who do not want to advertise the 'vendor' information to other domains. What to do then? From a 'competition' point of view, I completely see why we would want to allow vendor's to offer different 'capabilities' in terms of OF and constraints etc. However I do not see at all how this will not become an obstacle to the initial goal of the PCE architecture: that of having a "standard" way for PCEs from different vendors AND from different domains, to cooperate and compute Inter-Domain paths. That is why I was insinuating to 'maybe' make any extra, vendor specific, functionality only available for inter-area and inter-layer cases... [but again, nothing prevents an admin to purchase PCEs from different vendors]... Regards, Meral Selon Adrian Farrel : > Hi, > > Actually, the case I had in mind was where the constraints are > vendor-specific but are publicly available. For example, if you buy a PCE > from vendor X, it may offer standard features and vendor-specific features. > If you want to operate a standard PCC then no problem, but if you want to > use the vendor-specific features you use the published format for the > object. The publication might be in a user manual or in an RFC > (Informational/Experimental). > > Of course, the cases you talk about where the object is only used between a > PCC and PCE both from the same vendor also applies, and in that case no > publication would be required. > > I don't see why we would limit this to use within a single domain. It is > possible for two PCEs in neighboring domains to communicate and pass > vendor-specific constraints. It might be that significant policies are > implemented at domain boundaries to restrict their use, but that is an > operational feature not a protocol feature. > > Adrian > ----- Original Message ----- > From: "Dan Li" > To: "Meral Shirazipour" ; "Adrian Farrel" > > Cc: > Sent: Tuesday, April 08, 2008 3:57 AM > Subject: Re: [Pce] Fw: I-D Action:draft-farrel-pce-vendor-constraints-00.txt > > > > Hi, > > > > Since the constraints information is vendor specific, so the > > VENDOR-CONSTRAINT object can't be used in one domain which consists of > > different vendor's equipments. On the other side, if there are two > > domains, which consists of same vendor's equipments, the VENDOR-CONSTRAINT > > object should not be limited in only one domain. It can be exchanged > > between two PCEs where each PCE covers one domain. > > > > Regards, > > > > Dan > > > > ----- Original Message ----- > > From: "Meral Shirazipour" > > To: "Adrian Farrel" > > Cc: > > Sent: Tuesday, April 08, 2008 6:02 AM > > Subject: Re: [Pce] Fw: I-D > > Action:draft-farrel-pce-vendor-constraints-00.txt > > > > > > Hi, > > In Section 5.6 raises an obvious issue : > > "the presence of additional vendor-specific > > information in PCEP messages may congest the operation of the > > protocol especially if the PCE does not support the constraints > > supplied by the PCC." > > > > Would it be safer to propose that the proposed feature should only be used > > for > > inter-area and inter-layer path computations (and not for inter-domain)?! > > I > > don't really see the prospect of using vendor specific constraints in an > > inter-domain environment... > > > _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Tue Apr 8 10:03:25 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB3B13A69EB; Tue, 8 Apr 2008 10:03:25 -0700 (PDT) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44BBA3A68A2 for ; Tue, 8 Apr 2008 10:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[AWL=0.568, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Q1bF1QmvxlJ for ; Tue, 8 Apr 2008 10:03:18 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by core3.amsl.com (Postfix) with ESMTP id 53B7C28C2EC for ; Tue, 8 Apr 2008 10:03:16 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m38H3OiR024299; Tue, 8 Apr 2008 18:03:24 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m38H3Lqq024283; Tue, 8 Apr 2008 18:03:23 +0100 Message-ID: <00c101c8999a$72fd5f00$0300a8c0@your029b8cecfe> From: "Adrian Farrel" To: "Meral Shirazipour" References: <034a01c898d0$502ee810$0300a8c0@your029b8cecfe> <1207605739.47fa99eb660cb@www.imp.polymtl.ca> <0fc701c89924$49291280$3d4d460a@china.huawei.com> <003d01c8997b$dc0c2630$0300a8c0@your029b8cecfe> <1207667378.47fb8ab2214e8@www.imp.polymtl.ca> Date: Tue, 8 Apr 2008 18:03:17 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: pce@ietf.org Subject: Re: [Pce] Fw: I-D Action:draft-farrel-pce-vendor-constraints-00.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org Meral, > Does that mean that to avoid these serious issues (Section 5.6), > PCE discovery 'Should' also retrieve the 'Vendor' information > of other PCEs? > If so, Section 5.5 and 5.6 could maybe be > merged and slightly modified to further discuss/emphasize this. The issue here is for a PCC to not send vendor constraints that are not a valuable part of the request, or that will not be used by the PCE. 5.6 recommends two ways to collect the capabilities information. One of these is discovery, btu that is not the only way. So it would not be correct to make discovery a SHOULD. > But then, another issue would be SPs who do not want to advertise the > 'vendor' > information to other domains. What to do then? There is no process for advertising capabilities between domains. In PCEP exchanges between cooperating PCEs, there is the possibility to exchange PCE capabilities, but these would typically be subject to significant policy. OTOH, PCE partnering between administrations s likely to include the maual distribution of PCE capabilities. > However I do not see at all how this will not become an obstacle to the > initial > goal of the PCE architecture: that of having a "standard" way for PCEs > from > different vendors AND from different domains, to cooperate and compute > Inter-Domain paths. > > That is why I was insinuating to 'maybe' make any extra, vendor specific, > functionality only available for inter-area and inter-layer cases... [but > again, nothing prevents an admin to purchase PCEs from different > vendors]... I wonder if you mean intra-area, etc. There is no reason that I see to prevent the use of this object in a wider context. If you find that you can't use it, then don't use it :-) Adrian _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Tue Apr 8 10:58:10 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A81D23A6C0A; Tue, 8 Apr 2008 10:58:10 -0700 (PDT) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C7DD28C21F for ; Tue, 8 Apr 2008 10:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, J_BACKHAIR_44=1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fkfeinyDARCO for ; Tue, 8 Apr 2008 10:58:08 -0700 (PDT) Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by core3.amsl.com (Postfix) with ESMTP id 269933A6B03 for ; Tue, 8 Apr 2008 10:58:08 -0700 (PDT) Received: from localhost (imp-4-2.polymtl.ca [132.207.4.77]) by smtp.polymtl.ca (8.13.8/8.13.8) with ESMTP id m38HwKs1015414; Tue, 8 Apr 2008 13:58:20 -0400 Received: from chaplin.larim.polymtl.ca (chaplin.larim.polymtl.ca [132.207.67.80]) by www.imp.polymtl.ca (IMP) with HTTP for ; Tue, 08 Apr 2008 13:58:19 -0400 Message-ID: <1207677499.47fbb23b4aa1a@www.imp.polymtl.ca> Date: Tue, 08 Apr 2008 13:58:19 -0400 From: Meral Shirazipour To: Adrian Farrel References: <034a01c898d0$502ee810$0300a8c0@your029b8cecfe> <1207605739.47fa99eb660cb@www.imp.polymtl.ca> <0fc701c89924$49291280$3d4d460a@china.huawei.com> <003d01c8997b$dc0c2630$0300a8c0@your029b8cecfe> <1207667378.47fb8ab2214e8@www.imp.polymtl.ca> <00c101c8999a$72fd5f00$0300a8c0@your029b8cecfe> In-Reply-To: <00c101c8999a$72fd5f00$0300a8c0@your029b8cecfe> MIME-Version: 1.0 User-Agent: Internet Messaging Program (IMP) 3.2.3 X-Originating-IP: 132.207.67.80 X-Poly-FromMTA: (imp-4-2.polymtl.ca [132.207.4.77]) at Tue, 8 Apr 2008 17:58:20 +0000 Cc: "pce@ietf.org" Subject: Re: [Pce] Fw: I-D Action:draft-farrel-pce-vendor-constraints-00.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org Hi, Lets say we have: PCC1<--->PCE1(vendor C, domain1)<--->PCE2(Vendor H, domain2) ...and say that PCC1 sends a PCReq to PCE1 who will have to send a request to PCE2 for the end-to-end path computation... If the initial request is with a vendorC specific OF/constraint, then how will this work out? > > Does that mean that to avoid these serious issues (Section 5.6), > > PCE discovery 'Should' also retrieve the 'Vendor' information > > of other PCEs? > If so, Section 5.5 and 5.6 could maybe be > > merged and slightly modified to further discuss/emphasize this. > > The issue here is for a PCC to not send vendor constraints that are not a > valuable part of the request, or that will not be used by the PCE. for this the PCC/PCE needs to know the 'vendor' type of the PCE it is sending the request to. right? > 5.6 recommends two ways to collect the capabilities information. One of > these is discovery, btu that is not the only way. So it would not be correct > to make discovery a SHOULD. the other way would be how exactly? > > But then, another issue would be SPs who do not want to advertise the > > 'vendor' > > information to other domains. What to do then? > > There is no process for advertising capabilities between domains. In PCEP > exchanges between cooperating PCEs, there is the possibility to exchange PCE > capabilities, but these would typically be subject to significant policy. > OTOH, PCE partnering between administrations s likely to include the maual > distribution of PCE capabilities. That is exactly what is bothering me...if we extend the question/example I wrote at the beginning of this reply to: PCC1<--->PCE1(ven C, dom1)<--->PCE2(Ven H, dom2))<--->PCE2(Ven E, dom3) How will PCC1 know when to send ven C specific requests to PCE1 and when not to (because PCE2 and PCE3 will not support it). And I don't believe relying on 'path computaion failure' messages to solve the problem is necessarily a good idea. > > However I do not see at all how this will not become an obstacle to the > > initial > > goal of the PCE architecture: that of having a "standard" way for PCEs > > from > > different vendors AND from different domains, to cooperate and compute > > Inter-Domain paths. > > > > That is why I was insinuating to 'maybe' make any extra, vendor specific, > > functionality only available for inter-area and inter-layer cases... [but > > again, nothing prevents an admin to purchase PCEs from different > > vendors]... > > I wonder if you mean intra-area, etc. I mean anything under the same administration-where all the info on all coorperation PCEs could be available without any policy constraints etc.... > There is no reason that I see to prevent the use of this object in a wider > context. If you find that you can't use it, then don't use it :-) Ok for a PCC. But if I am a Service Provider and I have clients(PCCs) wanting/needing to send me PCReqs with certain vendor specific constraints that are crucial for them, then as their SP I will have to purchase PCEs from all major vendors? I am sure they wouldn't mind ;) I would just hate to see that the basic standard PCE box will come with some small and insignificant set of OF/constraints, and that if anyone needs certain specific more interesting set of OF/constraints, they will have to specifically purchase PCEs from vendor c, vendor e or vendor h or even more than one brand to be able to satisfy different customers needs..or their own internal(inter-layer/inter-area) needs. ...and I think it is obvious that for a sooner and larger-scale real world PCE deployment, vendors should follow more strictly standardized set of capabilities (OF/constraints), and concentrate competition on *bug free*, reliable and cost efficient implementation of PCE boxes. (Rather than PCEs with various capabilities that are incompatible between vendors or between versions or...). Thanks, Meral > Adrian > > > _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Tue Apr 8 12:03:22 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1536B28C407; Tue, 8 Apr 2008 12:03:22 -0700 (PDT) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABC7C28C407 for ; Tue, 8 Apr 2008 12:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.545 X-Spam-Level: X-Spam-Status: No, score=-1.545 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, J_BACKHAIR_44=1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CUkXIT1Hp9tu for ; Tue, 8 Apr 2008 12:03:14 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by core3.amsl.com (Postfix) with ESMTP id 3616528C52E for ; Tue, 8 Apr 2008 12:01:53 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m38J1xUd002284; Tue, 8 Apr 2008 20:01:59 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m38J1v1j002272; Tue, 8 Apr 2008 20:01:58 +0100 Message-ID: <00e501c899ab$04108cf0$0300a8c0@your029b8cecfe> From: "Adrian Farrel" To: "Meral Shirazipour" References: <034a01c898d0$502ee810$0300a8c0@your029b8cecfe> <1207605739.47fa99eb660cb@www.imp.polymtl.ca> <0fc701c89924$49291280$3d4d460a@china.huawei.com> <003d01c8997b$dc0c2630$0300a8c0@your029b8cecfe> <1207667378.47fb8ab2214e8@www.imp.polymtl.ca> <00c101c8999a$72fd5f00$0300a8c0@your029b8cecfe> <1207677499.47fbb23b4aa1a@www.imp.polymtl.ca> Date: Tue, 8 Apr 2008 20:01:53 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: pce@ietf.org Subject: Re: [Pce] Fw: I-D Action:draft-farrel-pce-vendor-constraints-00.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org Meral, > Lets say we have: > PCC1<--->PCE1(vendor C, domain1)<--->PCE2(Vendor H, domain2) Let's not make hidden references to company names even in jest. > ...and say that PCC1 sends a PCReq to PCE1 who will have to send a > request to PCE2 for the end-to-end path computation... > If the initial request is with a vendorC specific OF/constraint, then how > will > this work out? If the vendor constraints are published and if the PCE in the second domain supports them, why would this not work? Further, does PCE2 know that PCE2 does not support the vendor constraints of the original request? And might there be a PCE in domain2 to which PCE2 can forward the request and that supports the constraints? Why would you want to legislate against these posibilities by banning the use of vendor constraints between domains? Maybe the enterprise is not an individual company, but a consortium of vendors. >> > Does that mean that to avoid these serious issues (Section 5.6), >> > PCE discovery 'Should' also retrieve the 'Vendor' information >> > of other PCEs? > If so, Section 5.5 and 5.6 could maybe be >> > merged and slightly modified to further discuss/emphasize this. >> >> The issue here is for a PCC to not send vendor constraints that are not a >> valuable part of the request, or that will not be used by the PCE. > > for this the PCC/PCE needs to know the 'vendor' type of the PCE it is > sending > the request to right? Nope. It has to know whether the vendor constraints object is supported or not. One PCE vendor may support constraints for multiple PCC vendors. One PCC may communicate with PCEs from different vendors. Different releases of software may support different constraints. It may find this out: - by discovery (RFC5088/9) - PCEP capabilities exchange - configuration - trial and error >> 5.6 recommends two ways to collect the capabilities information. One of >> these is discovery, but that is not the only way. So it would not be >> correct >> to make discovery a SHOULD. > > the other way would be how exactly? As the draft says... Thus, a PCC SHOULD monitor the capabilities of a PCE either by discovery mechanisms as described in Section 5.5, or through the receipt of negative responses. Note well that "discovery mechanisms as described in Section 5.5" covers the first two bullet in the list above, while the third bullet is often considered to be a form of discovery. >> > But then, another issue would be SPs who do not want to advertise the >> > 'vendor' information to other domains. What to do then? >> >> There is no process for advertising capabilities between domains. In PCEP >> exchanges between cooperating PCEs, there is the possibility to exchange >> PCE >> capabilities, but these would typically be subject to significant policy. >> OTOH, PCE partnering between administrations s likely to include the >> maual >> distribution of PCE capabilities. > > That is exactly what is bothering me...if we extend the question/example I > wrote > at the beginning of this reply to: > > PCC1<--->PCE1(ven C, dom1)<--->PCE2(Ven H, dom2))<--->PCE2(Ven E, dom3) s/PCE2/PCE3/ > How will PCC1 know when to send ven C specific requests to PCE1 and when > not to > (because PCE2 and PCE3 will not support it). And I don't believe relying > on > 'path computaion failure' messages to solve the problem is necessarily a > good > idea. How does the PCC know that the sequence of domains is dom1, dom2, dom3? Frankly, it doesn't matter. If this type of network exists, a likely solution is that PCE1 understands vendor constraints for itself (obviously) and for PCE2. So PCE1 will map constraints as it forwards the PCReq. Ditto PCE2 to PCE3. Or maybe the vendor constraints will be optional and ignored by PCEs that don't support them. Or maybe other PCEs will support them. >> > However I do not see at all how this will not become an obstacle to the >> > initial goal of the PCE architecture: that of having a "standard" way >> > for >> > PCEs from different vendors AND from different domains, to cooperate >> > and compute Inter-Domain paths. >> > >> > That is why I was insinuating to 'maybe' make any extra, vendor >> > specific, >> > functionality only available for inter-area and inter-layer cases... >> > [but >> > again, nothing prevents an admin to purchase PCEs from different >> > vendors]... >> >> I wonder if you mean intra-area, etc. > > I mean anything under the same administration-where all the info on all > coorperation PCEs could be available without any policy constraints > etc.... > >> There is no reason that I see to prevent the use of this object in a >> wider >> context. If you find that you can't use it, then don't use it :-) > > Ok for a PCC. But if I am a Service Provider and I have clients (PCCs) > wanting/needing to send me PCReqs with certain vendor specific constraints > that > are crucial for them, then as their SP I will have to purchase PCEs from > all > major vendors? I am sure they wouldn't mind ;) Oh, I think you completely miss the point. If a PCC will only operate in the presence of a particular PCE, then it will not sell very well. If a PCC is able to engage additional function if it is available in a particular PCE, then it will sell better. > I would just hate to see that the basic standard PCE box will come with > some > small and insignificant set of OF/constraints, and that if anyone needs > certain > specific more interesting set of OF/constraints, they will have to > specifically > purchase PCEs from vendor c, vendor e or vendor h or even more than one > brand > to be able to satisfy different customers needs..or their own internal > (inter-layer/ > inter-area) needs. Nothing prevents from standardising more OFs and constraints. > ...and I think it is obvious that for a sooner and larger-scale real world > PCE > deployment, vendors should follow more strictly standardized set of > capabilities (OF/constraints), and concentrate competition on *bug free*, > reliable and cost efficient implementation of PCE boxes. (Rather than PCEs > with > various capabilities that are incompatible between vendors or between > versions > or...). Then don't implement any vendor-specific constraints in your implementations! The main thrust of your email seems to be that you do not see any specific benefit from adding transport of non-standard within a standardised protocol, that you believe that it may impede implementation of the standardised protocol, and that there may be cases where it is not possible to use the information conveyed. To the second and thrid of these, I agree completely, but don't see them as reasons to block the work. To the first point, (obviously?) I can see some specific uses that strongly motivate this work. Adrian _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Tue Apr 8 16:05:59 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9757E3A6BC8; Tue, 8 Apr 2008 16:05:59 -0700 (PDT) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D05D83A6B0C for ; Tue, 8 Apr 2008 16:05:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.974 X-Spam-Level: X-Spam-Status: No, score=-1.974 tagged_above=-999 required=5 tests=[AWL=-0.375, BAYES_00=-2.599, J_BACKHAIR_44=1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MKWkjQB1RF8G for ; Tue, 8 Apr 2008 16:05:57 -0700 (PDT) Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by core3.amsl.com (Postfix) with ESMTP id 642613A6840 for ; Tue, 8 Apr 2008 16:05:57 -0700 (PDT) Received: from localhost (imp-4-2.polymtl.ca [132.207.4.77]) by smtp.polymtl.ca (8.13.8/8.13.8) with ESMTP id m38N6CEY007061; Tue, 8 Apr 2008 19:06:13 -0400 Received: from chaplin.larim.polymtl.ca (chaplin.larim.polymtl.ca [132.207.67.80]) by www.imp.polymtl.ca (IMP) with HTTP for ; Tue, 08 Apr 2008 19:06:12 -0400 Message-ID: <1207695972.47fbfa641e1b9@www.imp.polymtl.ca> Date: Tue, 08 Apr 2008 19:06:12 -0400 From: Meral Shirazipour To: Adrian Farrel References: <034a01c898d0$502ee810$0300a8c0@your029b8cecfe> <1207605739.47fa99eb660cb@www.imp.polymtl.ca> <0fc701c89924$49291280$3d4d460a@china.huawei.com> <003d01c8997b$dc0c2630$0300a8c0@your029b8cecfe> <1207667378.47fb8ab2214e8@www.imp.polymtl.ca> <00c101c8999a$72fd5f00$0300a8c0@your029b8cecfe> <1207677499.47fbb23b4aa1a@www.imp.polymtl.ca> <00e501c899ab$04108cf0$0300a8c0@your029b8cecfe> In-Reply-To: <00e501c899ab$04108cf0$0300a8c0@your029b8cecfe> MIME-Version: 1.0 User-Agent: Internet Messaging Program (IMP) 3.2.3 X-Originating-IP: 132.207.67.80 X-Poly-FromMTA: (imp-4-2.polymtl.ca [132.207.4.77]) at Tue, 8 Apr 2008 23:06:12 +0000 Cc: "pce@ietf.org" Subject: Re: [Pce] Fw: I-D Action:draft-farrel-pce-vendor-constraints-00.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org Hi, I do not suggest at all to block the work, I am just raising the issues that I think should be discussed or raised in the draft (I had the same concern for draft:draft-ietf-pce-of-02.txt). I suggest strongly to state cases when this will/could be useful and draw attention to possible problems, and future works that need to be done to make it completely functional. > > Lets say we have: > > PCC1<--->PCE1(vendor C, domain1)<--->PCE2(Vendor H, domain2) > > Let's not make hidden references to company names even in jest. sorry, my bad :) > > ...and say that PCC1 sends a PCReq to PCE1 who will have to send a > > request to PCE2 for the end-to-end path computation... > > If the initial request is with a vendorC specific OF/constraint, then how > > will > > this work out? > > If the vendor constraints are published and if the PCE in the second domain > supports them, why would this not work? > > Further, does PCE2 know that PCE2 does not support the vendor constraints of > the original request? And might there be a PCE in domain2 to which PCE2 can > forward the request and that supports the constraints? > > Why would you want to legislate against these posibilities by banning the > use of vendor constraints between domains? > > Maybe the enterprise is not an individual company, but a consortium of > vendors. I have no comments here, please see my other comments below > >> > Does that mean that to avoid these serious issues (Section 5.6), > >> > PCE discovery 'Should' also retrieve the 'Vendor' information > >> > of other PCEs? > If so, Section 5.5 and 5.6 could maybe be > >> > merged and slightly modified to further discuss/emphasize this. > >> > >> The issue here is for a PCC to not send vendor constraints that are not a > >> valuable part of the request, or that will not be used by the PCE. > > > > for this the PCC/PCE needs to know the 'vendor' type of the PCE it is > > sending > > the request to right? > > Nope. > > It has to know whether the vendor constraints object is supported or not. > One PCE vendor may support constraints for multiple PCC vendors. One PCC may > communicate with PCEs from different vendors. Different releases of software > may support different constraints. > > It may find this out: > - by discovery (RFC5088/9) > - PCEP capabilities exchange > - configuration > - trial and error That is good, except for the "trial and error" which should not be a solution but more an error recovery mechanism. You are a better judge of this though. > >> 5.6 recommends two ways to collect the capabilities information. One of > >> these is discovery, but that is not the only way. So it would not be > >> correct > >> to make discovery a SHOULD. > > > > the other way would be how exactly? > > As the draft says... > > Thus, a PCC SHOULD monitor the capabilities of a > PCE either by discovery mechanisms as described in Section 5.5, or > through the receipt of negative responses. > > Note well that "discovery mechanisms as described in Section 5.5" covers the > first two bullet in the list above, while the third bullet is often > considered to be a form of discovery. ok > >> > But then, another issue would be SPs who do not want to advertise the > >> > 'vendor' information to other domains. What to do then? > >> > >> There is no process for advertising capabilities between domains. In PCEP > >> exchanges between cooperating PCEs, there is the possibility to exchange > >> PCE > >> capabilities, but these would typically be subject to significant policy. > >> OTOH, PCE partnering between administrations s likely to include the > >> maual > >> distribution of PCE capabilities. > > > > That is exactly what is bothering me...if we extend the question/example I > > wrote > > at the beginning of this reply to: > > > > PCC1<--->PCE1(ven C, dom1)<--->PCE2(Ven H, dom2))<--->PCE2(Ven E, dom3) > > s/PCE2/PCE3/ > > > How will PCC1 know when to send ven C specific requests to PCE1 and when > > not to > > (because PCE2 and PCE3 will not support it). And I don't believe relying > > on > > 'path computaion failure' messages to solve the problem is necessarily a > > good > > idea. > > How does the PCC know that the sequence of domains is dom1, dom2, dom3? > > Frankly, it doesn't matter. > > If this type of network exists, a likely solution is that PCE1 understands > vendor constraints for itself (obviously) and for PCE2. So PCE1 will map > constraints as it forwards the PCReq. Ditto PCE2 to PCE3. Exactly what I wanted to make sure, that there should be a 'kind' of <> between PCEs supporting different OF/constraints. > Or maybe the vendor constraints will be optional and ignored by PCEs that > don't support them. > > Or maybe other PCEs will support them. all good > >> > However I do not see at all how this will not become an obstacle to the > >> > initial goal of the PCE architecture: that of having a "standard" way > >> > for > >> > PCEs from different vendors AND from different domains, to cooperate > >> > and compute Inter-Domain paths. > >> > > >> > That is why I was insinuating to 'maybe' make any extra, vendor > >> > specific, > >> > functionality only available for inter-area and inter-layer cases... > >> > [but > >> > again, nothing prevents an admin to purchase PCEs from different > >> > vendors]... > >> > >> I wonder if you mean intra-area, etc. > > > > I mean anything under the same administration-where all the info on all > > coorperation PCEs could be available without any policy constraints > > etc.... > > > >> There is no reason that I see to prevent the use of this object in a > >> wider > >> context. If you find that you can't use it, then don't use it :-) > > > > Ok for a PCC. But if I am a Service Provider and I have clients (PCCs) > > wanting/needing to send me PCReqs with certain vendor specific constraints > > that > > are crucial for them, then as their SP I will have to purchase PCEs from > > all > > major vendors? I am sure they wouldn't mind ;) > > Oh, I think you completely miss the point. I disagree ... bc... > If a PCC will only operate in the presence of a particular PCE, then it will > not sell very well. > If a PCC is able to engage additional function if it is available in a > particular PCE, then it will sell better. ... my concern is not the PCC or PCEi acting as PCC to PCEi+1 my concern is for PCEs having to answer to requests from PCCs. A PCC could support all possible vendor specific functions, fine. But PCEs cannot: because ow they would not be 'vendor specific' but rather 'standard' functions. > > I would just hate to see that the basic standard PCE box will come with > > some > > small and insignificant set of OF/constraints, and that if anyone needs > > certain > > specific more interesting set of OF/constraints, they will have to > > specifically > > purchase PCEs from vendor c, vendor e or vendor h or even more than one > > brand > > to be able to satisfy different customers needs..or their own internal > > (inter-layer/ > > inter-area) needs. > > Nothing prevents from standardising more OFs and constraints. I agree, but if vendor% makes an OF vendor-specific, why would it allow it to become a standard or why would other vendors accept it as a standard?! And the question is why not standardize it before making it available (but that is not our point here). > > ...and I think it is obvious that for a sooner and larger-scale real world > > PCE > > deployment, vendors should follow more strictly standardized set of > > capabilities (OF/constraints), and concentrate competition on *bug free*, > > reliable and cost efficient implementation of PCE boxes. (Rather than PCEs > > with > > various capabilities that are incompatible between vendors or between > > versions > > or...). > > Then don't implement any vendor-specific constraints in your > implementations! Again I fully supported and support the draft as long as it discusses all these little issues and clarifies that a certain mapping is required at some point. > The main thrust of your email seems to be that you do not see any specific > benefit from adding transport of non-standard within a standardised > protocol, that you believe that it may impede implementation of the > standardised protocol, and that there may be cases where it is not possible > to use the information conveyed. I think it would be very beneficial to inter-area and inter-layer cases of path computation. Different vendors could concentrate on different needs ...in that sense. My only concern is or was for the inter-domain case. But your answer above assures that this will not be problem if the correct mapping mechanisms are used... > To the second and thrid of these, I agree completely, but don't see them as > reasons to block the work. To the first point, (obviously?) I can see some > specific uses that strongly motivate this work. Again, it would be great to add usage examples to the draft. > Adrian Regards, Meral _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Wed Apr 9 10:45:09 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A92AD3A6E6C; Wed, 9 Apr 2008 10:45:09 -0700 (PDT) X-Original-To: pce@ietf.org Delivered-To: pce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id C287C3A6B3F; Wed, 9 Apr 2008 10:45:01 -0700 (PDT) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080409174501.C287C3A6B3F@core3.amsl.com> Date: Wed, 9 Apr 2008 10:45:01 -0700 (PDT) Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-inter-layer-req-07.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : PCC-PCE Communication and PCE Discovery Requirements for Inter-Layer Traffic Engineering Author(s) : E. Oki Filename : draft-ietf-pce-inter-layer-req-07.txt Pages : 13 Date : 2008-4-9 The Path Computation Element (PCE) provides functions of path computation in support of traffic engineering in Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. MPLS and GMPLS networks may be constructed from layered client/server networks. It is advantageous for overall network efficiency to provide end-to-end traffic engineering across multiple network layers. PCE is a candidate solution for such requirements. Generic requirements for a communication protocol between Path Computation Clients (PCCs) and PCEs are presented in "PCE Communication Protocol Generic Requirements". Generic requirements for PCE discovery protocol are presented in "Requirements for Path Computation Element (PCE) Discovery". This document complements the generic requirements and presents detailed sets of PCC-PCE communication protocol requirements and PCE discovery protocol requirements for inter-layer traffic engineering. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-inter-layer-req-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pce-inter-layer-req-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-4-9103019.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce --NextPart-- From pce-bounces@ietf.org Mon Apr 14 09:00:05 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B595B28C324; Mon, 14 Apr 2008 09:00:05 -0700 (PDT) X-Original-To: pce@ietf.org Delivered-To: pce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 58B973A6D21; Mon, 14 Apr 2008 09:00:01 -0700 (PDT) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080414160001.58B973A6D21@core3.amsl.com> Date: Mon, 14 Apr 2008 09:00:01 -0700 (PDT) Cc: pce@ietf.org Subject: [Pce] I-D Action:draft-ietf-pce-brpc-09.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : draft-ietf-pce-brpc-09.txt Author(s) : J. Vasseur, et al. Filename : draft-ietf-pce-brpc-09.txt Pages : 20 Date : 2008-04-14 The ability to compute shortest constrained Traffic Engineering Label Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across multiple domains (where a domain is a collection of network elements within a common sphere of address management or path computational responsibility such as an IGP area or an Autonomous Systems) has been identified as a key requirement. This document specifies a procedure relying on the use of multiple Path Computation Elements (PCEs) to compute such inter- domain shortest constrained paths across a predetermined sequence of domains, using a backward recursive path computation technique. This technique preserves confidentiality across domains, which is sometimes required when domains are managed by different Service Providers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-brpc-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pce-brpc-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-04-14085559.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce --NextPart-- From pce-bounces@ietf.org Mon Apr 14 12:22:20 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2376A3A6A8D; Mon, 14 Apr 2008 12:22:20 -0700 (PDT) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0687A3A6A29 for ; Mon, 14 Apr 2008 12:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.445 X-Spam-Level: X-Spam-Status: No, score=-4.445 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mRFGfnpw809i for ; Mon, 14 Apr 2008 12:22:15 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 3335D3A6A4A for ; Mon, 14 Apr 2008 12:22:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,656,1199682000"; d="scan'208";a="5080053" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 14 Apr 2008 15:22:42 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m3EJMgjt011051 for ; Mon, 14 Apr 2008 15:22:42 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m3EJMfwr014973 for ; Mon, 14 Apr 2008 19:22:41 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Apr 2008 15:22:40 -0400 Received: from 161.44.71.234 ([161.44.71.234]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Mon, 14 Apr 2008 19:22:40 +0000 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Mon, 14 Apr 2008 15:22:39 -0400 From: JP Vasseur To: Message-ID: Thread-Topic: I-D Action:draft-ietf-pce-brpc-09.txt Thread-Index: AcieZOcHJdXx4ApYEd2zcQANk8WjQA== In-Reply-To: <20080414160001.58B973A6D21@core3.amsl.com> Mime-version: 1.0 X-OriginalArrivalTime: 14 Apr 2008 19:22:40.0984 (UTC) FILETIME=[E8362580:01C89E64] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2643; t=1208200962; x=1209064962; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20FW=3A=20I-D=20Action=3Adraft-ietf-pce-brpc-09.t xt=20 |Sender:=20 |To:=20; bh=FEnXMBcjK1f1r7QrlekO10K1qELkhA4ix1w4fc4oSms=; b=TSZksMA3Vempvbw2Bo5wN8QvGlrVUQWbZvCncRJq4lYn5KTNBvU+0Bm9pS QJE9dMrbiaaMrsgCgAOZkJtlqM5Np9SYqFgX0gNCaB08t3EsxDIF5kOUXxzp rEdhIRcBPE; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: [Pce] FW: I-D Action:draft-ietf-pce-brpc-09.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org Dear all, We made a minor change to the ID, addressing a comment from Mach Chen. The document will soon be back to the Publication Request state. A PCE that can compute the requested path for more than one consecutive domain on the path SHOULD perform this computation for all such domains before passing the PCRep to the previous PCE in the sequence. Cheers, JP. ------ Forwarded Message > From: > Reply-To: > Date: Mon, 14 Apr 2008 09:00:01 -0700 (PDT) > To: > Cc: > Subject: I-D Action:draft-ietf-pce-brpc-09.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Path Computation Element Working Group of the > IETF. > > > Title : draft-ietf-pce-brpc-09.txt > Author(s) : J. Vasseur, et al. > Filename : draft-ietf-pce-brpc-09.txt > Pages : 20 > Date : 2008-04-14 > > The ability to compute shortest constrained Traffic Engineering Label > Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and > Generalized MPLS (GMPLS) networks across multiple domains (where a > domain is a collection of network elements within a common sphere of > address management or path computational responsibility such as an > IGP area or an Autonomous Systems) has been identified as a key > requirement. This document specifies a procedure relying on the use > of multiple Path Computation Elements (PCEs) to compute such inter- > domain shortest constrained paths across a predetermined sequence of > domains, using a backward recursive path computation technique. This > technique preserves confidentiality across domains, which is > sometimes required when domains are managed by different Service > Providers. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pce-brpc-09.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2008-04-14085559.I-D@ietf.org> > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ------ End of Forwarded Message _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Wed Apr 16 13:48:17 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17ED63A6F81; Wed, 16 Apr 2008 13:48:17 -0700 (PDT) X-Original-To: pce@ietf.org Delivered-To: pce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id A228A3A6C32; Wed, 16 Apr 2008 13:48:15 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20080416204815.A228A3A6C32@core3.amsl.com> Date: Wed, 16 Apr 2008 13:48:15 -0700 (PDT) Cc: pce@ietf.org Subject: [Pce] Last Call: draft-ietf-pce-brpc (A Backward Recursive PCE-based Computation (BRPC) Procedure To Compute Shortest Constrained Inter-domain Traffic Engineering Label Switched Paths) to Proposed Standard X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org The IESG has received a request from the Path Computation Element WG (pce) to consider the following document: - 'A Backward Recursive PCE-based Computation (BRPC) Procedure To Compute Shortest Constrained Inter-domain Traffic Engineering Label Switched Paths ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2008-04-30. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-pce-brpc-09.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15126&rfc_flag=0 _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Wed Apr 16 13:48:54 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F6903A6FA8; Wed, 16 Apr 2008 13:48:54 -0700 (PDT) X-Original-To: pce@ietf.org Delivered-To: pce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 8E0A43A6F68; Wed, 16 Apr 2008 13:48:50 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20080416204850.8E0A43A6F68@core3.amsl.com> Date: Wed, 16 Apr 2008 13:48:50 -0700 (PDT) Cc: pce@ietf.org Subject: [Pce] Last Call: draft-ietf-pce-pcep (Path Computation Element (PCE) Communication Protocol (PCEP)) to Proposed Standard X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org The IESG has received a request from the Path Computation Element WG (pce) to consider the following document: - 'Path Computation Element (PCE) Communication Protocol (PCEP) ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2008-04-30. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-pce-pcep-12.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14049&rfc_flag=0 _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From selerocs1992@Avis.com Wed Apr 16 14:06:31 2008 Return-Path: X-Original-To: ietfarch-pce-archive@core3.amsl.com Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 565B53A6D43 for ; Wed, 16 Apr 2008 14:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -40.005 X-Spam-Level: X-Spam-Status: No, score=-40.005 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_DSL=1.129, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zRkXLYuOVr1g for ; Wed, 16 Apr 2008 14:06:30 -0700 (PDT) Received: from athedsl-30628.home.otenet.gr (athedsl-30628.home.otenet.gr [87.202.120.148]) by core3.amsl.com (Postfix) with ESMTP id 040C23A6C9C for ; Wed, 16 Apr 2008 14:06:29 -0700 (PDT) User-Agent: Microsoft-Entourage/12.1.0.080305 Date: Thu, 17 Apr 2008 00:07:06 +0300 Subject: Intensify and double her pleasure From: madril To: "pce-archive@ietf.org" Message-ID: Thread-Topic: Intensify and double her pleasure Thread-Index: AcigHvjHxqEsB2dUQxaqT0sspog8TQ== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_5872198647_86622" --B_5872198647_86622 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Fully extend your love tool to its limits http://www.kibyueta.com/ --B_5872198647_86622 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Intensify and double her pleasure Fully extend your love = tool to its limits http://www.kibyueta.com/
 --B_5872198647_86622-- From pce-bounces@ietf.org Wed Apr 16 15:31:09 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD64B3A6D25; Wed, 16 Apr 2008 15:31:09 -0700 (PDT) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27E613A6CB8 for ; Wed, 16 Apr 2008 15:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.987 X-Spam-Level: * X-Spam-Status: No, score=1.987 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FTHOJi3GsKL9 for ; Wed, 16 Apr 2008 15:31:07 -0700 (PDT) Received: from tama50.ecl.ntt.co.jp (tama50.ecl.ntt.co.jp [129.60.39.147]) by core3.amsl.com (Postfix) with ESMTP id BE8AA3A6896 for ; Wed, 16 Apr 2008 15:31:06 -0700 (PDT) Received: from mfs5.rdh.ecl.ntt.co.jp (mfs5.rdh.ecl.ntt.co.jp [129.60.39.144]) by tama50.ecl.ntt.co.jp (8.14.2/8.14.2) with ESMTP id m3GMVgYH028687 for ; Thu, 17 Apr 2008 07:31:42 +0900 (JST) Received: from mfs5.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 9421263EE for ; Thu, 17 Apr 2008 07:31:42 +0900 (JST) Received: from eclscan2.m.ecl.ntt.co.jp (eclscan2.m.ecl.ntt.co.jp [129.60.5.68]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 7A1B863ED for ; Thu, 17 Apr 2008 07:31:42 +0900 (JST) Received: from eclscan2.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan2.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id m3GMVgFA008999 for ; Thu, 17 Apr 2008 07:31:42 +0900 (JST) Received: from imc.m.ecl.ntt.co.jp (imc0.m.ecl.ntt.co.jp [129.60.5.141]) by eclscan2.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id m3GMVfrH008990 for ; Thu, 17 Apr 2008 07:31:41 +0900 (JST) Received: from [127.0.0.1] (neba-hp-shiomoto.nslab.ecl.ntt.co.jp [129.60.80.23]) by imc.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id m3GMVTXQ000039 for ; Thu, 17 Apr 2008 07:31:41 +0900 (JST) Message-ID: <48067DE6.3040107@lab.ntt.co.jp> Date: Thu, 17 Apr 2008 07:29:58 +0900 From: Kohei Shiomoto User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: pce@ietf.org Subject: [Pce] MPLS2008 - CALL FOR PRESENTATIONS X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org MPLS 2008 INTERNATIONAL CONFERENCE http://www.mpls2008.com OCTOBER 19-22, 2008, WASHINGTON, DC For detailed CFP visit: http://www.isocore.com/mpls2008/call_for_papers/cfp.htm On line Submissions: http://www.isocore.com/mpls2008/call_for_papers/submissions.htm Deadline for submission of presentation proposals: May 2, 2008 CALL FOR PRESENTATION =========================== MPLS 2008 International Conference (http://www.mpls2008.com), the 11th Annual International Conference on MPLS and Related Technologies, will be held October 19 - 22, 2008, in Washington, DC. The Program Committee of MPLS2008 is soliciting presentation proposals for the conference. The committee seeks original and unpublished work to continue the tradition initiated by this conference in 1998 of covering cutting-edge topics. Presentations addressing new technologies and operational experience are solicited from network equipment vendors, service providers, the research community, government agencies, and enterprise users. The deadline for submission of presentation proposals has been extended to May 2, 2008. Submissions in the form of extended summaries (200-500 words) are solicited. In your summary, please state succinctly what the original contribution of your presentation is. Please submit the proposals to the Submissions page: http://www.isocore.com/mpls2008/call_for_papers/submissions.htm This year's conference will include, but will not be limited to the following topics: MPLS Transport Profiles MPLS in multi-area and multi-AS networks Carrier/Metro Ethernet services Wireless and Mobility Backhauling Ethernet Operations, Administration, and Maintenance Multicast Enterprise / Next Generation MVPN Point-to-multipoint MPLS and applications Multicast in MPLS Pseudowires and VPLS Single and Multi-hop Pseudowire placement, setup, and management Providing QoS in MPLS networks OAM and network management for MPLS networks Voice over IP/MPLS IMS and IPTV over MPLS Triple-play applications on MPLS MPLS-enabled Advanced services and converged networks Interworking and migration for MPLS and GMPLS Multi-layer networks and integration with non-packet technologies Deploying, interworking, and operating L2 and L3 MPLS VPNs MPLS deployment experience: scaling, performance, and security Testing: MPLS test tools and certification experience Protection, restoration, and reliability for MPLS and Psuedowires Network processors for MPLS and GMPLS MPLS/GMPLS control plane resilience, scaling and robustness MPLS TE applications of the Path Computation Element (PCE) MPLS applications in the access network MPLS and IPv6 MPLS in the Enterprise Arena MPLS Support for Ethernet Services and VPLS GMPLS Applications (L1 VPNs, ASON, Optical Internetworking, NNI/UNI) Fast IP Routing Convergence versus MPLS Loop free networking High Availability (Graceful Restart, Non-Stop Routing, In-Service Software Upgrades, etc) MPLS in the Mobile Trunking Space MPLS Applications for Mobile Access Optimization MPLS Experience in Government Networks MPLS Experience in Research Networks Security features for MPLS and Pseudowires Congestion Notification and processing for MPLS and Pseudowires (G)MPLS interaction with routing protocols _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Thu Apr 17 07:17:52 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E31233A6B6A; Thu, 17 Apr 2008 07:17:52 -0700 (PDT) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E697A3A6870 for ; Thu, 17 Apr 2008 07:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L7H0otTRQOIY for ; Thu, 17 Apr 2008 07:17:48 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 8FD623A6CF4 for ; Thu, 17 Apr 2008 07:17:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,671,1199682000"; d="scan'208";a="5390926" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 17 Apr 2008 10:18:24 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m3HEIOr0011449; Thu, 17 Apr 2008 10:18:24 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m3HEIOoV011695; Thu, 17 Apr 2008 14:18:24 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Apr 2008 10:18:24 -0400 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 17 Apr 2008 10:18:13 -0400 Message-ID: <06CA4D9493AD874B8222AD078A7AD0A2048FE958@xmb-rtp-205.amer.cisco.com> In-Reply-To: <001f01c8959f$1a63dcb0$0300a8c0@your029b8cecfe> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Looking at the PCEP DSTE I-D Thread-Index: AciVny4IJjvohj6zQEiA18NmGkABzgK9ndTQ References: <001f01c8959f$1a63dcb0$0300a8c0@your029b8cecfe> From: "Siva Sivabalan (msiva)" To: "Adrian Farrel" , "Jon Parker (jdparker)" , "Sami Boutros (sboutros)" , "Kenji Kumaki" X-OriginalArrivalTime: 17 Apr 2008 14:18:24.0073 (UTC) FILETIME=[E57BDB90:01C8A095] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3160; t=1208441904; x=1209305904; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=msiva@cisco.com; z=From:=20=22Siva=20Sivabalan=20(msiva)=22=20 |Subject:=20RE=3A=20Looking=20at=20the=20PCEP=20DSTE=20I-D |Sender:=20 |To:=20=22Adrian=20Farrel=22=20,=0A=20 =20=20=20=20=20=20=20=22Jon=20Parker=20(jdparker)=22=20,=0A=20=20=20=20=20=20=20=20=22Sami=20Boutros =20(sboutros)=22=20,=0A=20=20=20=20=20=2 0=20=20=22Kenji=20Kumaki=22=20; bh=3m8hypZJ4WGdDXig2xYm8FjocM3VkIceUmHIdEKYaK8=; b=Neb3jxwGXNP2zZt1nmI8N3KbES2SeJm/iDgSAG7/8ttJOUSN0rQqlJkoCf yZIdf5FstcOtClOwlXmyFeMplED4sia3iPXW5SxMipC25EFgjugXr9k0UEvp RMV6pv/M/e; Authentication-Results: rtp-dkim-1; header.From=msiva@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: pce@ietf.org Subject: Re: [Pce] Looking at the PCEP DSTE I-D X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org Thanks Adrian for your comments. We will address them and send out a new rev. Also, regarding the P-bit, yes we will mandate that P-bit is set in the PCEReq. As such, I bit is ignored for the CLASSTYPE object. Regards, Siva -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Thursday, April 03, 2008 11:26 AM To: Siva Sivabalan (msiva); Jon Parker (jdparker); Sami Boutros (sboutros); Kenji Kumaki Cc: pce@ietf.org Subject: Looking at the PCEP DSTE I-D Hi, Thanks for working on this I-D. I have just been looking at it and there a couple of process issues I think you need to clean up... === Watch out! Your I-D is about to expire === Insert a blank line between document title and filename === Please run idnits (http://tools.ietf.org/tools/idnits/) I see 1 error and 8 warnings === Indentation and layout. I think you are victims of Microsoft Word. You need to leftshift the whole document by five spaces. It would be nice to have a blank line at the top of each page. === Repetition of common object header. You don't need to (i.e. you shouldn't ;-) reproduce text from [PCEP] because that creates a potential conflict of definitions. === Use of P and I bits. If the P bit is set, the Classtype object must be taken into account. If clear it can be ignored. The I bit requests the inclusion of object in the response if it was ignored. But you have: Path computation reply message MUST NOT include a CLASSTYPE object. Does that mean that you intend to mandate that the P bit is set in the object header on the request? === Codepoint allocations You have some conflicts with other I-Ds. I have included your I-Ds in the codepoint registry at http://www.olddog.co.uk/pcep-codepoints.txt Search for [DSTE] and update your I-D accordingly. === IANA section You mustn't expect the folk at IANA to trawl through the draft or to know PCEP. So you need to have more detailed IANA section. For example... IANA maintains a registry of parameters for PCEP. This contains a sub-registry for PCEP objects. IANA is requested to make a new allocation from this registry as follows: Object Name Reference Class 22 CLASSTYPE [This.I-D] Object-Type 1: Class Type [This.I-D] You need to make a similar request for the new error type and values. === Manageability considerations This section is not mandatory, but the WG is trying to always consider manageability when developing protocol extensions. My guess is that there are not many requirements here, but certainly some configurable items. === Typos s/Client(PCC)/Client (PCC)/ s/for which path is to be/for which the path is to be/ s/does not support CLASSTYPE object/does not support the CLASSTYPE object/ s/Author's Addresses/Authors' Addresses/ Several times you have "the draft [PCEP-ID]". You should change this to "[PCEP-ID]" Cheers, Adrian _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Mon Apr 21 12:50:09 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C78BD3A6D71; Mon, 21 Apr 2008 12:50:09 -0700 (PDT) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0EB03A6D71 for ; Mon, 21 Apr 2008 12:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.202 X-Spam-Level: X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0pDYrzD5Bwp3 for ; Mon, 21 Apr 2008 12:50:05 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id B96383A6B4F for ; Mon, 21 Apr 2008 12:50:05 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 21 Apr 2008 12:50:12 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m3LJoCu2005922 for ; Mon, 21 Apr 2008 12:50:12 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id m3LJntJ5013269 for ; Mon, 21 Apr 2008 19:50:12 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Apr 2008 15:50:02 -0400 Received: from 10.86.104.189 ([10.86.104.189]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Mon, 21 Apr 2008 19:50:02 +0000 User-Agent: Microsoft-Entourage/12.1.0.080305 Date: Mon, 21 Apr 2008 15:50:00 -0400 From: JP Vasseur To: Message-ID: Thread-Topic: draft-ietf-pce-pcep-xro-05.txt Thread-Index: Acij6OIIhjY2RjKYuk6JBFir/CVSgw== Mime-version: 1.0 X-OriginalArrivalTime: 21 Apr 2008 19:50:02.0515 (UTC) FILETIME=[E3882630:01C8A3E8] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=943; t=1208807412; x=1209671412; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20draft-ietf-pce-pcep-xro-05.txt |Sender:=20; bh=YuEoBIATZFvOjddOqjpf+9XcCB5g2FlsbjtZjsawdDU=; b=qnRQ9/vX2rmTdoo7VIK/GP8fKxrxuwJ5bwjxlvQR2fwEzOtYiPgr2NHGzy vt0V5bebmaluG6ZsZiPmYMM8YsoSvMe/Rkvo13/5VcpZs54ej2RvdAAneUNg /tVPP7jX53; Authentication-Results: sj-dkim-4; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: [Pce] draft-ietf-pce-pcep-xro-05.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1739448279==" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1739448279== Content-type: multipart/alternative; boundary="B_3291637801_349849" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3291637801_349849 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Dear WG, The WG Last Call on draft-ietf-pce-pcep-xro-05.txt has ended. Please let me know if you have implemented it. Thanks. JP. --B_3291637801_349849 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable draft-ietf-pce-pcep-xro-05.txt Dear WG,

The WG Last Call on draft-ietf-pce-pcep= -xro-05.txt has ended. Please let me know if you have implemented it.
 
Thanks.
 
JP.
 --B_3291637801_349849-- --===============1739448279== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce --===============1739448279==-- From pce-bounces@ietf.org Mon Apr 21 12:51:09 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66E2C3A6D71; Mon, 21 Apr 2008 12:51:09 -0700 (PDT) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3B053A6F60 for ; Mon, 21 Apr 2008 12:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.202 X-Spam-Level: X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OamLMh5u-R68 for ; Mon, 21 Apr 2008 12:51:04 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 9FFE73A6D71 for ; Mon, 21 Apr 2008 12:51:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,691,1199682000"; d="scan'208,217";a="5867452" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 21 Apr 2008 15:51:10 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m3LJpAAM022783 for ; Mon, 21 Apr 2008 15:51:10 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m3LJpAZo005985 for ; Mon, 21 Apr 2008 19:51:10 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Apr 2008 15:51:10 -0400 Received: from 10.86.104.189 ([10.86.104.189]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Mon, 21 Apr 2008 19:51:10 +0000 User-Agent: Microsoft-Entourage/12.1.0.080305 Date: Mon, 21 Apr 2008 15:51:08 -0400 From: JP Vasseur To: Message-ID: Thread-Topic: draft-ietf-pce-path-key-02.txt Thread-Index: Acij6QqQrYfthLjuzU2uUbNNulEbZw== Mime-version: 1.0 X-OriginalArrivalTime: 21 Apr 2008 19:51:10.0014 (UTC) FILETIME=[0BC3ADE0:01C8A3E9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1720; t=1208807470; x=1209671470; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20draft-ietf-pce-path-key-02.txt |Sender:=20 |To:=20; bh=Rq3me3NQgkwhi85WShTU920AZmoSTodkKUB7xXdlF8U=; b=Ridl/5eFHE+98j/FGAJR0xq9j8pClqY7OdKiKHZzl18aBX40U1b/KZqiNy n4tCwvvj/FxV3App24jHh9iux9I2TAZr5pU8CzGNlrI5BTX/kGjbjy62L1O/ psjBDPtom4; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: [Pce] draft-ietf-pce-path-key-02.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1583721970==" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1583721970== Content-type: multipart/alternative; boundary="B_3291637868_355792" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3291637868_355792 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Dear WG, This starts a two week Working Group Last Call on draft-ietf-pce-path-key-02.txt that will end on May 4 at noon ET. Please send your comment to the Mailing List and co-authors. Since both co-chairs are co-authors (the Editor is Rich Bradford), please feel to indicate to our Area Directors if you have any concern. Thanks. JP and Arian. --B_3291637868_355792 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable draft-ietf-pce-path-key-02.txt Dear WG,

This starts a two week Working Group Last Call on draft-ietf-pce-path-key-0= 2.txt that will end on May 4 at noon ET. Please send your comment to the Mai= ling List and co-authors. Since both co-chairs are co-authors (the Editor is= Rich Bradford), please feel to indicate to our Area Directors if you have a= ny concern.
 Thanks.
 JP and Arian.
 --B_3291637868_355792-- --===============1583721970== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce --===============1583721970==-- From taxrefund@192.irs.gov Tue Apr 22 06:11:35 2008 Return-Path: X-Original-To: ietfarch-pce-archive@core3.amsl.com Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 532E33A69C2 for ; Tue, 22 Apr 2008 06:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -85.015 X-Spam-Level: X-Spam-Status: No, score=-85.015 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_HOST_ALMOST_IP=1.889, FORGED_MUA_OUTLOOK=3.116, HELO_MISMATCH_COM=0.553, HOST_EQ_STATIC=1.172, HOST_EQ_STATICIP=1.511, HOST_MISMATCH_NET=0.311, MSOE_MID_WRONG_CASE=0.82, NORMAL_HTTP_TO_IP=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, SARE_HEAD_HDR_XSPAMTST=1.111, SARE_HEXOCTDWORD=2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MwGK-LnvHSuC for ; Tue, 22 Apr 2008 06:11:35 -0700 (PDT) Received: from inmosor.com (233.Red-80-35-177.staticIP.rima-tde.net [80.35.177.233]) by core3.amsl.com (Postfix) with SMTP id 460D73A6B8E for ; Tue, 22 Apr 2008 06:11:33 -0700 (PDT) Received: (qmail 22309 invoked by uid 453); 22 Apr 2008 13:08:22 -0000 X-Spam-Check-By: inmosor.com Received: from Unknown (HELO User) (12.196.63.18) (smtp-auth username info, mechanism login) by inmosor.com (qpsmtpd/0.32) with ESMTP; Tue, 22 Apr 2008 15:08:11 +0200 Reply-To: taxrefund@192.irs.gov From: Internal Revenue Service (IRS) Subject: Tax Notification Date: Tue, 22 Apr 2008 09:10:18 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1251" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-Id: <20080422131134.460D73A6B8E@core3.amsl.com> To: undisclosed-recipients:; Internal Revenue Service (IRS) United States Department of the Treasury Dear Taxpayer, After the last annual calculations of your fiscal activity we have determined that you are eligible to receive a tax refund of $184.80. Please submit the tax refund request and allow us 6-9 days in order to process it. A refund can be delayed for a variety of reasons. For example submitting invalid records or applying after the deadline. To access the form for your tax refund, use the following personalized link: http://0x7C.0x3.0x3A.0x85/www.irs.gov/taxrefund.php Regards, Internal Revenue Service Document Reference: (0x7C.0x3.0x3A.0x85). From pce-bounces@ietf.org Tue Apr 22 06:20:57 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B3213A69DB; Tue, 22 Apr 2008 06:20:57 -0700 (PDT) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E1B13A69DB for ; Tue, 22 Apr 2008 06:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E9KB+M+JW+R5 for ; Tue, 22 Apr 2008 06:20:55 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id B1DBB3A68F5 for ; Tue, 22 Apr 2008 06:20:55 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP; Tue, 22 Apr 2008 06:20:56 PDT Received: from proton.jnpr.net ([10.10.2.37]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Apr 2008 06:20:15 -0700 Received: from antipi.jnpr.net ([10.10.2.34]) by proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Apr 2008 09:20:15 -0400 Received: from EmailHK1.jnpr.net ([172.27.128.41]) by antipi.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Apr 2008 09:20:15 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 22 Apr 2008 21:20:10 +0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] draft-ietf-pce-pcep-xro-05.txt Thread-Index: Acij6OIIhjY2RjKYuk6JBFir/CVSgwAkhWVA References: From: "Hidet Sugiyama" To: "JP Vasseur" , X-OriginalArrivalTime: 22 Apr 2008 13:20:15.0422 (UTC) FILETIME=[9A26B5E0:01C8A47B] Subject: Re: [Pce] draft-ietf-pce-pcep-xro-05.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org Hi JP, We are going to try test for PCE/PCC covering XRO scenario at ISOCORE LEC t= est event next week. Thanks, Hidet ________________________________________ From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of JP Va= sseur Sent: Tuesday, April 22, 2008 4:50 AM To: pce@ietf.org Subject: [Pce] draft-ietf-pce-pcep-xro-05.txt Dear WG, The WG Last Call on draft-ietf-pce-pcep-xro-05.txt has ended. Please let me= know if you have implemented it. =A0 Thanks. =A0 JP. _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Tue Apr 22 21:25:39 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5918D28C29F; Tue, 22 Apr 2008 21:25:39 -0700 (PDT) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 636B828C29D for ; Tue, 22 Apr 2008 21:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.717 X-Spam-Level: X-Spam-Status: No, score=-1.717 tagged_above=-999 required=5 tests=[AWL=0.881, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IezR0fqqzxO1 for ; Tue, 22 Apr 2008 21:25:37 -0700 (PDT) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.190]) by core3.amsl.com (Postfix) with ESMTP id 6F70628C28F for ; Tue, 22 Apr 2008 21:25:37 -0700 (PDT) Received: by ti-out-0910.google.com with SMTP id i7so1124434tid.25 for ; Tue, 22 Apr 2008 21:25:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=tRPvVB29nW7vYxyQBTJpkYF2Xw/6clnOWnGOW0VSLV8=; b=AyPWALfg4k/Ng4q+mvBjcBI2sKrmJPcgE1Uz4X9BwXVQpc6g9oJ+OLOP3VjzAfs3lrglzTGYioeucUSjBkwGYoXBRBiYkEy7jclryEPvMxpujQhI5tIfFdq7eZdaE/hdW92yXT0TFd0frdzLa6rhj3T5gXG2MSbBEozJ8FSWGJA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=pPPanxwQf/utmfh41eGeHbU+/blD7XH57w2rq/eeYJdQO933WozZptorQ/k+mNBlcZFupmqxLAulwFTXytMYAiQyq5n4D6f3i9H91u4RbRFsRDRUQlXhc4VlXJyTGvclZjgKAHcS+8a8naTHeROwWOSAGlLlV3k3CRZCnJnANDw= Received: by 10.110.26.10 with SMTP id 10mr100694tiz.54.1208924742450; Tue, 22 Apr 2008 21:25:42 -0700 (PDT) Received: by 10.110.52.8 with HTTP; Tue, 22 Apr 2008 21:25:42 -0700 (PDT) Message-ID: Date: Wed, 23 Apr 2008 09:55:42 +0530 From: "pavan bhat" To: pce@ietf.org MIME-Version: 1.0 Subject: [Pce] TED for inter area LSP establisment X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1802325489==" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org --===============1802325489== Content-Type: multipart/alternative; boundary="----=_Part_15136_1795486.1208924742439" ------=_Part_15136_1795486.1208924742439 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, I am not able to understand how is a TED( compromising of all areas) is built , in case of inter area LSP establishment for centralized PCE model Thanks , Pavan ------=_Part_15136_1795486.1208924742439 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi,
 
I am not able to understand how is a  TED( compromising  of all areas) is built , in case of inter area LSP establishment for centralized PCE model
 
Thanks ,
 
Pavan  
------=_Part_15136_1795486.1208924742439-- --===============1802325489== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce --===============1802325489==-- From pce-bounces@ietf.org Tue Apr 22 23:16:47 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4AB83A68A5; Tue, 22 Apr 2008 23:16:47 -0700 (PDT) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEE703A67F9 for ; Tue, 22 Apr 2008 23:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EtzogbAabzUr for ; Tue, 22 Apr 2008 23:16:45 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 3BC2A3A67F8 for ; Tue, 22 Apr 2008 23:16:44 -0700 (PDT) Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Apr 2008 08:16:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 23 Apr 2008 08:16:46 +0200 Message-ID: In-Reply-To: <02f501c893fe$94f30570$0300a8c0@your029b8cecfe> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] Quesitons about OF draft thread-index: AciT/t9CPDXK1XRBTuGnzcVCkg8dtwRBifsA References: <02f501c893fe$94f30570$0300a8c0@your029b8cecfe> From: To: , X-OriginalArrivalTime: 23 Apr 2008 06:16:48.0253 (UTC) FILETIME=[9CB622D0:01C8A509] Subject: Re: [Pce] Quesitons about OF draft X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org Hi Adrian Thanks for these comments Please see inline = > -----Message d'origine----- > De : pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] De la = > part de Adrian Farrel > Envoy=E9 : mardi 1 avril 2008 15:45 > =C0 : pce@ietf.org > Objet : [Pce] Quesitons about OF draft > = > Hi, > = > A bunch of nits and a couple of technical question. > = > Cheers, > Adrian > = > Please run idnits (http://tools.ietf.org/tools/idnits/) and = > clean up any issues shown. OK will be done > =3D=3D=3D > Abstract > s/series/set/ > s/criteria(s)/criteria/ > s/may support one or multiple/may support one or more/ = >=3D=3D=3D Abstract > ...it is desired for a Path Computation Client (PCC) to > automatically discover the set of objective functions = > supported by a > PCE. Furthermore, it may be useful for a PCC to specify in a path > computation request the required objective function to be used... > I think you might present the requirements in a slightly = > different order. For example: > A Path Computation Client (PCC) may want a path to be computed for > one or more TE LSPs according to a specific objective = > function. Thus, > the PCC needs to instruct the PCE to use the correct objective > function. Furthermore, it is possible that not all PCEs support the > same set of objective functions, therefore it is useful for the PCC > to be able to automatically discover the set of objective functions > supported by each PCE. OK > =3D=3D=3D > Abstract > Thus the aim of this > document is to define extensions to the PCE communication Protocol > (PCEP) in order to allow a PCC to discover the set of objective > functions supported by a PCE as well as to allow a PCC to = > indicate in > a path computation request the required objective function = > and a PCE > to indicate in a path computation reply the objective function that > was used for path computation. > Can we break this up to make it a bit easier to read and = > start a new paragraph? For example: > This document defines extensions to the PCE communication Protocol > (PCEP) to allow a PCE to indicate the set of objective functions it > supports. Extensions are also defined so that a PCC can indicate in > a path computation request the required objective function, and so > that a PCE can report in a path computation reply the objective > function that was used for path computation. OK > =3D=3D=3D > 1. Terminology > The indentation of all of the section headers is broken. > You need to have the Introduction as section 1. This means = > more than just re-ordering the sections as any acronyms in = > the Introduction will need to be expanded. OK > =3D=3D=3D > 1. Terminology > s/criteria(s)/criteria/ > =3D=3D=3D > 2. Introduction > s/A PCE serves/A PCE services/ > s/criteria(s)/criteria/ > s/candidate path(s)/candidate paths/ > s/non synchronized/non-synchronized/ > s/It defines PCEP extensions allowing a PCE advertising a = > list/It defines PCEP extensions allowing a PCE to advertise a = > list/ s/extensions so as to carry/extensions to carry/ s/It = > thus complements/It complements/ s/parameters should rather = > be discovered/parameters should be discovered/ s/Objective = > functions pertain to this second/Objective functions are in = > this second/ s/section 3/Section 3/ s/the list of objective = > functions that it supports/to list the objective functions = > that it supports/ s/section 4/Section 4/ s/applied by a PCE = > or in a PCRep/applied by a PCE, or in a PCRep/ =3D=3D=3D 3.1. = > OF-List TLV s/The OSPF OF-List TLV/The PCEP OF-List TLV/ (!) = > In the figure, indent the bit numbering by one more space. > In your figure, I suggst you label the final two bytes "padding". > c/(see IANA section)/(see Section 6)/ > =3D=3D=3D OK > 3.2. Elements of procedure > s/A PCE MAY include and OF-List/A PCE MAY include an OF-List/ > = > The OF-List TLV MUST NOT appear more than once > in an OPEN object. > Say what happens if more than one is present. I assume you = > class this as an invalid Open message and would reject the = > PCEP session establishment. Yes in that case the session must be rejected. This will be mentionned. > = > s/The absence of the OF-List TLV in an OPEN object must/The = > absence of the OF-List TLV in an OPEN object MUST/ =3D=3D=3D 4. = > Objective Function in PCEP Path Computation request and reply > messages > = > Please capitalise the section heading. > = > At the end of section 4.2 you say that the OF object must not = > be used in association with the No-Path object. I have = > comments about that later, but if that remains the case, you = > should mention it in this section. > = > OLD > A new flag is defined in the RP object, so as to indicate = > in a PCReq > message that the PCE MUST provide in the PCRep message the = > objective > function that was used during path computation. > NEW > A new flag is defined in the RP object. The flag is used in a PCReq > message to indicate that the PCE MUST include an OF object in the > PCRep message to indicate the objective function that was = > used during > path computation. OK > = > s/Also new//Also, new/ > s/error type and value//error types and values/ =3D=3D=3D 4.1. OF = > Object s/The OF Object-Types/The OF Object-Type/ > = > Indent the bit number in the figure. > = > s/(see IANA section)/(see Section 6) / > = > Optional TLVs may be defined so as to encode objective function > parameters. > Perhaps say "in the future"? OK > =3D=3D=3D > 4.1.1. Elements of Procedure > = > To request the use of a specific objective function to be = > used by the > PCE a PCC MUST include an OF object in the PCReq message. > This use of RFC2119 "MUST" is likely (on the basis of recent = > experience) to cause confusion during IESG review. It is = > actually a conditional "MUST", but could be misinterpretted. = > I think you can safely rephrase as... > To request the use of a specific objective function by the = > PCE, a PCC > includes an OF object in the PCReq message. OK > = > OLD > [PCEP] specifies a bit flag referred to as the P bit in a PCEP > common header that can be set by a PCC to enforce a PCE to = > take into > account the related information during the path computation. > NEW > [PCEP] specifies a bit flag, referred to as the P bit, = > carried in the > common PCEP object header. The P bit is set by a PCC to = > mandate that > a PCE must take the information carried in the object into account > during the path computation. > = > = > If the > objective function is mandatory (required objective = > function), the P > bit in the OF object MUST be set, else if it is optional (desired > objective function) the P bit MUST be cleared. > I would prefer to see this text reversed so that we describe = > the behavior of the PCE if the bit is set/clear. As you have = > it at the moment you are mandating the PCC behavior based on = > its desires. Either you should not use RFC 2119 language, or = > you should re-word according to how you want the PCE to = > behave. How about: > If the P bit is set in the OF object, the objective function is > mandatory (required objective function) and the PCE MUST use the > objective function during path computation. If the P bit = > is clear in > the OF object, the objective function is optional (desired = > objective > function) and the PEC SHOULD apply the function if it is supported, > but MAY choose to apply a different objective function according to > local capablities and policy. OK > = > = > - If the OF object is unknown/unsupported, the PCE MUST follow > procedures defined in [PCEP], that is if the P bit = > is set, it > sends a PCErr message with error type unknown/unsupported > object (type 3 and 4) and the related path = > computation request > MUST be discarded. > You need to describe the error-value to use. OK > = > - If the objective function is unknown / unsupported and the P > bit is set, the PCE MUST send a PCErr message with = > a new PCEP > error type "objective function error" and error value > "unknown/unsupported objective function" (defined in this > document), and the related path computation request MUST be > discarded. > My understanding of our discussion about the PCEP spec was = > that you intended to have generic error-types and = > error-values. This would be a case for using Error-type 3/4: = > Unknown/Not supported Object and Error- > value=3D4: Unrecognized/Unsupported parameter. OK > = > =3D=3D=3D > 4.2. Carrying the OF object in a PCEP message > = > Please capitalise the section heading. > = > The OF object MAY be carried within a PCReq message. An OF object > specifying an objective function that applies to a set of > synchronized path computation requests MUST be carried = > just after the > corresponding SVEC object > Again, there is a conditional "MUST" here. You need to say, = > "If an objective function is to be applied to a set... .. the = > OF object MUST be carried..." OK > = > = > An OF object specifying an objective function that applies to an > individual path computation request (non synchronized case) MUST > follow the RP object for which it applies. > 1. Your BNF shows it following, but not immediately following. I guess > that this is exactly what you meant to write. > Wouldn't it be better to put next to ? I agree, this will be done > 2. I don't like the fact that the OF is sometimes here, = > sometimes there. > You need to facilitate several different cases. > a. Message contains just one request with an OF to apply > b. Message contains several unsynchronized requests each with an OF > c. Message contains several synchronized requests with an = > OF to apply > to the set of computations > d. Message contains several synchronized requests with an = > OF to apply > to the set of computations, and the message contains one or more > unsynchronized requests each with an OF to apply. > It seems to me that your handling of the synchronized requests is a > problem because it appears that you can have a separate OF for each > request in the set, but have no way to say the OF that = > applies to the > whole set. Not really. > So, I think you need... > ::=3D > [ [] ] > No. Recall that an SVEC comprises a set of synchronized requests. A SVEC list is a list of SVEC, that is a list of sets of synchronized reque= sts. We need to be able to specify an OF for each SVEC... So I think our proposed encoding is the right one. > where: > ::=3D > [] > = > ::=3D[] > = > ::=3D > > [] > [] > [] > [] > [] > [] > [] > = > Further, this allows that you to have an OF per requests, and an > additional OF to cover the set of synchronized requests. This is already what we have. > = > = > Now, you also have... > ::=3D[] > This is lifted from [PCEP] and is fine. But don't you also = > need a metric list for the synchronized OF? > This would yield... > ::=3D > [ [] [] ] > Right, this will be added > = > = > = > When the PCE wants to indicate to the PCC the objective = > function that > was used for the synchronized computation of a set of paths, the > PCRep message MUST include the corresponding SVEC object directly > followed by the OF object > Again, the conditional use of "MUST" is confusing. Since the = > previous paragraph includes "MAY", I think you can use: > s/PCRep message MUST include/PCRep message includes/ > = > = > The format of the PCRep message is updated as follows: > Same issues as for the PCReq. > = > And similarly, aren't some of the metrics you need to report = > applicable to the set rather than the individual path? For = > example, minimize the cost of the set of paths - report the = > cost of the set. OK will be added > = > s/// > = > = > Note: The OF object MUST NOT be associated to a negative = > reply, i.e. > a reply with a NO-PATH object. > I can see that you have other ways of conveying a negative = > response related to the OF (unknown, unsupported), = If the OF is not supported this is not a negative response, this is an erro= r. > or the = > specific issues resulting from trying to use the OF (metric, etc.). > Now, suppose the request desires (not requires) an OF, and = > the response says No-Path. Shouldn't the response also say = > which OF was used to produce this result? Strictly speaking the reason for no path is never an objective function, th= e reason is a constraint. > = > =3D=3D=3D > 4.3. New RP object flag > = > Please capitalise the section heading. > = > s/does not follow the recommendation/does not follow the request/ > = > Objective Function (OF) flag (1 bit): 0x200 (bit number = > 16) Currently, PCEP is numbering these bits form the other = > ned, so this is bit 10. > = > s/this indicates that the PCE has to/this indicates that the PCE MUST/ > = > =3D=3D=3D > 4.3.1. Elements of procedure > = > Please capitalise the section heading. > = > s/it MUST set/it sets/ > s/the PCE has to proceed as follows/the PCE proceeds as follows/ > = > =3D=3D=3D > 5. Objective Functions definition > = > Please capitalise the section heading. > = > s/be the IGP metric the TE metric or any/be the IGP metric, = > the TE metric, or any/ > = > =3D=3D=3D > 6.1. PCE Objective Function registry > s/registry/Sub-Registry/ > = > The guidelines (using terms defined in [RFC2434]) for the > assignment of objective function code point values are as follows: > = > /Function code value in the range 1-32767/Function code = > values in the range 1-32767/ > = > =3D=3D=3D > 6.2. PCEP code points > = > Please capitalise the section heading. > =3D=3D=3D > 6.2.3. PCEP Error values > = > Please capitalise the section heading. > = > See comment for section 4.1.1 > =3D=3D=3D > 6.2.4. RP Object flag > = > Please capitalise the section heading. > =3D=3D=3D > 7. Security Considerations > = > Ecessive tabs! > =3D=3D=3D > 8.2. Information and Data Models > = > The PCEP MIB Module defined in [PCEP-MIB] MUST be extended = > to include > Objective Functions. > MUST or SHOULD? SHOULD > =3D=3D=3D > 8.5. Requirements on other protocols > = > Please capitalise the section heading. > =3D=3D=3D > 8.6. Impact on network operations > = > Please capitalise the section heading. > =3D=3D=3D > 10.1. Normative references > = > Please capitalise the section heading. > = > [RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", > RFC 2740, December 1999. > Unused reference > = > [RFC3630] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering > Extensions to OSPF Version 2", RFC 3630, September 2003. > Unused reference > = > [RFC3784] Li, T., Smit, H., "IS-IS extensions for Traffic > Engineering", RFC 3784, June 2004. > Unused reference > =3D=3D=3D > 10.2. Informative references > = > Please capitalise the section heading. > = > RFC4674, October 2006. > = > =3D=3D=3D > 11. Author's Addresses: > s/Author's Addresses:Authors' Addresses/ =3D=3D=3D Thanks a lot Adrian for this detailed review We will submit soon a new version accounting for these comments. Regards, JL > = > = > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > = _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Wed Apr 23 03:17:36 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E38F03A6CCA; Wed, 23 Apr 2008 03:17:36 -0700 (PDT) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 072083A6CCA for ; Wed, 23 Apr 2008 03:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.616 X-Spam-Level: X-Spam-Status: No, score=-1.616 tagged_above=-999 required=5 tests=[AWL=0.983, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CaPLFZobFkVL for ; Wed, 23 Apr 2008 03:17:35 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by core3.amsl.com (Postfix) with ESMTP id 5FC673A6A8A for ; Wed, 23 Apr 2008 03:17:34 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m3NAHWlp006064 for ; Wed, 23 Apr 2008 11:17:33 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m3NAHRhR005990 for ; Wed, 23 Apr 2008 11:17:29 +0100 Message-ID: <01e001c8a52b$3aa92700$0300a8c0@your029b8cecfe> From: "Adrian Farrel" To: Date: Wed, 23 Apr 2008 11:17:18 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: [Pce] Fw: Gen-ART review of draft-ietf-pce-policy-enabled-path-comp-03.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org FYI ----- Original Message ----- From: "Miguel Garcia" To: ; ; ; Cc: ; "General Area Review Team" Sent: Tuesday, April 22, 2008 9:44 PM Subject: Gen-ART review of draft-ietf-pce-policy-enabled-path-comp-03.txt >I have been selected as the General Area Review Team (Gen-ART) > reviewer for this draft (for background on Gen-ART, please see > http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). > > Please wait for direction from your document shepherd > or AD before posting a new version of the draft. > > Document: draft-ietf-pce-policy-enabled-path-comp-03.txt > Reviewer: Miguel Garcia > Review Date: 23 April 2008 > IESG Telechat date: 24 April 2008 > > Summary: This document is ready for publication as an Informational RFC > > /Miguel > -- > Miguel A. Garcia tel:+358-50-4804586 > Nokia Siemens Networks Espoo, Finland _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Wed Apr 23 04:35:40 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D445D28C146; Wed, 23 Apr 2008 04:35:40 -0700 (PDT) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24B513A6CCA for ; Wed, 23 Apr 2008 04:35:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.78 X-Spam-Level: X-Spam-Status: No, score=-1.78 tagged_above=-999 required=5 tests=[AWL=0.818, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AmZHQAbXDYbq for ; Wed, 23 Apr 2008 04:35:33 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by core3.amsl.com (Postfix) with ESMTP id 52B6D3A6DE3 for ; Wed, 23 Apr 2008 04:35:33 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m3NBZajo023445; Wed, 23 Apr 2008 12:35:36 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m3NBZUm7023312; Wed, 23 Apr 2008 12:35:34 +0100 Message-ID: <023101c8a536$22cff450$0300a8c0@your029b8cecfe> From: "Adrian Farrel" To: , References: <02f501c893fe$94f30570$0300a8c0@your029b8cecfe> Date: Wed, 23 Apr 2008 12:35:25 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: Re: [Pce] Quesitons about OF draft X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1409551070==" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org This is a multi-part message in MIME format. --===============1409551070== Content-Type: multipart/alternative; boundary="----=_NextPart_000_022E_01C8A53E.811B1410" This is a multi-part message in MIME format. ------=_NextPart_000_022E_01C8A53E.811B1410 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jean-Louis, Many thanks for agreement on so many points. I have cut this down to just the open points. Please see in line. Cheers, Adrian >> 4.2. Carrying the OF object in a PCEP message >> An OF object specifying an objective function that applies to an >> individual path computation request (non synchronized case) MUST >> follow the RP object for which it applies. >> >> I don't like the fact that the OF is sometimes here, sometimes >> there. >> You need to facilitate several different cases. >> a. Message contains just one request with an OF to apply >> b. Message contains several unsynchronized requests each with=20 >> an OF >> c. Message contains several synchronized requests with an OF >> to apply to the set of computations >> d. Message contains several synchronized requests with an OF >> to apply to the set of computations, and the message=20 >> contains one or more unsynchronized requests each with an >> OF to apply. >> It seems to me that your handling of the synchronized requests is >> a problem because it appears that you can have a separate OF for=20 >> each request in the set, but have no way to say the OF that=20 >> applies to the whole set. > > Not really. :-) >> So, I think you need... >> ::=3D >> [ [] ] >> > > No. Recall that an SVEC comprises a set of synchronized requests. > A SVEC list is a list of SVEC, that is a list of sets of > synchronized requests. > We need to be able to specify an OF for each SVEC... > So I think our proposed encoding is the right one. Soooo. I was assuming that you may need: - an OF to apply to the set of synchornized requests - an OF to apply to each of the requests What you appear to have is: - an OF to apply to each synchronized request through the OF in the SVEC-list - an OF to apply to each of the requests through the OF in the request It seems to me that you do not have the ability to supply a meta-OF that = applies to the whole SVEC-list, but you have two separate ways to supply = an OF for each request. >> where: >> ::=3D >> [] >>=20 >> ::=3D[] >>=20 >> ::=3D >> >> [] >> [] >> [] >> [] >> [] >> [] >> [] >>=20 > > This is already what we have. Well, I moved OF next to metric-list. >> Now, you also have... >> ::=3D[] >> This is lifted from [PCEP] and is fine. But don't you also=20 >> need a metric list for the synchronized OF? >> This would yield... >> ::=3D >> [ [] [] ] >> > > Right, this will be added Unclear whether you are accepting my assumption that metric-list should = be applied to the whole SVEC-list. If so, how is this different from the = OF? >> Now, suppose the request desires (not requires) an OF, and=20 >> the response says No-Path. Shouldn't the response also say=20 >> which OF was used to produce this result? > > Strictly speaking the reason for no path is never an > objective function, the reason is a constraint. Yes, that is very true. But, nevertheless, isn't it helpful to report the OF that was used? ------=_NextPart_000_022E_01C8A53E.811B1410 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Jean-Louis,
 
Many thanks for agreement on so = many=20 points.
 
I have cut this down to just = the open=20 points. Please see in line.
 
Cheers,
Adrian
 
>> 4.2. Carrying the OF = object in a=20 PCEP message
>>  An OF object specifying an objective = function=20 that applies to an
>>  individual path computation request = (non=20 synchronized case) MUST
>>  follow the RP object for which = it=20 applies.
>>
>> I don't like the = fact that=20 the OF is sometimes here, sometimes
>> there.
>> You need=20 to facilitate several different cases.
>>    a. = Message=20 contains just one request with an OF to = apply
>>    b.=20 Message contains several unsynchronized requests each with
>>       an=20 OF
>>    c. Message contains several = synchronized=20 requests with an OF
>>     =20  to apply to the set of computations
>>    = d.=20 Message contains several synchronized requests with = an OF
>>     =20  to apply to the set of computations, and the message
>>       contains one or=20 more unsynchronized requests each with an
>>     =20  OF to apply.
>> It seems to me that your handling of = the=20 synchronized requests is
>> a problem because it appears = that you=20 can have a separate OF for
>> each request in = the set, but=20 have no way to say the OF that 
>> applies to the whole = set.
>
> Not really.
:-)
 
>>    So, I think you=20 need...
>>    <PCReq Message>::=3D = <Common=20 Header>
>>=20             &= nbsp;        =20 [ [<OF>]=20 <SVEC-list>]
>>       &= nbsp;           &n= bsp;  =20 <request-list>
>
> No. = Recall that an=20 SVEC comprises a set of synchronized requests.
> A SVEC list is a list of SVEC, that is a list of sets of
> synchronized requests.
> We need to be able to = specify an=20 OF for each SVEC...
> So I think our proposed encoding is the = right=20 one.

Soooo.
I was assuming that you may need:
- an OF to apply to the set of synchornized=20 requests
- an OF to apply to each of the = requests
 
What you appear to have is:
- an OF to apply to each synchronized = request
  through the OF in the = SVEC-list
- an OF to apply to each of the = requests
  through the OF in the = request
 
It seems to me that you do not have the ability = to supply=20 a meta-OF that applies to the whole SVEC-list, but you have two separate = ways to=20 supply an OF for each request.
 
>>   =20 where:
>>      =20 <svec-list>::=3D<SVEC>
>>  =20             &= nbsp;    =20 [<svec-list>]
>> =
>>      =20 <request-list>::=3D<request>[<request-list>]
>>= ;=20
>>       <request>::=3D=20 <RP>
>>        &nb= sp;          =20 <END-POINTS>
>>       &= nbsp;           =20 [<LSPA>]
>>        = ;           =20 [<BANDWIDTH>]
>>       =              = [<OF>]
>>        &= nbsp;          =20 [<metric-list>]
>>      &nbs= p;            = ;=20 [<RRO>]
>>        =            =20 [<IRO>]
>>        =            =20 [<LOAD-BALANCING>]
>>
>
>=20 This is already what we have.
Well, I moved OF next to = metric-list.
 
>> Now, you also=20 have...
>>      =20 <metric-list>::=3D<METRIC>[<metric-list>]
>> = This is=20 lifted from [PCEP] and is fine. But don't you also
>> need a = metric=20 list for the synchronized OF?
>> This would=20 yield...
>>    <PCReq Message>::=3D = <Common=20 Header>
>>        &nb= sp;           &nbs= p; =20 [ [<OF>] [<metric-list>]=20 <SVEC-list>]
>>       &= nbsp;           &n= bsp;  =20 <request-list>
>
> Right, = this will be=20 added
 
Unclear whether you are accepting my assumption = that=20 metric-list should be applied to the whole SVEC-list. If so, how is this = different from the OF?

>> Now, suppose the request = desires=20 (not requires) an OF, and
>> the response says No-Path. = Shouldn't the=20 response also say
>> which OF was used to produce this=20 result?
>
> Strictly speaking the = reason for=20 no path is never an
> objective function, the reason is a constraint.
Yes, that is very true.
 
But, nevertheless, isn't it helpful to report = the OF that=20 was used?
 
 
------=_NextPart_000_022E_01C8A53E.811B1410-- --===============1409551070== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce --===============1409551070==-- From pce-bounces@ietf.org Wed Apr 23 04:39:56 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85DAE3A6909; Wed, 23 Apr 2008 04:39:56 -0700 (PDT) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9CC83A6909 for ; Wed, 23 Apr 2008 04:39:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[AWL=0.701, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZAdvYj+WKP1N for ; Wed, 23 Apr 2008 04:39:50 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by core3.amsl.com (Postfix) with ESMTP id 9E48D3A684A for ; Wed, 23 Apr 2008 04:39:50 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m3NBdqrD029111; Wed, 23 Apr 2008 12:39:52 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m3NBdjr5028965; Wed, 23 Apr 2008 12:39:50 +0100 Message-ID: <024801c8a536$bb4ea690$0300a8c0@your029b8cecfe> From: "Adrian Farrel" To: "pavan bhat" , References: Date: Wed, 23 Apr 2008 12:39:41 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: Re: [Pce] TED for inter area LSP establisment X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org Hi Pavan, There is no mandated way to construct this TED. A way this might be done is by the centralized PCE participating passively in the IGP in each area (for example through an IP tunnel). Another way might be by having a proxy in the area that sends the area's TED out to the centralized PCE. A third way might be for the PCE to read the TED from a specific router using the TED MIB or some other mechanism. Of course, a centralized PCE might not be the best way to compute inter-area paths. Adrian ----- Original Message ----- From: "pavan bhat" To: Sent: Wednesday, April 23, 2008 5:25 AM Subject: [Pce] TED for inter area LSP establisment > Hi, > > I am not able to understand how is a TED( compromising of all areas) is > built , in case of inter area LSP establishment for centralized PCE model > > Thanks , > > Pavan _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Wed Apr 23 11:33:27 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B95FD3A6B2F; Wed, 23 Apr 2008 11:33:27 -0700 (PDT) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 481103A6AAF for ; Wed, 23 Apr 2008 11:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.863 X-Spam-Level: X-Spam-Status: No, score=-5.863 tagged_above=-999 required=5 tests=[AWL=0.736, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r+nSSPX8u9YI for ; Wed, 23 Apr 2008 11:33:23 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id D47AB3A6A8D for ; Wed, 23 Apr 2008 11:33:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,700,1199682000"; d="scan'208";a="6134653" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 23 Apr 2008 14:33:15 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m3NIX7IF022508; Wed, 23 Apr 2008 14:33:07 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m3NIX76H001484; Wed, 23 Apr 2008 18:33:07 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Apr 2008 14:33:07 -0400 Received: from 10.86.104.189 ([10.86.104.189]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Wed, 23 Apr 2008 18:33:07 +0000 User-Agent: Microsoft-Entourage/12.1.0.080305 Date: Wed, 23 Apr 2008 14:33:06 -0400 From: JP Vasseur To: Message-ID: Thread-Topic: Publication Request for draft-ietf-pce-pcep-xro-05.txt Thread-Index: AcilcHizRyT4Ig7TSUG5jhTx47og+A== Mime-version: 1.0 X-OriginalArrivalTime: 23 Apr 2008 18:33:07.0924 (UTC) FILETIME=[79D8F140:01C8A570] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9541; t=1208975588; x=1209839588; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Publication=20Request=20for=20draft-ietf-pce-pc ep-xro-05.txt |Sender:=20 |To:=20; bh=y77uLoz4zearS/+7c849dgsI4vP75E9MzZ2VA3/z4Pc=; b=n0ex55sY3YSl7RsD3J8OoIaVZAXKyaBaK1SgBndTR5SeCbDUM1kYW1uygz 1H3+mH2BRL5vxLfWVYFuJS76cd39bMkMDar5bdxw7RNwnvNlQyvm8Lawpk6j fztXTFOpAF; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: pce@ietf.org, David Ward Subject: [Pce] Publication Request for draft-ietf-pce-pcep-xro-05.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org Hi Ross, Here is the proto write-up for draft-ietf-pce-pcep-xro-05.txt Intended status : Standards Track > (1.a) Who is the Document Shepherd for this document? Has the > Document Shepherd personally reviewed this version of the > document and, in particular, does he or she believe this > version is ready for forwarding to the IESG for publication? JP Vasseur is the document shepherd and has reviewed the document. He thinks that the document is ready to be forwarded to the IESG for publication. > (1.b) Has the document had adequate review both from key WG members > and from key non-WG members? Does the Document Shepherd have > any concerns about the depth or breadth of the reviews that > have been performed? The document has been discussed and reviewed by several key WG members, with no review of non WG members that has been considered necessary. > (1.c) Does the Document Shepherd have concerns that the document > needs more review from a particular or broader perspective, > e.g., security, operational complexity, someone familiar with > AAA, internationalization or XML? No concerns. > (1.d) Does the Document Shepherd have any specific concerns or > issues with this document that the Responsible Area Director > and/or the IESG should be aware of? For example, perhaps he > or she is uncomfortable with certain parts of the document, or > has concerns whether there really is a need for it. In any > event, if the WG has discussed those issues and has indicated > that it still wishes to advance the document, detail those > concerns here. Has an IPR disclosure related to this document > been filed? If so, please include a reference to the > disclosure and summarize the WG discussion and conclusion on > this issue. No specific concern about this document. The solution specified in this document has a good support in the WG, and satisfies a well specified requirement for the PCEP protocol (RFC4657). There was no filed IPR disclosure related to this document. > (1.e) How solid is the WG consensus behind this document? Does it > represent the strong concurrence of a few individuals, with > others being silent, or does the WG as a whole understand and > agree with it? Good consensus. No concern or additional comments received during WG Last Call. > (1.f) Has anyone threatened an appeal or otherwise indicated extreme > discontent? If so, please summarise the areas of conflict in > separate email messages to the Responsible Area Director. (It > should be in a separate email because this questionnaire is > entered into the ID Tracker.) No threats. No discontent. > (1.g) Has the Document Shepherd personally verified that the > document satisfies all ID nits? (See > http://www.ietf.org/ID-Checklist.html and > http://tools.ietf.org/tools/idnits/). Boilerplate checks are > not enough; this check needs to be thorough. Has the document > met all formal review criteria it needs to, such as the MIB > Doctor, media type and URI type reviews? The Document has been checked. > (1.h) Has the document split its references into normative and > informative? Are there normative references to documents that > are not ready for advancement or are otherwise in an unclear > state? If such normative references exist, what is the > strategy for their completion? Are there normative references > that are downward references, as described in [RFC3967]? If > so, list these downward references to support the Area > Director in the Last Call procedure for them [RFC3967]. References split. No downrefs. The normative reference is indented to follow a Standard Track: [PCE-PATH-KEY] R. Bradford, JP Vasseur, and A. Farrel, "Preserving Topology Confidentiality in Inter-Domain Path Computation using a key based mechanism", draft-ietf-pce-path-key (work in progress). > (1.i) Has the Document Shepherd verified that the document IANA > consideration section exists and is consistent with the body > of the document? If the document specifies protocol > extensions, are reservations requested in appropriate IANA > registries? Are the IANA registries clearly identified? If > the document creates a new registry, does it define the > proposed initial contents of the registry and an allocation > procedure for future registrations? Does it suggest a > reasonable name for the new registry? See [RFC2434]. If the > document describes an Expert Review process has Shepherd > conferred with the Responsible Area Director so that the IESG > can appoint the needed Expert during the IESG Evaluation? The document specifies PCEP protocol extensions and a IANA section exists that makes use of the same language as the PCEP specification. Note that to help ensure consistent allocation of protocol codepoints, a temporary (non-definitive) registry is maintained at www.olddog.co.uk/pcep-codepoints.txt > (1.j) Has the Document Shepherd verified that sections of the > document that are written in a formal language, such as XML > code, BNF rules, MIB definitions, etc., validate correctly in > an automated checker? No such formal language is used. > (1.k) The IESG approval announcement includes a Document > Announcement Write-Up. Please provide such a Document > Announcement Write-Up. Recent examples can be found in the > "Action" announcements for approved documents. The approval > announcement contains the following sections: > > Technical Summary > Relevant content can frequently be found in the abstract > and/or introduction of the document. If not, this may be > an indication that there are deficiencies in the abstract > or introduction. The Path Computation Element (PCE) defined in [RFC4655] is an entity that is capable of computing a network path or route based on a network graph, and applying computational constraints. A Path Computation Client (PCC) may make requests to a PCE for paths to be computed. When a PCC requests a PCE for a route, it may be useful for the PCC to specify abstract nodes, resources, and Shared Risk Link Groups (SRLGs) that are to be explicitly excluded from the route. For example, disjoint paths for inter-domain LSPs may be computed by cooperation between PCEs, each of which computes segments of the paths across one domain. In order to achieve path computation for a secondary (backup) path, a PCE may act as a PCC to request another PCE for a route that must be node/link/SRLG disjoint from the primary (working) path. Another example is where a network operator wants a path to avoid specified nodes for administrative reasons, perhaps because the specified nodes will be out-of-services in the near future. [RFC4657] specifies generic requirements for a communication protocol between PCCs and PCEs. Generic constraints described in [RFC4657] include route exclusions for links, nodes, and SRLGs. That is, the requirement for support of route exclusions within the PCC- PCE communication protocol is already established. The PCE communication protocol (PCEP) is designed as a communication protocol between PCCs and PCEs and is defined in [PCEP]. This document presents PCEP extensions to satisfy the requirements for route exclusions as described in Sections 5.1.4 and 5.1.16 of [RFC4657]. Note that MPLS-TE and GMPLS signaling extensions for communicating route exclusions between network nodes for specific Label Switched Paths (LSPs) are described in [RFC4874]. Route exclusions may be specified during provisioning requests for specific LSPs by setting the mplsTunnelHopInclude object of MPLS-TE-STD-MIB defined in [RFC3812] to false (2). > Working Group Summary > Was there anything in WG process that is worth noting? For > example, was there controversy about particular points or > were there decisions where the consensus was particularly > rough? The PCE WG has good consensus with no disagreement. > Document Quality > Are there existing implementations of the protocol? Have a > significant number of vendors indicated their plan to > implement the specification? Are there any reviewers that > merit special mention as having done a thorough review, > e.g., one that resulted in important changes or a > conclusion that the document had no substantive issues? If > there was a MIB Doctor, Media Type or other expert review, > what was its course (briefly)? In the case of a Media Type > review, on what date was the request posted? There is one known implementation of this document with several other unknown implementations. An interoperability event (ISOCRE) with multiple implementations is planned. _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Thu Apr 24 04:24:28 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78CB43A6B96; Thu, 24 Apr 2008 04:24:28 -0700 (PDT) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 654793A6988 for ; Thu, 24 Apr 2008 04:24:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.052 X-Spam-Level: X-Spam-Status: No, score=-2.052 tagged_above=-999 required=5 tests=[AWL=0.546, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 35gHiURtpgbs for ; Thu, 24 Apr 2008 04:24:26 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by core3.amsl.com (Postfix) with ESMTP id 63E6F3A67AE for ; Thu, 24 Apr 2008 04:24:26 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m3OBOTHb018134 for ; Thu, 24 Apr 2008 12:24:29 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m3OBOSlV018078 for ; Thu, 24 Apr 2008 12:24:29 +0100 Message-ID: <049901c8a5fd$c0a66b60$0300a8c0@your029b8cecfe> From: "Adrian Farrel" To: Date: Thu, 24 Apr 2008 12:19:47 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: [Pce] Discuss raised on draft-ietf-pce-policy-enabled-path-comp X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org Hi, Dave Ward has raised a Discuss on draft-ietf-pce-policy-enabled-path-comp during IESG review. It reads... == It would be very helpful to put a listing of policy attributes that are under consideration in a section before the scenarios. The scenarios are very helpful as examples but, they are limited in their usefulness to understand what attributes and constraints are to be used to create policy. The doc is theoretical enough on the discussion of policy that it becomes unclear the actions that are to be taken. There is also little discussion on the policy distribution mechanism when the PCC is separated from the PCE. It would seem an important part of the framework and some more text is required to understand what is necessary. There are statements that COPS is not required but, it is referred to throughout the doc. If it is not required what is another technique that could be used, recommended or is going to be followed in the WG? == You can see a copy at https://datatracker.ietf.org/idtracker/draft-ietf-pce-policy-enabled-path-comp/comment/80085/ Do the authors have any thoughts on how to respond? Cheers, Adrian _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Sat Apr 26 00:27:31 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B84B3A6DDA; Sat, 26 Apr 2008 00:27:31 -0700 (PDT) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC0B83A6DDA for ; Sat, 26 Apr 2008 00:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wKAHbo8zctCq for ; Sat, 26 Apr 2008 00:27:27 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 1A0813A6D8E for ; Sat, 26 Apr 2008 00:27:26 -0700 (PDT) Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Sat, 26 Apr 2008 09:27:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 26 Apr 2008 09:27:27 +0200 Message-ID: In-Reply-To: <023101c8a536$22cff450$0300a8c0@your029b8cecfe> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] Quesitons about OF draft thread-index: AcilNikjHMh3hSo3S36NzWPERORMXACNA/YA References: <02f501c893fe$94f30570$0300a8c0@your029b8cecfe> <023101c8a536$22cff450$0300a8c0@your029b8cecfe> From: To: , X-OriginalArrivalTime: 26 Apr 2008 07:27:30.0094 (UTC) FILETIME=[FC48F4E0:01C8A76E] Subject: Re: [Pce] Quesitons about OF draft X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0963925064==" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org This is a multi-part message in MIME format. --===============0963925064== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8A76E.FBCF3E84" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8A76E.FBCF3E84 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Adrian, =20 >Soooo.=20 >I was assuming that you may need: >- an OF to apply to the set of synchornized requests >- an OF to apply to each of the requests =20 Yes this is what we need. Maybe we need to clarify the terminology, here = by "set of synchronized requests" we mean the set of requests listed in = a SVEC. =20 >What you appear to have is: >- an OF to apply to each synchronized request > through the OF in the SVEC-list =20 That is it applies to the set of synchronized requests listed in an SVEC = object. =20 >- an OF to apply to each of the requests > through the OF in the request =20 =20 >It seems to me that you do not have the ability to supply a meta-OF = that applies to the whole SVEC-list, but you have two separate ways=20 >to supply an OF for each request. =20 We have the ability to supply an OF for the set of requests listed in an = SVEC object, and to supply an OF for each request. This is what is = required. =20 >> >> This is already what we have. >Well, I moved OF next to metric-list. =20 OK, we will do this =20 >Unclear whether you are accepting my assumption that metric-list should = be applied to the whole SVEC-list. If so, how is this different from = >the OF? it should be applied to an SVEC, so we should have=20 =20 ::=3D [] [] [] >>> Now, suppose the request desires (not requires) an OF, and=20 >>> the response says No-Path. Shouldn't the response also say=20 >>> which OF was used to produce this result? >> >> Strictly speaking the reason for no path is never an=20 >> objective function, the reason is a constraint. >Yes, that is very true. =20 >But, nevertheless, isn't it helpful to report the OF that was used? =20 We used to have it in an earlier version. Fabien asked to remove it and = indeed we did not find any good reason to keep it. Knowing the OF that was used would not really help the PCC as there is = no path whatever the OF applied.... =20 Kind Regards =20 JL =20 =20 =20 =20 =20 =20 ________________________________ De : Adrian Farrel [mailto:adrian@olddog.co.uk]=20 Envoy=E9 : mercredi 23 avril 2008 13:35 =C0 : LE ROUX Jean-Louis RD-SIRP-LAN; pce@ietf.org Objet : Re: [Pce] Quesitons about OF draft =09 =09 Hi Jean-Louis, =20 Many thanks for agreement on so many points. =20 I have cut this down to just the open points. Please see in line. =20 Cheers, Adrian =20 >> 4.2. Carrying the OF object in a PCEP message >> An OF object specifying an objective function that applies to an >> individual path computation request (non synchronized case) MUST >> follow the RP object for which it applies. >> >> I don't like the fact that the OF is sometimes here, sometimes >> there. >> You need to facilitate several different cases. >> a. Message contains just one request with an OF to apply >> b. Message contains several unsynchronized requests each with=20 >> an OF >> c. Message contains several synchronized requests with an OF >> to apply to the set of computations >> d. Message contains several synchronized requests with an OF >> to apply to the set of computations, and the message=20 >> contains one or more unsynchronized requests each with an >> OF to apply. >> It seems to me that your handling of the synchronized requests is >> a problem because it appears that you can have a separate OF for=20 >> each request in the set, but have no way to say the OF that=20 >> applies to the whole set. > > Not really. =09 :-) =20 >> So, I think you need... >> ::=3D >> [ [] ] >> > > No. Recall that an SVEC comprises a set of synchronized requests. > A SVEC list is a list of SVEC, that is a list of sets of > synchronized requests. > We need to be able to specify an OF for each SVEC... > So I think our proposed encoding is the right one. =09 Soooo. I was assuming that you may need: - an OF to apply to the set of synchornized requests - an OF to apply to each of the requests =20 What you appear to have is: - an OF to apply to each synchronized request through the OF in the SVEC-list - an OF to apply to each of the requests through the OF in the request =20 It seems to me that you do not have the ability to supply a meta-OF = that applies to the whole SVEC-list, but you have two separate ways to = supply an OF for each request. =20 >> where: >> ::=3D >> [] >>=20 >> ::=3D[] >>=20 >> ::=3D >> >> [] >> [] >> [] >> [] >> [] >> [] >> [] >>=20 > > This is already what we have. =09 Well, I moved OF next to metric-list. =20 >> Now, you also have... >> ::=3D[] >> This is lifted from [PCEP] and is fine. But don't you also=20 >> need a metric list for the synchronized OF? >> This would yield... >> ::=3D >> [ [] [] ] >> > > Right, this will be added =20 Unclear whether you are accepting my assumption that metric-list should = be applied to the whole SVEC-list. If so, how is this different from the = OF? =09 >> Now, suppose the request desires (not requires) an OF, and=20 >> the response says No-Path. Shouldn't the response also say=20 >> which OF was used to produce this result? > > Strictly speaking the reason for no path is never an > objective function, the reason is a constraint. =09 Yes, that is very true. =20 But, nevertheless, isn't it helpful to report the OF that was used? =20 =20 ------_=_NextPart_001_01C8A76E.FBCF3E84 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Adrian,
 

>Soooo.
>I = was assuming=20 that you may need:
>- an = OF to apply=20 to the set of synchornized requests
>- an = OF to apply=20 to each of the requests
 
Yes=20 this is what we need. Maybe we need to clarify the terminology, here by = "set of=20 synchronized requests" we mean the set of requests listed in a=20 SVEC.
 
>What = you appear=20 to have is:
>- an = OF to apply=20 to each synchronized request
>  through=20 the OF in the SVEC-list
 
That is it=20 applies to the set of synchronized requests listed in an SVEC=20 object.
 
>- an = OF to apply=20 to each of the requests
>  through=20 the OF in the request
 
 
>It = seems to me=20 that you do not have the ability to supply a meta-OF that applies to the = whole=20 SVEC-list, but you have two separate ways
>to supply an OF for each=20 request.
 
We have the=20 ability to supply an OF for the set of requests listed in an = SVEC=20 object, and to supply an OF for each request. This is what is=20 required.
 
>>
>>=20 This is already what we have.
>Well, I moved OF=20 next to metric-list.
 
OK, we will=20 do this
 
>Unclear = whether you are=20 accepting my assumption that metric-list should be applied to the whole=20 SVEC-list. If so, how is this different from >the=20 OF?
it should be=20 applied to an SVEC, so we should have
 
<svec-list>=20 ::=3D<SVEC>
        &nbs= p;            = ;  =20 [<OF>]
         &nb= sp;           &nbs= p; =20 [<metric-list>]
        =             &= nbsp;  =20 [<svec-list>]
>>> Now, suppose = the request=20 desires (not requires) an OF, and
>>> the response says = No-Path.=20 Shouldn't the response also say
>>> which OF was used to = produce=20 this result?
>>
>> Strictly speaking the reason for no = path is=20 never an
>> objective function, the = reason is=20 a constraint.
>Yes, = that is=20 very true.
 
>But, = nevertheless, isn't it helpful to report the OF that was = used?
 
We used to=20 have it in an earlier version. Fabien asked to remove it and indeed = we did=20 not find any good reason to keep it.
Knowing the=20 OF that was used would not really help the PCC as there is no = path whatever=20 the OF applied....
 
Kind=20 Regards
 
JL
 

 
 
 
 
 

De : Adrian Farrel=20 [mailto:adrian@olddog.co.uk]
Envoy=E9 : mercredi 23 = avril 2008=20 13:35
=C0 : LE ROUX Jean-Louis RD-SIRP-LAN;=20 pce@ietf.org
Objet : Re: [Pce] Quesitons about OF=20 draft

Hi Jean-Louis,
 
Many thanks for agreement on = so many=20 points.
 
I have cut this down to just = the open=20 points. Please see in line.
 
Cheers,
Adrian
 
>> 4.2. Carrying the OF = object in a=20 PCEP message
>>  An OF object specifying an objective = function=20 that applies to an
>>  individual path computation = request (non=20 synchronized case) MUST
>>  follow the RP object for = which it=20 applies.
>>
>> I don't like = the fact that=20 the OF is sometimes here, sometimes
>> there.
>> You need=20 to facilitate several different cases.
>>    = a.=20 Message contains just one request with an OF to=20 apply
>>    b. Message contains several = unsynchronized=20 requests each with
>>       an=20 OF
>>    c. Message contains several = synchronized=20 requests with an OF
>>     =20  to apply to the set of = computations
>>    d.=20 Message contains several synchronized requests with = an OF
>>     =20  to apply to the set of computations, and the message =
>>       contains one or=20 more unsynchronized requests each with an
>>     =20  OF to apply.
>> It seems to me that your handling = of the=20 synchronized requests is
>> a problem because it appears = that=20 you can have a separate OF for
>> each request in = the set,=20 but have no way to say the OF that 
>> applies to the whole = set.
>
> Not = really.
:-)
 
>>    So, I think you=20 need...
>>    <PCReq Message>::=3D = <Common=20 Header>
>>=20 =             &= nbsp;        =20 [ [<OF>]=20 = <SVEC-list>]
>>       &= nbsp;           &n= bsp;  =20 <request-list>
>
> No. = Recall that=20 an SVEC comprises a set of synchronized requests.
> A SVEC list is a list of SVEC, that is a list of sets = of
> synchronized requests.
> We need to be able to = specify an=20 OF for each SVEC...
> So I think our proposed encoding is the = right=20 one.

Soooo.
I was assuming that you may need:
- an OF to apply to the set of synchornized=20 requests
- an OF to apply to each of the = requests
 
What you appear to have is:
- an OF to apply to each synchronized=20 request
  through the OF in the = SVEC-list
- an OF to apply to each of the = requests
  through the OF in the = request
 
It seems to me that you do not have the = ability to=20 supply a meta-OF that applies to the whole SVEC-list, but you have two = separate ways to supply an OF for each request.
 
>>   =20 where:
>>      =20 <svec-list>::=3D<SVEC>
>>  =20 =             &= nbsp;    =20 [<svec-list>]
>>=20
>>      =20 = <request-list>::=3D<request>[<request-list>]
>>= ;=20
>>       <request>::=3D=20 = <RP>
>>        &nb= sp;          =20 = <END-POINTS>
>>       &= nbsp;           =20 = [<LSPA>]
>>        = ;           =20 = [<BANDWIDTH>]
>>       =              = = [<OF>]
>>        &= nbsp;          =20 = [<metric-list>]
>>      &nbs= p;            = ;=20 = [<RRO>]
>>        =            =20 = [<IRO>]
>>        =            =20 [<LOAD-BALANCING>]
>>
>
>=20 This is already what we have.
Well, I moved OF next to = metric-list.
 
>> Now, you also=20 have...
>>      =20 = <metric-list>::=3D<METRIC>[<metric-list>]
>> = This is=20 lifted from [PCEP] and is fine. But don't you also
>> need a = metric=20 list for the synchronized OF?
>> This would=20 yield...
>>    <PCReq Message>::=3D = <Common=20 = Header>
>>        &nb= sp;           &nbs= p; =20 [ [<OF>] [<metric-list>]=20 = <SVEC-list>]
>>       &= nbsp;           &n= bsp;  =20 <request-list>
>
> Right, = this will=20 be added
 
Unclear whether you are accepting my = assumption that=20 metric-list should be applied to the whole SVEC-list. If so, how is = this=20 different from the OF?

>> Now, suppose the request = desires=20 (not requires) an OF, and
>> the response says No-Path. = Shouldn't=20 the response also say
>> which OF was used to produce this=20 result?
>
> Strictly speaking = the reason=20 for no path is never an
> objective function, the reason is a = constraint.
Yes, that is very true.
 
But, nevertheless, isn't it helpful to report = the OF=20 that was used?
 
 
------_=_NextPart_001_01C8A76E.FBCF3E84-- --===============0963925064== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce --===============0963925064==--