Hi Cyril, Thanks for your comments.
If you find a better term to substitute the term "pre-configured route", please let me know. Anyone who is interested is welcomed to be a co-author. Since the main idea of this draft is to solve the potential problem of un availability of pre-configured routes, so I don't think it will be achieved by using the svec-list. Beause using svec with multi times can't provide the requested path is available when the primary path fails. There really exists a problem of request id of the PCRep, if you have any good idea, we can cooperate. PCC can be aware that the route failed and request a new Path computation for the failed path. However, this will make longer time delay of restoration process , since PCC needs to send PCReq and PCE needs to compute and send PCRep to PCC. This context doesn't define any new flag in the RP object, only a new flag in LSPA object. Best Regards, Yuanlin Bao "Margaria, Cyril (NSN - DE/Munich)" <[email protected]> 写于 2009-10-19 20:39:11: > Hi, > > I think the term pre-configured route is a bit misleading, I understand > the scenario as the PCC ask for 3 routes, the first one will be > signaled, the 2 other kept in case a failure happens on the first route. > > If I am not misunderstood this can be achieved by using the svec with 3 > time the same endpoints and bandwidth. > > Regarding the indication that a route has changed, the PCE could send a > PCRep with RRO (not allowed in rfc5440) and ERO containing the new Path, > but what should be the request id of the PCRep? > > In addition the PCC could also be aware that the route failed and > request a new Path computation for the failed path. > > In this context I do not see the need to have a new flag in the RP > object for this use case. > > > Best Regards > Cyril Margaria > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > ext Adrian Farrel > Sent: Monday, October 19, 2009 1:29 PM > To: [email protected]; [email protected]; [email protected] > Cc: [email protected] > Subject: Re: [Pce] I-D > Action:draft-bao-pce-pre-configured-routing-00.txt > > While this is a reasonably well-written draft, I don't see that it adds > anything to what we already have in the core RFCs. > > In section 4.3 you have... > > There are two options > for PCE to send pre-configured route as follows: > PCRep is used to respond route computation result naturally. If it > is used to send pre-configured route, a new flag SHOULD be defined to > indicate the route carried is pre-configured route. > > Two questions: > 1. What is the other option? You only list one option. > 2. Why do you need a flag to indicate that a route is pre- > configured? Why does the PCC care how the route was > derived? > > You slighlty answer question 2, in section 5.1 where you say... > > When PCC requests pre-configured route > > ...but why would the PCC ask for a pre-configured route? It just wants a > > route. If there is a policy to be applied by the PCE in selection of the > > route, this should be indicated using the normal policy functions. If > there > is an objective function/algorithm to be applied in selecting the route, > > this should be indicated using the OF object. > > So I think that you don't need the pre-configured route flag. > > Cheers, > Adrian > > _______________________________________________ > Pce mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/pce >
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
