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
