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.
Lucy Yong <[EMAIL PROTECTED]>
25/05/2006 15:58
To: "'JP Vasseur'" <[EMAIL PROTECTED]>
cc: [EMAIL PROTECTED], Dimitri PAPADIMITRIOU/BE/[EMAIL PROTECTED]
Subject: RE: What is the TED? Was: [Pce] Comments about
draft-ietf-pce-architecture-05
Hi JP,
Thank you for a good catch. See me response below.
Regards,
Lucy
-----Original Message-----
From: JP Vasseur [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 25, 2006 6:16 AM
To: Lucy Yong
Cc: 'Adrian Farrel'; 'Payam Torab'; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: Re: What is the TED? Was: [Pce] Comments about
draft-ietf-pce-architecture-05
Hi Lucy,
On May 24, 2006, at 6:07 PM, Lucy Yong wrote:
> 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.
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.
[Lucy] Agree. I do not assume that either. PCE could be centralized or
partial distributed.
> 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.
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
[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.
>
> Regards,
> Lucy
>
> -----Original Message-----
> From: Adrian Farrel [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, May 24, 2006 4:34 PM
> To: Lucy Yong; 'Payam Torab'; [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: What is the TED? Was: [Pce] Comments about
> draft-ietf-pce-architecture-05
>
> 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
_______________________________________________
Pce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pce
_______________________________________________
Pce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pce
