[Pce] 答复: RE: I-D Action:draft-bao-pce-pre-configured-routing-00.txt

[Bao.Yuanlin at zte.com.cn]

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 unavailability
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)" <cyril.margaria at nsn.com>
写于 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: pce-bounces at ietf.org [mailto:pce-bounces at ietf.org] On Behalf
Of
> ext Adrian Farrel
> Sent: Monday, October 19, 2009 1:29 PM
> To: Bao.Yuanlin at zte.com.cn; fu.xihua at zte.com.cn; xie.gang at zte.com.cn
> Cc: pce at ietf.org
> 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
> Pce at ietf.org
> https://www.ietf.org/mailman/listinfo/pce
>