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 PROTECTED]> To: "'Adrian Farrel'" <[EMAIL PROTECTED]>; "'Meral Shirazipour'" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, May 24, 2006 6:08 PM
Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05


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 PROTECTED]
Sent: Wednesday, May 24, 2006 11:11 AM
To: Meral Shirazipour; Lucy Yong
Cc: [EMAIL PROTECTED]
Subject: Re: [Pce] Comments about draft-ietf-pce-architecture-05

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

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.

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











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

Reply via email to