Lucy, It's probably just a matter of design philosophy. If you want to use time- based, I think you need to lock-step the network through time and you need to address the set of issues that Dimitri raised. I don't remember if Dimitri raised the issue that unplanned link/node outages may wreak havoc with your nicely planned future.
If you don't want to use time-based, then pre-emption mechanisms in signaling allow the network to adapt to the conditions at a given point in time. Thanks, John > -----Original Message----- > From: Lucy Yong [mailto:[EMAIL PROTECTED] > Sent: Thursday, May 25, 2006 12:27 PM > To: Drake, John E; 'Adrian Farrel'; 'Payam Torab'; > [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: RE: What is the TED? Was: [Pce] Commentsaboutdraft-ietf-pce- > architecture-05 > > Hi John, > > John, > > It is hard to see this time-based feature will be implemented on NE. > If a network does not use PCE based architecture, carrier has to implement > in other way like today's. However, today's solution, carrier needs to > have > two path computation engines: one in the network and one in the management > system. That is why PCE provides this special value as I see. > > Thanks, > Lucy > > -----Original Message----- > From: Drake, John E [mailto:[EMAIL PROTECTED] > Sent: Thursday, May 25, 2006 1:38 PM > To: Lucy Yong; Adrian Farrel; Payam Torab; > [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: RE: What is the TED? Was: [Pce] Comments > aboutdraft-ietf-pce-architecture-05 > > Hi, > > I had a clarification question. Isn't it the case that it is a matter > of policy whether a given node uses a PCE or computes/expands the ERO > itself? > > If so, then I think time-based may be problematic as the PCE operating > in the future domain will have no idea of the EROs that will be computed > in the future by the nodes not using the PCE. > > Thanks, > > John > > > -----Original Message----- > > From: Lucy Yong [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, May 24, 2006 3:07 PM > > To: 'Adrian Farrel'; 'Payam Torab'; [EMAIL PROTECTED] > > Cc: [EMAIL PROTECTED] > > Subject: RE: What is the TED? Was: [Pce] Comments aboutdraft-ietf-pce- > > architecture-05 > > > > 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. 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. > > > > 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
