Hi Cyril,
Fine with what you say, but...
We did consider allowing the PCE to push unsolicited routes to the PCC. We
decided this was not actually the correct information or processing flow.
The point is that a "new route" is only available if a new computation is
performed. But the PCE only performs computations on demand. How would it
know that the network event should cause it to perform a new computation,
and how would it know whether the newly computed route was wanted by the
PCC.
However a third party tool (for example, the NMS, or the VNTM, depending on
the scenario) should be able to perform this function that is heavily
associated with local network and per-LSP policy. In these cases, it is the
management entity that is requesting path computations as the PCC, and it
will push those paths to the LER according to policy.
Of course, the LER could be the PCC and could request the paths, but it is
less likely to be in control of the necessary triggers. This behavior is
actually very similar to what you might expect for reoptimization.
Cheers,
Adrian
----- Original Message -----
From: "Margaria, Cyril (NSN - DE/Munich)" <[email protected]>
To: "Adrian Farrel" <[email protected]>; <[email protected]>;
<[email protected]>; <[email protected]>
Cc: <[email protected]>
Sent: Monday, October 19, 2009 1:39 PM
Subject: RE: [Pce] I-D Action:draft-bao-pce-pre-configured-routing-00.txt
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
