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
----- Original Message -----
From: "Lucy Yong" <[EMAIL PROTECTED]>
To: "'Payam Torab'" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, May 24, 2006 9:48 PM
Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05
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 PROTECTED]
Sent: Wednesday, May 24, 2006 2:31 PM
To: 'Lucy Yong'; [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05
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
-----Original Message-----
From: Lucy Yong [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 24, 2006 3:11 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: RE: [Pce] Comments about draft-ietf-pce-architecture-05
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-----
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-proto
col-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
_______________________________________________
Pce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pce
