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
