Hi Adrian,

 

Sorry I did not read the entire message in the previous response.

Here are comments for last few response.

 

-----Original Message-----
From: Adrian Farrel [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 24, 2006 11:02 AM
To: Lucy Yong
Cc: [EMAIL PROTECTED]
Subject: Re: Comments about draft-ietf-pce-architecture-05

 

Hi Lucy,

 

> The draft layouts the basic PCE architecture and expresses the motivation
> for a PCE-based architecture. It is a good document.

 

Thanks.


> Beyond these motivation facts, I think we should have another incentive for
> a PCE-based architecture.
>
> 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.

 

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".


> 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! :-)

 

> 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.

 

> 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.

 

> 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.

 

> Here is the recommendation for the PCE-based architecture:
>
>                       ---------------
>                      |   ---------   | Routing   ----------
>                      |  |         |  | Protocol |          |
>                      |  |   TED   |<-+----------+->        |
>                      |  |         |  |          |          |
>                      |   ---------   |          |          |
>                      |      |        |          |          |
>                      |      | Input  |          |          |
>                      |      v        |          |          |
>  ---------- Response |   ---------   |          |          |
> |          |Request  |  |         |  |          | Adjacent |
> |  SORD    |<------->|  |   PCE   |  |          |   Node   |
> |          |Input    |  |         |  |          |          |
>  ----------          |   ---------   |          |          |
>      ^               |      ^        |          |          |
>      |               |      |Request |          |          |
>      |               |      |Response|          |          |
>   Service Order      |      v        |          |          |
>                      |   ---------   |          |          |
>             Service  |  |         |  | Signaling|          |
>             Request  |  |Signaling|  | Protocol |          |
>                ------+->| Engine  |<-+----------+->        |
>                      |  |         |  |          |          |
>                      |   ---------   |           ----------
>                       ---------------
>

> Here, SORD is the service order reservation database, it contains all
> service order requests in terms of ingress and egress points, bandwidth,
> service type, time period for the request, etc. When PCE computes a path, it
> could get input from SORD to indicate if there are some network resource is
> already blocked out. When a booking order in SORD is ready to kick off, SORD
> will send request to PCE for the path computation, then PCE will send a
> service request to signaling engine to establish the LSP.

 

This would be hugely inefficient, wouldn't it?

Since PCE cannot guess which resources might be blocked out for future requests, it would have to make this query for every computation. Further, if PCE only made the query for resources that satisfied the computation, it might have to make repeated recomputations, so it would be more efficient for it to retrieve information about every future blocking.

So, in fact, it makes more sense for SORD to feed the information into the TED and allow PCE to operate on the full database.

 

But consider: How does SORD know which resources will be reserved and when? Presumably, it has consulted PCE as well.

 

Good point. Thus, even the result is saved in TED, it still needs to consulted PCE.

 

> It is clarified that not all pending orders in SORD need to reserve the
> bandwidth ahead, carrier could have some policies in SORD to manage which
> order need to reserve the bandwidth ahead and which is not.
>
> Be glad to hear your and other people comment on this suggestion.

If you wanted to work on some issue like "Applicability of PCE to time-scoped service requests" this might be of interest to people. It was raised in the early days of PCE and of L1VPN, but did not attract significant interest. I think that the feeling at the time was that it was out of scope for PCE, but formed part of a management system. However, it might be that there would be value in enhancing the PCE protocol to carry time delimiters for computation requests.

 

Note that the PCE working group is interested in applications of PCE and the protocols involved, but is not so interested in abstract functional components that are beyond the scope of the working group.

 

Thank you for the suggestion. Well understand the group interest now. We will think about the protocol enhancement.

 

 

Regards,

Adrian

_______________________________________________
Pce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pce

Reply via email to