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 >> 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... >> <PCReq Message>::= <Common Header> >> [ [<OF>] <SVEC-list>] >> <request-list> > > 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: >> <svec-list>::=<SVEC> >> [<svec-list>] >> >> <request-list>::=<request>[<request-list>] >> >> <request>::= <RP> >> <END-POINTS> >> [<LSPA>] >> [<BANDWIDTH>] >> [<OF>] >> [<metric-list>] >> [<RRO>] >> [<IRO>] >> [<LOAD-BALANCING>] >> > > This is already what we have. Well, I moved OF next to metric-list. >> Now, you also have... >> <metric-list>::=<METRIC>[<metric-list>] >> This is lifted from [PCEP] and is fine. But don't you also >> need a metric list for the synchronized OF? >> This would yield... >> <PCReq Message>::= <Common Header> >> [ [<OF>] [<metric-list>] <SVEC-list>] >> <request-list> > > 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 >> 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, the reason is a constraint. Yes, that is very true. But, nevertheless, isn't it helpful to report the OF that was used?
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
