JP, I did not say the architecture prevent from time-based reservation. To be clarify here. Actually, I see that the architecture could be explicitly extended to support the application and be mentioned as one value for PCE based implementation compared to current router based implementation. The gap is you think that should be done in the TED and is out of scope of PCE. I think that, as we promote this basic architecture, it is good to mention the architecture also enable this kind of application and provide possible architecture scenario. Again, this does not impact the protocol implementation scoped here.
Lucy -----Original Message----- From: JP Vasseur [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 24, 2006 2:35 PM To: Lucy Yong Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [Pce] Comments about draft-ietf-pce-architecture-05 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
