Hi,
> From: Meral Shirazipour <[EMAIL PROTECTED]> > Date: Tue, 01 Apr 2008 11:27:48 -0400 > To: Peng He <[EMAIL PROTECTED]> > Cc: "[email protected]" <[email protected]> > 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 >> <[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. > 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 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. > > >>>> 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. 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 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. > > 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. For sure and this is what BRPC says already. > 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. Thanks. JP. > >> 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 _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
