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". > > 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. 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), 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. And it is not a must for PCCs to know this also. Regards, Peng > > > 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
