Subject: [Pce] Comments about draft-ietf-pce-architecture-05

From: Lucy Yong <[email-masked]>
Date: Wed, 24 May 2006 10:06:46 -0500

Adrian,

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

 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.

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. 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. A path computer engine has a
capability of taking a consideration about future pending orders while it
computes a path. 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. 

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. 

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.

Regards,

Lucy Yong

Huawei Technologies, U.S.

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

---

From: Meral Shirazipour <[email-masked]>
Date: Wed, 24 May 2006 12:00:44 -0400

Lucy,
   I agree with what you say here. This is a fact to consider especially if the
PCE architecture is to be adapted later on for inter-AS TE in the ‘Internet’.
What you say here is important if we consider the Internet peering models.

Regards,
   Meral Shirazipour

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 24 May 2006 17:02:25 +0100

Hi Lucy,

> for a PCE-based architecture. It is a good document.

Thanks.

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

> bandwidth request.

Hmmm. This may be why I disagreed with your assumptions! :-)

> Typically, carrier has a service order reservation
> 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
> 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

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.

> |  SORD    |<------->|  |   PCE   |  |          |   Node   |
> |          |Input    |  |         |  |          |          |

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.

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

Regards,
Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 24 May 2006 17:10:51 +0100

Begging your pardon, Meral, but I'm a bit confused.

> PCE architecture is to be adapted later on for inter-AS TE in the 
> 'Internet'.

The architecture is already intended to be "adapted" for that purpose. Have 
a quick read through the first few sections and you'll see ample discussion 
of inter-AS.

Lucy's email seems to me to be about the time-based reservation of 
resources. This doesn't seem to me to be outside the scope of the current 
architecture, but one might want to write down how PCE is used for that 
purpose as an informational draft.

Personally, I would find Lucy's suggestion of a distinct component and 
database that was consulted for each computation request a costly idea, and 
would prefer to see this type of function rolled into a single database.

Adrian

---

From: [email-masked]
Date: Wed, 24 May 2006 18:11:45 +0200

i have one specific comment ... what i see progressively is that work item 

enters into the document of specific "architectures" ... while the role of
the working group is to - per charter -

The WG will specify a protocol for communication between LSRs (termed
Path Computation Clients - PCCs) and PCEs, and between cooperating 
PCEs

note: LSR = Label Switching Router

i start to have some concerns in building around a PC (functional) element 

a global network architecture with all related transactional user request 
and so forth... so i have a suggestion - summarize the message around 
section
5 and close this section by detailing areas of standardization 

Lucy Yong <[email-masked]>
24/05/2006 17:06
 
        To:     "'Adrian Farrel'" <[email-masked]>
        cc:     [email-masked]
        Subject:        [Pce] Comments about 
draft-ietf-pce-architecture-05

Adrian,
 
The draft layouts the basic PCE architecture and expresses the motivation 
for a PCE-based architecture. It is a good document.
 Beyond these motivation facts, I think we should have another incentive 
for a PCE-based architecture.

 
 
                       ---------------
|  SORD    |ß----à   |  |   PCE   |  |          |   Node   |
 
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. 

 
Regards,
Lucy Yong

---

From: Meral Shirazipour <[email-masked]>
Date: Wed, 24 May 2006 12:46:42 -0400

Dear Adrian,
   I apologize for the lack of clarity in my previous comment. I think Lucy has
a point. But I do not think the draft needs to me modified.
My comment on “the applicability of the PCE architecture in the Internet at
large” comes from the following lines in the Description of Working Group.
(http://www.ietf.org/html.charters/pce-charter.html).

I was referring to:
“The PCE WG will work on application of this model within a single
domain
or within a small group of domains (where a domain is a layer, IGP area
or Autonomous System with limited visibility from the head-end LSR).
At this time, applying this model to large groups of domains such as
the
Internet is not thought to be possible, and the PCE WG will not spend
energy on that topic.”

This said, I think if our ultimate goal is to do inter-AS TE and path
optimization in a PCE-based architecture, we must consider TED updating issues
and PCE signaling responsiveness while we are still at the definition stage of
the architecture and signaling protocols.

Best regards,
  Meral Shirazipour

---

From: Lucy Yong <[email-masked]>
Date: Wed, 24 May 2006 12:08:40 -0500

All,

Thank you for all the comments.
PCE should support time-base reservation in the general and leave as an
option for carrier to implement or not. If we exclude this functionality, it
is hard to see the full automatic network because there are quite these
kinds of service demands and carrier also encourages the pre-order so they
can proactively engineer the network.
I'll be glad to write an informational draft to explain the possible
mechanism and protocols. Weather the function should be maintained in the
same database or separated databases, it would be better to see after
clarifying the functionality of each element first, and then decide the
solution. The service reservation database mentioned here has a lot of
information that PCE does not need and has no responsibility to maintain
them.
Maybe some cache mechanism could be used.
Welcome anyone to provide the input on the informational draft.

Best Regards,
Lucy

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Wednesday, May 24, 2006 11:11 AM
To: Meral Shirazipour; Lucy Yong
Cc: [email-masked]
Subject: Re: [Pce] Comments about draft-ietf-pce-architecture-05

>   I agree with what you say here. This is a fact to consider especially if

Adrian

---

From: [email-masked]
Date: Wed, 24 May 2006 19:25:27 +0200

the question is why "time constraint" should be taken into account
during path computation that would justify incorporation into the
communication between LSR-PCE/PCE-PCE elements 

scheduling of LSPs - themselves - is outside the scope of the comm
process between LSR-PCE/PCE-PCE elements, it is even outside the
scope of the PCE (since not a resource manager of some sort)

24/05/2006 19:08
 
        To:     "'Adrian Farrel'" <[email-masked]>, "'Meral 
Shirazipour'" <[email-masked]>
        cc:     [email-masked]
        Subject:        RE: [Pce] Comments about 
draft-ietf-pce-architecture-05

All,

option for carrier to implement or not. If we exclude this functionality, 
it

Best Regards,
Lucy

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Wednesday, May 24, 2006 11:11 AM
To: Meral Shirazipour; Lucy Yong
Cc: [email-masked]
Subject: Re: [Pce] Comments about draft-ietf-pce-architecture-05

> What you say here is important if we consider the Internet peering 
models.

The architecture is already intended to be "adapted" for that purpose. 
Have 
a quick read through the first few sections and you'll see ample 
discussion 
of inter-AS.

Personally, I would find Lucy's suggestion of a distinct component and 
database that was consulted for each computation request a costly idea, 
and 
would prefer to see this type of function rolled into a single database.

Adrian

---

From: Lucy Yong <[email-masked]>
Date: Wed, 24 May 2006 12:26:16 -0500

Meral,

PCE group is formed recently. If this is out of charter scope, it may be
added on if this is really valuable function. As Adrian mentions that the
basic architecture scope already 'adapt' this functionality, but seems it is
clear how PCE performs this function yet.
We are researching some advanced intelligent network to accomplish
intelligent automatic LSP establish and tear down. If the reservation
functionality is scoped out because of network size, I don't think that is
proper. 
See more below.

Regards,
Lucy

-----Original Message-----
From: Meral Shirazipour [mailto:[email-masked]] 
Sent: Wednesday, May 24, 2006 11:47 AM
To: Adrian Farrel
Cc: Lucy Yong; [email-masked]
Subject: Re: [Pce] Comments about draft-ietf-pce-architecture-05

Dear Adrian,
   I apologize for the lack of clarity in my previous comment. I think Lucy
has
a point. But I do not think the draft needs to me modified.
My comment on "the applicability of the PCE architecture in the Internet at
large" comes from the following lines in the Description of Working Group.
(http://www.ietf.org/html.charters/pce-charter.html).

I was referring to:
"The PCE WG will work on application of this model within a single
domain
energy on that topic."

This said, I think if our ultimate goal is to do inter-AS TE and path
optimization in a PCE-based architecture, we must consider TED updating
issues
and PCE signaling responsiveness while we are still at the definition stage
of
the architecture and signaling protocols.

Lucy: I don't see the conflict here. WG should study all these issues.
However, these should not prevent from studying time-based reservation
either, especially in the architecture design stage.

Best regards,
  Meral Shirazipour

---

From: Lucy Yong <[email-masked]>
Date: Wed, 24 May 2006 12:33:15 -0500

Dimitri,

Because for some important reservations, carrier want to reserve the
specific path for many purposes such as better optimization, request length
period, service guarantee, etc.

Why should PCE WG limits the scope between LSR-PCE/PCE-PCE elements? We are
defining the architecture now.

Adrian has mentioned that it is in PCE scope.

Regards,
Lucy

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] 
Sent: Wednesday, May 24, 2006 12:25 PM
To: Lucy Yong
Cc: 'Adrian Farrel'; 'Meral Shirazipour'; [email-masked]
Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05

 

All,

Best Regards,
Lucy

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Wednesday, May 24, 2006 11:11 AM
To: Meral Shirazipour; Lucy Yong
Cc: [email-masked]
Subject: Re: [Pce] Comments about draft-ietf-pce-architecture-05

Adrian

---

From: [email-masked]
Date: Wed, 24 May 2006 19:49:24 +0200

lucy - 

take a look at 
<http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol-gen-reqs-06.txt> 
section 6.16,

if there is a need to consider - as you wrote - that "PCE should support 
time-base reservation in the general 
and leave as an option for carrier to implement or not." i would like to 
hear from operators specific rationales 
to incorporate as part of the communication protocol / PCE processing any 
time constraint

now more fundamentally and as stated the role of the group is to define IP 
communication protocols not network
architectures of some sort - reason for the suggestion made on section 5

adrian mentions what is that inter-AS PCE is in scope, he forgot probably 
to mention to you that the primary 
concerns of the work ongoing here is driven by four major concerns: 
scalability, performance, robustness and
resiliency from this perspective any time constraint is going to seriously 
impact all these base objectives

24/05/2006 19:33
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     "'Adrian Farrel'" <[email-masked]>, "'Meral 
Shirazipour'" <[email-masked]>, [email-masked]
        Subject:        RE: [Pce] Comments about 
draft-ietf-pce-architecture-05

Dimitri,

Because for some important reservations, carrier want to reserve the
specific path for many purposes such as better optimization, request 
length
period, service guarantee, etc.

Why should PCE WG limits the scope between LSR-PCE/PCE-PCE elements? We 
are
defining the architecture now.

Regards,
Lucy

-----Original Message-----

 

All,

Best Regards,
Lucy

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Wednesday, May 24, 2006 11:11 AM
To: Meral Shirazipour; Lucy Yong
Cc: [email-masked]
Subject: Re: [Pce] Comments about draft-ietf-pce-architecture-05

Adrian

---

From: Lucy Yong <[email-masked]>
Date: Wed, 24 May 2006 13:54:25 -0500

Hi Adrian,

First of all, highly appreciate your all great comments. See my comment
below.

Regards,

Lucy

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

Hi Lucy,

Thanks.

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

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.

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

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.

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. 

That is my suggestion to expand the architecture including this scenario.
This adds value for the PCE.

> this as its application too and revise the basic architecture to include

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.

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.

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

Regards,

Adrian

---

From: Lucy Yong <[email-masked]>
Date: Wed, 24 May 2006 14:10:38 -0500

Hi Dimitri,

Thank you for the comments. It is understood that the group goal is to study
IP communication protocols not network architecture. However, they can not
be completely separated. Before we are clear about the architecture and its
components, we can't really specify the protocol, do we?
The suggestion here is to add another architecture scenario which enables to
support time-based reservation. I don't see this impact the protocol study.
It simply adds a value for PCE based architecture.
If we only study the protocols between LSR-PCE and PCE-PCE, adding this
scenario does not add addition work at all.  I don't see how this scenario
impacts the scalability, performance, robustness and resiliency at all. If
it is, it is scared what we are doing here.

Regards,
Lucy

-----Original Message-----
Sent: Wednesday, May 24, 2006 12:49 PM

lucy - 

take a look at 
<http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol-gen-reqs-0
6.txt> 
section 6.16,

 

Dimitri,

Regards,
Lucy

-----Original Message-----

 

All,

Best Regards,
Lucy

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Wednesday, May 24, 2006 11:11 AM
To: Meral Shirazipour; Lucy Yong
Cc: [email-masked]
Subject: Re: [Pce] Comments about draft-ietf-pce-architecture-05

Adrian

---

From: JP Vasseur <[email-masked]>
Date: Wed, 24 May 2006 15:24:48 -0400

Hi Lucy,

Comments in line,

On May 24, 2006, at 2:54 PM, Lucy Yong wrote:

> Hi Adrian,
>
>
> First of all, highly appreciate your all great comments. See my  
> comment below.
>
>
> Regards,
>
> Lucy
>
>
> 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".
As already pointed out by Adrian, the PCE does not preclude this  
"instant per-user" model ... but from a realistic point of view, it  
is unlikely to be the most common application case. You may want to  
have a closer look at several of the requirement documents that do  
describe various applications contexts such as Inter-area, Inter-AS  
and Inter-layer MPLS TE. Such applications will likely be described  
in more details in future applicability statement.

The PCE Architecture ID specifies the components, their interaction  
in term of protocols and so on. If you want to use it in a per-user  
real-time fashion, this is not precluded but again I would express  
some serious concerns about the scalability.
> OK PCE does specify an instant request from end-user or NMS.
Not sure what you mean by "instant" request. The trigger for a path  
computation request are out of the standardization scope.
> TED defined in the draft contains the topology and resource  
> information of the domain.
Note that we do not change the definition of the TED.
> It is very unclear if it can sever bandwidth reservation purpose or  
> not.
The PCE does not *reserve* bandwidth, but computes paths for TE LSP.  
Bandwidth reservation is performed by RSVP-TE (RFC 3209).
> In addition, TED is not excluded to reside within network, which is  
> hard to use this purpose.
>
>
> 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.
There is no such assumption in the architecture.
> 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.
>

It does.
> 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.
>
>
> 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.
>
> That is my suggestion to expand the architecture including this  
> scenario. This adds value for the PCE.
So you might want to consider producing an applicability statement ID  
but this does not require any change to the architecture document.

> 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.
>
>
> 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.
>
>
> 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.
In full sync with Adrian.

JP.

---

From: "Payam Torab" <[email-masked]>
Date: Wed, 24 May 2006 15:31:17 -0400

Lucy-

What do you mean by "architecture scenario" below? I don't see any conflict
between the current PCE architecture, and adding an element of time to path
computation. You can certainly add time constraints to TED, as well as
computation algorithms and support scheduling if you wish.

You mention "It seems that current TED definition does not serve this
function (scheduling)" - How is TED definition blocking you from scheduling?

Thanks,
Payam Torab

> From: Lucy Yong [mailto:[email-masked]] 
> Sent: Wednesday, May 24, 2006 3:11 PM
> To: [email-masked]
> Cc: [email-masked]
> Thank you for the comments. It is understood that the group 
> goal is to study IP communication protocols not network 
> architecture. However, they can not be completely separated. 
> Before we are clear about the architecture and its 
> components, we can't really specify the protocol, do we? The 
> suggestion here is to add another architecture scenario which 
> enables to support time-based reservation. I don't see this 
> impact the protocol study. It simply adds a value for PCE 
> based architecture. If we only study the protocols between 
> LSR-PCE and PCE-PCE, adding this scenario does not add 
> addition work at all.  I don't see how this scenario impacts 
> the scalability, performance, robustness and resiliency at 
> all. If it is, it is scared what we are doing here.
> 
> Regards,
> Lucy
> 
> 
> Because for some important reservations, carrier want to 
> reserve the specific path for many purposes such as better 
> optimization, request 
> length
> the question is why "time constraint" should be taken into 
> account during path computation that would justify 
> incorporation into the communication between LSR-PCE/PCE-PCE elements 
> 
> scheduling of LSPs - themselves - is outside the scope of the 
> comm process between LSR-PCE/PCE-PCE elements, it is even 
> outside the scope of the PCE (since not a resource manager of 
> some sort)
> 
> 
> 
> 
> 
> PCE should support time-base reservation in the general and 
> leave as an option for carrier to implement or not. If we 
> exclude this functionality, 
> it
> is hard to see the full automatic network because there are 
> quite these kinds of service demands and carrier also 
> encourages the pre-order so they can proactively engineer the 
> network. I'll be glad to write an informational draft to 
> explain the possible mechanism and protocols. Weather the 
> function should be maintained in the same database or 
> separated databases, it would be better to see after 
> clarifying the functionality of each element first, and then 
> decide the solution. The service reservation database 
> mentioned here has a lot of information that PCE does not 
> need and has no responsibility to maintain them. Maybe some 
> cache mechanism could be used. Welcome anyone to provide the 
> input on the informational draft.
> 
> Best Regards,
> Lucy
> 
> >   I agree with what you say here. This is a fact to consider 
> > especially
> if
> 
> > the

---

From: JP Vasseur <[email-masked]>
Date: Wed, 24 May 2006 15:34:33 -0400

Hi Lucy,

On May 24, 2006, at 3:10 PM, Lucy Yong wrote:

> support time-based reservation.

But again there's nothing that prevents you from applying your  
application using the defined PCE architecture. I think that you made  
some assumptions about the applicability of the PCE architecture that  
are not valid. Hope that these emails have clarified this.

> I don't see this impact the protocol study.
> scenario does not add addition work at all.

Note that there is one communication protocol between PCC-PCE and PCE- 
PCE.

> I don't see how this scenario
> impacts the scalability, performance, robustness and resiliency at  
> all.

I personally think that it does, as pointed out by Dimitri.

In summary:
(1) The Architecture ID does not preclude the scenario that you  
describe,
(2) We are very welcome to document such application model in an  
applicability ID to gather input from the list.

Thanks.

JP.

> If

---

From: JP Vasseur <[email-masked]>
Date: Wed, 24 May 2006 15:50:36 -0400

Hi Meral,

> the architecture and signaling protocols.

Both items are indeed important.

TED update: do you see any reason to change the way the TED is  
updated by the IGP in a PCE context ?
Note that so called "distributed CSPF approach" is a specific  
instantiation of the PCE (LSR and PCE co-resident).

PCEP communication responsiveness: this is an key metric indeed that  
is been considered during the protocol design (in line with the  
requirement IDs). Note also that there's a WG item related to  
"Objective metrics" for which several expressed some interest. We can  
expect some work to be done in this area and you're obviously very  
welcome to contribute.

- Definition of objective metrics to evaluate various criteria such as
the measurement of path quality, response time, robustness and
scalability of path computation models.

Thanks.

JP.

---

From: Lucy Yong <[email-masked]>
Date: Wed, 24 May 2006 15:48:34 -0500

Payam,

The draft specifies five architecture scenarios. Suggest adding one for
time-based reservation. Giving the definition of TED, I don't see it can
serve that function properly.
TED contains topology and resource information from network. It may be
embedded in NE. It is good to have a place to hold real network information
and another place hold all reservations. You can flexibly apply policy to
manage which bandwidth need to reserve ahead and which is only a book. It is
hard to see the implementation done in TED.

Lucy

-----Original Message-----
From: Payam Torab [mailto:[email-masked]] 
Sent: Wednesday, May 24, 2006 2:31 PM
To: 'Lucy Yong'; [email-masked]
Cc: [email-masked]
Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05

Lucy-

Thanks,
Payam Torab

---

From: Lucy Yong <[email-masked]>
Date: Wed, 24 May 2006 16:01:41 -0500

JP,

I did not say the architecture prevent from time-based reservation. To be
clarify here. Actually, I see that the architecture could be explicitly
extended to support the application and be mentioned as one value for PCE
based implementation compared to current router based implementation. The
gap is you think that should be done in the TED and is out of scope of PCE.
I think that, as we promote this basic architecture, it is good to mention
the architecture also enable this kind of application and provide possible
architecture scenario. Again, this does not impact the protocol
implementation scoped here.

Lucy 

-----Original Message-----
From: JP Vasseur [mailto:[email-masked]] 
Sent: Wednesday, May 24, 2006 2:35 PM
To: Lucy Yong
Cc: [email-masked]; [email-masked]
Subject: Re: [Pce] Comments about draft-ietf-pce-architecture-05

Hi Lucy,

In summary:

Thanks.

JP.

---

From: Lucy Yong <[email-masked]>
Date: Wed, 24 May 2006 16:18:44 -0500

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-masked]] 
Sent: Wednesday, May 24, 2006 11:02 AM
To: Lucy Yong
Cc: [email-masked]
Subject: Re: Comments about draft-ietf-pce-architecture-05

Hi Lucy,

Thanks.

for

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.

it

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

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

Regards,

Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 24 May 2006 22:34:04 +0100

Hi Lucy,

I think that some of the confusion may be coming from the definition of TED.

In the architecture I-D we have
   TED: Traffic Engineering Database which contains the topology and
   resource information of the domain. The TED may be fed by IGP
   extensions or potentially by other means.
and also
   ...a PCE would
   be able to compute the path of a TE LSP by operating on the TED and
   considering bandwidth and other constraints applicable to the TE LSP
   service request.

This gives us the somewhat circular definition that the TED is the database 
on which PCE operates to compute TE paths. You might think that this TED is 
exactly the database of TE information advertised by an IGP, and that would 
be an entirely reasonable implementation, but the architecture and 
definitions deliberately allow the TED to be supplemented from other 
sources, or even created entirely from other sources.

Regards,
Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 24 May 2006 22:41:01 +0100

Lucy,

Just to clarify:

If you plan to propose a change in the architecture, we will (of course) 
discuss this with you. But I would not expect the working group to be very 
sympathetic having just completed work on the architecture, taken it through 
working group last call, and negotiated through a rather thorough IESG 
review.

If you plan to write an informational I-D to show the requirements for 
time-based path computation, to show how the existing architecture meets the 
needs, and to propose requirements for extensions to existing protocols, 
this would be fine. From a working group perspective, this is getting a 
little ahead of ourselves (we have to complete the basic work first, and I 
hope you will contribute to advance this work), but it is a worthwhile 
activity to start if:
- you want to prove that it can be done with the existing tools
- you are willing to watch your draft progress slowly until
  other pieces of work have been done.

It is possible that as you progress with the second option you may find 
yourself drawn to the first option. In this case i would suggest that you 
step back from the solutions work and focus only on the requirements work. 
Then you can consult with others in the working group about how to meet your 
requirements using the existing toolset.

Regards,
Adrian

----- Original Message ----- 
From: "Lucy Yong" <[email-masked]>
To: "'Adrian Farrel'" <[email-masked]>; "'Meral Shirazipour'" 
<[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, May 24, 2006 6:08 PM
Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 24 May 2006 22:54:14 +0100

Hi Lucy,

Sorry that I am a bit behind in this discussion. others may have jumped in 
on some of these points already.

> addition, TED is not excluded to reside within network, which is hard to 

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.

> sends a signal request at ingress point at the time that a bandwidth 

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.

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

> NMS initiating the service request, but does not show the reservation

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.

> reservation.

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?

> It seems that current TED definition does not serve this function.

Please show me the definition to which you refer.

Thanks,
Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 24 May 2006 22:58:31 +0100

No problem.

Thanks for continuing to discuss this.

>>> resource is already blocked out. When a booking order in SORD is
>>> ready to kick off, SORD

Yes. Your SORD becomes just another regular PCC. in fact, it is probably 
part of the NMS/OSS.

> will think about the protocol enhancement.

OK.

Thanks,
Adrian

---

From: Lucy Yong <[email-masked]>
Date: Wed, 24 May 2006 17:07:21 -0500

Hi Adrian,

Great explanation. Thanks.
Since PCE is the only path computation engine, any path reservation needs to
go through it even the result could be saved in TED. I understand the TED
may be fed by IGP extensions or potentially by other means. This other could
be the reservation system. However, the reservation system only has ingress
and egress information, it does not have travel path information, TED can
not compute the path either. Therefore, it needs to go through the PCE. No
need to another path computation engine.

Regards,
Lucy 

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Wednesday, May 24, 2006 4:34 PM
To: Lucy Yong; 'Payam Torab'; [email-masked]
Cc: [email-masked]
Subject: What is the TED? Was: [Pce] Comments about

Hi Lucy,

Regards,
Adrian

---

From: Lucy Yong <[email-masked]>
Date: Wed, 24 May 2006 17:44:47 -0500

Adrian,

Thank you for a kind advice.
My purpose is to suggest PCE based architecture could support time-based
reservation, which has a great value for a label switched service. (As the
chair, you deserve a high pay!) You clearly see this function in existing
architecture model while that is not clear to me (sorry I am not that
clever). My point is: does this worth to explicitly mention in the document
even this may not be the main implementation area for the group? Don't know
if the time is the issue or not. I am new for this group and just read this
document published recently. Maybe a lot of discussions have been done
before. Then, sorry about that late noise.

I would like to provide some informational draft about time-based
computation. However, as you mentioned, that will be back to the
architecture model again, which model to use. Thank you for the suggestion,
starting from the requirement might be a smart starting point. Please
continually advise.

Best Regards,
Lucy

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Wednesday, May 24, 2006 4:41 PM
To: Lucy Yong; 'Meral Shirazipour'
Cc: [email-masked]
Subject: Informational I-D for timebased LSPs Was: Comments about

Lucy,

Just to clarify:

Regards,
Adrian

---

From: JP Vasseur <[email-masked]>
Date: Thu, 25 May 2006 07:15:30 -0400

Hi Lucy,

On May 24, 2006, at 6:07 PM, Lucy Yong wrote:

> go through it even the result could be saved in TED.

Yes, although I would suggest you to be cautious here since there  
would be dangerous side-effect especially in situations where the PCE  
is not used by all nodes to compute TE LSP paths.

> I understand the TED

It looks like you use a different terminology than in the IETF  
documents related to MPLS TE:
-> By "reservation system" do you mean "Control plane used to  
establish the TE LSP (RSVP-TE)" ?
-> TED never compute paths ... this is the topology database used to  
compute path

Thanks.

JP.

>> manage which bandwidth need to reserve ahead and which is only a  
>> book. It
>> is
>> between the current PCE architecture, and adding an element of  
>> time to
>> path

---

From: Lucy Yong <[email-masked]>
Date: Thu, 25 May 2006 08:58:24 -0500

Hi JP,

Thank you for a good catch. See me response below.

Regards,
Lucy

-----Original Message-----
From: JP Vasseur [mailto:[email-masked]] 
Sent: Thursday, May 25, 2006 6:16 AM
To: Lucy Yong
Cc: 'Adrian Farrel'; 'Payam Torab'; [email-masked];
[email-masked]
Subject: Re: What is the TED? Was: [Pce] Comments about
draft-ietf-pce-architecture-05

Hi Lucy,

[Lucy] Agree. I do not assume that either. PCE could be centralized or
partial distributed.

[Lucy]: Sorry, use the wrong term. It should be inventory system. Inventory
system is manually maintained resource system. With PCE based architecture,
we only want one place to compute the path, that is the PCE. Therefore, no
matter where the time-based reserved resource is stored, PCE should be the
place to compute the path. Maybe someone could illustrate how the basic
architecture model could accomplish this task. :)

Thanks.

JP.

---

From: [email-masked]
Date: Thu, 25 May 2006 16:50:29 +0200

lucy - 

this side discussion on TED is diverting from the (real) issue behind the 
initial
proposal that has started this thread 

there is first a need to determine whether there is an interest behind 
this feature
i.e. whether this would be addressing a real concern, and i have not seen 
anything 
similar in all the requirements document and discussion we had since so 
far

now, assuming such requirement would pop up (i would be keen to see which 
applications
we're speaking about here) there is a second phase that consists in 
assessing whether 
the PCE communication/entity is appropriate for processing such kind of 
information 
(side note: PCE does not perform any resource admission control nor 
performs any sort
of resource reservation) and the impact this would have on the PCE 
mechanisms assumed 
since so far

this because time based reservation / time constraint implies 

- network time synchronization for each resource reservation and for each 
LSP

- the PCE that will have to take this constraint into account will also 
have to maintain
  (or obtain as information) for each reservation and for each LSP the 
time elapsed in 
  order to be able to provide with the suitable answer to subsequent 
request (in brief, 
  a computation will not have only to rely on the PRESENT state of the 
network resource 
  reservation but also on PAST and FUTURE reservation) 

  note: there is a side-effect on the signaling protocol mechanism as this 
breaks the 
  idempotent behaviour of RSVP (for inst.)

- PCEs will need to synchronize around that information during Path 
computation requests
  involving more than one PCE

- PCE becomes trigger for setting up and tearing down LSP (or at least is 
involved in 
  this decision process) when reservation time elapses and the signaling 
controller fails
  performing this action

- Preemption will become a required mechanism (based on the LSP priority) 
you would have
  to perform actions that are also impacting network stability

- etc.

at the end and more specifically the "pce architecture" document is not 
dealing with any
kind of specific usage of the functional (and informational) element that 
are proposed
but on the other side someone proposing a specific application has imho to 
demonstrate 
that the documented mechanisms will support this specific application, and 
i fail to see 
real rationales for the time being
 
thanks,
- dimitri.

25/05/2006 15:58
 
        To:     "'JP Vasseur'" <[email-masked]>
        cc:     [email-masked], Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        Subject:        RE: What is the TED? Was: [Pce] Comments about 
draft-ietf-pce-architecture-05

Hi JP,

Regards,
Lucy

-----Original Message-----
From: JP Vasseur [mailto:[email-masked]] 
Sent: Thursday, May 25, 2006 6:16 AM
To: Lucy Yong
Cc: 'Adrian Farrel'; 'Payam Torab'; [email-masked];
[email-masked]

Hi Lucy,

[Lucy]: Sorry, use the wrong term. It should be inventory system. 
Inventory
system is manually maintained resource system. With PCE based 
architecture,
we only want one place to compute the path, that is the PCE. Therefore, no
matter where the time-based reserved resource is stored, PCE should be the
place to compute the path. Maybe someone could illustrate how the basic
architecture model could accomplish this task. :)

Thanks.

JP.

---

From: JP Vasseur <[email-masked]>
Date: Thu, 25 May 2006 11:03:19 -0400

Hi Lucy,

> [Lucy] Agree. I do not assume that either. PCE could be centralized or

Again be cautious with the word "distributed"; this has been  
discussed on the list. You can refer to the definition provided in  
the document.

> architecture model could accomplish this task. :)

Right. Note that our charter is limited to the PCE. Inventory system,  
NMS, ... are outside of our scope.

Thanks.

JP.

---

From: Lucy Yong <[email-masked]>
Date: Thu, 25 May 2006 10:22:14 -0500

Hi Dimitri,

Thank you for the concern. I did not expect the group come out a solution
for this application now. All I want to say is that PCE based architecture
could allow this kind of application compared to current NE based
computation, which is value added for this architecture. Adding this
application does require to add some features and protocols. Weather we want
to solve in this group or not is debatable and depends on the peoples
interests. There are five models in the basic architecture, but the group
only focuses on LSR-PCE and PCE-PCE protocols not all functions architected.
Therefore, why do you so much concern that showing the architecture
capability to support this application will impact whole project scope?

I could provide some information to show the importance of the application.
People working in different areas have different views. As I mentioned, it
is hard to see a large bandwidth demand or a permanent bandwidth demand will
always be requested at time it needs. When the network and its management
move to intelligent automatic management, it needs to have the capability to
support the future reservation and we hope to have one place to do the path
computation.

Regards,
Lucy

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] 
Sent: Thursday, May 25, 2006 9:50 AM
To: Lucy Yong
Cc: 'JP Vasseur'; [email-masked]
Subject: RE: What is the TED? Was: [Pce] Comments
aboutdraft-ietf-pce-architecture-05

lucy - 

- etc.

thanks,
- dimitri.

Hi JP,

Regards,
Lucy

-----Original Message-----
From: JP Vasseur [mailto:[email-masked]] 
Sent: Thursday, May 25, 2006 6:16 AM
To: Lucy Yong
Cc: 'Adrian Farrel'; 'Payam Torab'; [email-masked];
[email-masked]

Hi Lucy,

Thanks.

JP.

---

From: Lucy Yong <[email-masked]>
Date: Thu, 25 May 2006 10:36:48 -0500

Adrian,

Let's put down the time-based reservation for now. I have another comment
about the draft. In the Figure 5, it shows that NMS will send request to PCE
directly to get the path information and send service request to the
head-end node. The request flow seems different from other the four models.
Is it better to keep the consistency?
We could have NMS based service request to go head-end node first and let
head-end node send request to PCE, thus all models will have the same
message flows.
Does this make sense?

Regards,
Lucy

---

From: [email-masked]
Date: Thu, 25 May 2006 17:39:04 +0200

lucy 

> There are five models in the basic architecture, but the group

indeed (because the other entities are outside the scope) 

> capability to support this application will impact whole project scope?

for the reasons explained in my previous post - without clear answers 
to these issues (that are going to impact the whole approach) i don't
see how you could progress

> When the network and its management move to intelligent automatic 
management, 
> it needs to have the capability to support the future reservation and we 
hope 
> to have one place to do the path computation.

probably ... but if you are intricating "reservation time" in the path 
computation request you are de-facto going to introduce resource resv.
which is beyond scope of path computation 

i can understand that some NRENs, research nets, etc. are looking at
LSP / resource scheduling functionality (... the mythical resource
broker) for single domain application specific networks but PCE is not
meant to incorporate such functionality

thanks,
- d.

25/05/2006 17:22
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     "'JP Vasseur'" <[email-masked]>, [email-masked]
        Subject:        RE: What is the TED? Was: [Pce] Comments 
aboutdraft-ietf-pce-architecture-05

Hi Dimitri,

application does require to add some features and protocols. Weather we 
want
only focuses on LSR-PCE and PCE-PCE protocols not all functions 
architected.

I could provide some information to show the importance of the 
application.
People working in different areas have different views. As I mentioned, it
is hard to see a large bandwidth demand or a permanent bandwidth demand 
will
always be requested at time it needs. When the network and its management
move to intelligent automatic management, it needs to have the capability 
to
support the future reservation and we hope to have one place to do the 
path
computation.

Regards,
Lucy

-----Original Message-----

lucy - 

breaks the 

- etc.

demonstrate 

i fail to see 
 
thanks,
- dimitri.

Hi JP,

Regards,
Lucy

-----Original Message-----
From: JP Vasseur [mailto:[email-masked]] 
Sent: Thursday, May 25, 2006 6:16 AM
To: Lucy Yong
Cc: 'Adrian Farrel'; 'Payam Torab'; [email-masked];
[email-masked]

Hi Lucy,

Thanks.

JP.

---

From: Lucy Yong <[email-masked]>
Date: Thu, 25 May 2006 11:21:16 -0500

Dimitri,

I see your points. Since PCE based architecture opens a lot of potential
compared to NE based path computation. Although the group only focus on the
basic communication capability between LSR and PCE, it may be not necessary
to conclude that the group will not study this in the future if this is
convinced as an important functionality.
Does IETF require closing the group when it finishes the charter goal?

Regards,
Lucy

-----Original Message-----
Sent: Thursday, May 25, 2006 10:39 AM

lucy 

architected.

management, 
hope 

thanks,
- d.

Hi Dimitri,

Regards,
Lucy

-----Original Message-----

lucy - 

breaks the 

- etc.

demonstrate 

i fail to see 
 
thanks,
- dimitri.

Hi JP,

Regards,
Lucy

-----Original Message-----
From: JP Vasseur [mailto:[email-masked]] 
Sent: Thursday, May 25, 2006 6:16 AM
To: Lucy Yong
Cc: 'Adrian Farrel'; 'Payam Torab'; [email-masked];
[email-masked]

Hi Lucy,

Thanks.

JP.

---

From: "Drake, John E" <[email-masked]>
Date: Thu, 25 May 2006 11:37:34 -0700

Hi,

I had a clarification question.  Isn't it the case that it is a matter
of policy whether a given node uses a PCE or computes/expands the ERO
itself?

If so, then I think time-based may be problematic as the PCE operating
in the future domain will have no idea of the EROs that will be computed
in the future by the nodes not using the PCE.

Thanks,

John 

> Sent: Wednesday, May 24, 2006 3:07 PM
> To: 'Adrian Farrel'; 'Payam Torab'; [email-masked]
> Cc: [email-masked]
> Subject: RE: What is the TED? Was: [Pce] Comments aboutdraft-ietf-pce-
> architecture-05
> 
> Hi Adrian,
> 
> Since PCE is the only path computation engine, any path reservation
needs
> I think that some of the confusion may be coming from the definition
of
> TED.
> on which PCE operates to compute TE paths. You might think that this
TED
> > and another place hold all reservations. You can flexibly apply
policy
> > manage which bandwidth need to reserve ahead and which is only a
book.
> It
> > between the current PCE architecture, and adding an element of time
to
> >> > What you say here is important if we consider the Internet
peering

---

From: Lucy Yong <[email-masked]>
Date: Thu, 25 May 2006 14:27:11 -0500

Hi John,

John,

It is hard to see this time-based feature will be implemented on NE. 
If a network does not use PCE based architecture, carrier has to implement
in other way like today's. However, today's solution, carrier needs to have
two path computation engines: one in the network and one in the management
system. That is why PCE provides this special value as I see.

Thanks,
Lucy

-----Original Message-----
From: Drake, John E [mailto:[email-masked]] 
Sent: Thursday, May 25, 2006 1:38 PM
To: Lucy Yong; Adrian Farrel; Payam Torab; [email-masked]
Cc: [email-masked]
Subject: RE: What is the TED? Was: [Pce] Comments

Hi,

Thanks,

John 

needs
of
TED
policy
book.
to
peering

---

From: JP Vasseur <[email-masked]>
Date: Thu, 25 May 2006 13:58:38 -0400

Hi Lucy,

> Does IETF require closing the group when it finishes the charter goal?

If you want to know what is under the scope of the PCE WG, here is  
the current charter: http://www.ietf.org/html.charters/pce-charter.html

And if you plan to submit draft(s) in the future, to be adopted as WG  
document, yes the draft MUST be related to a WG item (under the scope  
of the charter).

Now to answer your question, WG can be re-chartered to add new items,  
with the approval of the IESG, as specified in RFC2418.

Thanks.

JP.

>> needs to
>>> policy to

---

From: "Drake, John E" <[email-masked]>
Date: Thu, 25 May 2006 12:50:04 -0700

Lucy,

It's probably just a matter of design philosophy.  If you want to use
time- based, I think you need to lock-step the network through time and
you need to address the set of issues that Dimitri raised.  I don't
remember if Dimitri raised the issue that unplanned link/node outages
may wreak havoc with your nicely planned future.

If you don't want to use time-based, then pre-emption mechanisms in
signaling allow the network to adapt to the conditions at a given point
in time.

Thanks,

John

> Sent: Thursday, May 25, 2006 12:27 PM
> To: Drake, John E; 'Adrian Farrel'; 'Payam Torab';
> [email-masked]
> Cc: [email-masked]
> Subject: RE: What is the TED? Was: [Pce] Commentsaboutdraft-ietf-pce-
> architecture-05
> 
> Hi John,
> 
> John,
> 
aboutdraft-ietf-pce-
> > go through it even the result could be saved in TED. I understand
the
> TED
> > may be fed by IGP extensions or potentially by other means. This
other
> > could
> > and egress information, it does not have travel path information,
TED
> can
> > exactly the database of TE information advertised by an IGP, and
that
> > would
> > > The draft specifies five architecture scenarios. Suggest adding
one
> for
> > > time-based reservation. Giving the definition of TED, I don't see
it
> can
> > > TED contains topology and resource information from network. It
may
> be
time
> to
> > > path
> > > computation. You can certainly add time constraints to TED, as
well
> as

---

From: Lucy Yong <[email-masked]>
Date: Thu, 25 May 2006 15:02:12 -0500

John,

Please keep in mind, not all the future books need to reserve the bandwidth,
especially for the future order that requires carrier to build new network
spans. We will gradually address Dimitri's concern. The design philosophy is
to keep path computation functionality in the same place.   

Thanks,
Lucy 

-----Original Message-----
From: Drake, John E [mailto:[email-masked]] 
Sent: Thursday, May 25, 2006 2:50 PM
To: Lucy Yong; Adrian Farrel; Payam Torab; [email-masked]
Cc: [email-masked]
Subject: RE: What is the TED? Was: [Pce]
Commentsaboutdraft-ietf-pce-architecture-05

Lucy,

Thanks,

John

aboutdraft-ietf-pce-

the
other
TED
that
one
it
may
time
well