Hi Lucy,
On May 24, 2006, at 3:10 PM, Lucy Yong wrote:
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.
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.
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.
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
it is, it is scared what we are doing here.
Regards,
Lucy
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 24, 2006 12:49 PM
To: Lucy Yong
Cc: 'Adrian Farrel'; 'Meral Shirazipour'; [EMAIL PROTECTED]
Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05
lucy -
take a look at
<http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol-
gen-reqs-0
6.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
Lucy Yong <[EMAIL PROTECTED]>
24/05/2006 19:33
To: Dimitri PAPADIMITRIOU/BE/[EMAIL PROTECTED]
cc: "'Adrian Farrel'" <[EMAIL PROTECTED]>, "'Meral
Shirazipour'" <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
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.
Adrian has mentioned that it is in PCE scope.
Regards,
Lucy
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 24, 2006 12:25 PM
To: Lucy Yong
Cc: 'Adrian Farrel'; 'Meral Shirazipour'; [EMAIL PROTECTED]
Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05
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)
Lucy Yong <[EMAIL PROTECTED]>
24/05/2006 19:08
To: "'Adrian Farrel'" <[EMAIL PROTECTED]>, "'Meral
Shirazipour'" <[EMAIL PROTECTED]>
cc: [EMAIL PROTECTED]
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
_______________________________________________
Pce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pce
_______________________________________________
Pce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pce
