Hi Lucy,
Sorry that I am a bit behind in this discussion. others may have jumped in
on some of these points already.
Today, a control plane based switching architecture assumes a
user-network
model or client-server model. A LSP is initiated at an end user point
(client), then network establishes the LSP thru. the control plane
instantly. PCE reserves that concept too. Thus all connection paths are
based on instant requests from end users.
I think it is true that PCE supports this model, but I don't think it is
the
case that the assumptions you state are universal.
1. The user-network model and the client-server model are examples
of
how one might use a control plane-based switching network, but they are
not
the only examples.
Accept this comment.
2. To say that all connection paths are based on instant requests from
end
users slightly misses the point of PCE. PCE performs computations based
on
requests from an external entity (the PCC), and PCE operates on a TED.
There
is nothing that says that the TED must be a representation of the network
at
only one instant of time, and there is nothing that says that the
computation request must demand a computation "now".
OK PCE does specify an instant request from end-user or NMS. TED defined
in
the draft contains the topology and resource information of the domain. It
is very unclear if it can sever bandwidth reservation purpose or not. In
addition, TED is not excluded to reside within network, which is hard to
use
this purpose.
That is clear. There are several architectural models defined. Not all
models are applicable to all usage scenarios. Part of the purpose of an
applicability statement is to define which models should be used for a
particular application.
In carrier reality world, it is hard to see that transport service will
be
offered this way only, especially for a large bandwidth and permanent
bandwidth request.
Hmmm. This may be why I disagreed with your assumptions! :-)
Maybe my words here are not clear to you. I means that it is hard to see
that transport service will be only offered in the way that an end user
sends a signal request at ingress point at the time that a bandwidth
needed.
Ah, *that* meaning of "instant" :-)
OK. Yes. Sometimes services will be planned ahead of time. This was
certainly in our minds as we wrote the architecture.
Typically, carrier has a service order reservation
system, it allows customer to book a bandwidth ahead (pending order),
carrier will do traffic engineering based on the pending order and will
excuse the order when the time arrives.
Yes, this is another valid model. But it is also not the only valid model
and many transport networks are operated today on a much more flexible
approach.
I agree. Does the architecture need to enable other approaches?
The architecture has to enable a variety of realistic approaches. It does
not need to document how they are achieved. That is the role of applicbility
statements.
A path computer engine has a
capability of taking a consideration about future pending orders while
it
computes a path.
I am unsure whether what you say matches reality perfectly.
That is, when a pending future order is entered into the system, the
reservation is made. This means that the TED reflects the results of the
order/computation/fulfilment cycle, and that computations are still
prefomred on demand (i.e. "now"). The difference is that the provisioning
(fulfilment) is some time in the future.
In this case, it seems unlikely that you would feed your TED from the
routing protocols, but rather from inventory discovery and from the
service
ordering/fulfilment process. Figure 5 in the architecture shows this
model.
That is the goal to feed TED from the routing protocols and let PCE use
TED
information and SORD information to compute the path. I think resource
inventory should come from network instead of human entering. Figure 5
show
NMS initiating the service request, but does not show the reservation
capability.
Whose goal do you describe?
You are already describing a time-based TED in which resources that are free
in the network are actually reserved at some point in the future.
I think our problem is the definition of TED. See my mail on this subject.
You mention that the architecture does not prohibit time-based
reservation.
But it does not explicitly support that either. It is hard to see through
it. If this is a valid function, could we explicitly specify it instead of
"imply it"? Maybe insert section 5.6 to illustrate this model.
It is not the architecture's job to explicitly support everything you might
want to do. In fact, it would be a long document if it tried to do that. it
is an architecture not a complete functional specification to cover all
eventualities. Again, in order to show the applicability of the architecture
to a scenario, we write applicability I-Ds.
That is my suggestion to expand the architecture including this scenario.
I understand your suggestion. I do not see the need. Perhaps the working
group will disagree with me.
This adds value for the PCE.
:-)
Will that mean that chairs get paid more?
The architecture is pretty close to the PCE-based
architecture except a lot of manual operation. I think PCE should
consider
this as its application too and revise the basic architecture to include
this functionality.
There is nothing (IMHO) in the current architecture that prohibits either
the management plane use of PCE, or the inclusion of a time dimension in
the
TED and the computaiton requests.
It seems that current TED definition does not serve this function.
Please show me the definition to which you refer.
Thanks,
Adrian
_______________________________________________
Pce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pce
