Hi, Very interesting indeed If I sum up all this, you are saying that we should make mandatory that the initiating domain specifies the complete domain sequence. I am arguing that this should be possible but not mandatory.
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 architecture to choose the best sequence of domains (by maybe just including the info on domains to include/exclude) 3- Having the PCEs 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 domain 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 resulting in the PCE architecture), I do not see why we should force such practice if having the PCEs choose the next domain in sequence does not necessarily give any worse 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 <<OR>> b- rely on an external entity (or any other means) to come up with the complete 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 <[EMAIL PROTECTED]>: > Interesting discussion, please see inline... > > On Tue, Apr 1, 2008 at 11:27 AM, Meral Shirazipour > <[EMAIL PROTECTED]> 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 > > > <[EMAIL PROTECTED]> 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 > details 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. > > > > > > 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 '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 > 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 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 described > 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 > > > > > <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>: > > > > > > > > > > > > > > > > > > > > > > > > > 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 ³discovered by some means² > 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 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) > > > > > > > > > > > > > > <ascii-art> > > > > > > > --------- > > > > > > > | AS-B | > > > > > > > --------- | | --------- > > > > > > > | AS-A |----| |----| AS-D | > > > > > > > | | | | | | > > > > > > > | PCC |----| |----| Egress | > > > > > > > | | --------- | | > > > > > > > | | | | | | > > > > > > > | | --------- | | > > > > > > > | |----| AS-C |----| | > > > > > > > | | | | | | > > > > > > > | |----| |----| | > > > > > > > --------- | | --------- > > > > > > > | | > > > > > > > --------- > > > > > > > </ascii-art> > > > > > > > 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 > > > > > > > [email protected] > > > > > > > https://www.ietf.org/mailman/listinfo/pce > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Pce mailing list > > > > > > [email protected] > > > > > > https://www.ietf.org/mailman/listinfo/pce > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
