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
