Hi Fabien, Thanks for your valuable comments. Please see in-line for my response.
Best Regards, Young -----Original Message----- From: Fabien Verhaeghe [mailto:[email protected]] Sent: Wednesday, April 15, 2009 1:24 AM To: 'Young Lee'; [email protected] Subject: RE: [Pce] PCE TED work Hi Young and Greg, Here are some comments on draft-lee-pce-ted-alternatives A) In architecure presented in Figure 3, if one of the PCE fails we loose information sent by nodes to that PCE. Each node should send information to at least 2 PCEs to avoid single point of failure. Young>> I can see your point. Definitely this would enhance resiliency in case a PCE fails. Since each PCE only has a partial TED information, when a PCE fails, we may not be able to maintain the complete TED. B) section "2.1.1. Nodes Send TE Info to all PCEs" "As the number of PCEs grow we have scaling concerns" Is it really a concern? How many PCEs do you think may be needed? Young>> Each node will need to maintain session to each PCE with this architecture and this could be burden to the nodes if there are "too many" PCEs. If we are talking about 2-3 PCEs, the scaling concern may not be a real issue. C) section "2.2. Nodes Finding PCEs" In case 3 nodes the selection of the PCE needs to be done so that the load is correctly balanced among PCEs. Young>> Yes. I agree with you. D) Not sure what is the advantage of architecture 2 compared to architecture 1. At first I thought the advantage was that the node only sent information to one entity instead of N PCEs. But since we also need a backup server for resiliency purpose, eventually it seems to me both architecture are equivalent. Young>> Architecture 2 employs publish/subscribe functionality similar to BGP route reflectors. P/S server needs not be a PCE although it can be collocated with a PCE. We definitely need to consider resiliency of P/S servers as you indicate. Actually I think my problem is that I do not see what is the purpose of having multiple PCEs for one intermediate server. I thought the goal of having multiple PCEs (in case 1) was for backup purpose. This does not seems to be the case for case 2 since the backup is provided by having 2 intermediate server. Young>> You may be right. We are exploring different possibilities in the draft. We may elaborate advantages/disadvantages for each architecture. E) section "3.2.2. Communication Protocols" One idea: Isn't it possible to meet the presented architecture by using IGP over tunnels. For case 1 for instance. In figure 1 the characters "|", "-", "/", or "\" represents some (GRE) tunnels. You run OSPF (or ISIS) over those tunnels so that there is an adjacency between each node and the PCE in a dedicated OSPF (or IS-IS) area. You can rely on regular OSPF/ISIS procedure to send TE information from node to PCE. The only OSPF/ISIS trick needed is at the PCE to prevent LSA received from one node to be sent to other nodes. I think this it is possible, without having any problem with legacy OSPF/ISIS node though it needs to be check more deeply. The advantage would be that it requires none or few protocol extensions. One drawback is that it offers less flexibilities to target which information are sent to the PCE and which are not. Young>> Sounds a good choice. At this point, we are not proposing any solution. This draft simply illustrates a set of possible communication protocols that can implement the proposed architectures. We can add your tunnels + IGP idea into the text. Ultimately, once this work is approved, then we can think of implementation details. BR Fabien > -----Message d'origine----- > De : [email protected] [mailto:[email protected]] De la part de > Young Lee > Envoyé : jeudi 9 avril 2009 20:34 > À : [email protected] > Objet : [Pce] PCE TED work > > > Dear fellow PCE working group participants, > > As discussed at the PCE WG meeting at the 74th IETF meeting in San > Francisco > we'd like to get feedback on the document: "draft-lee-pce-ted- > alternatives". > This document examines alternative and supplementary approaches to > creating > and maintaining the Traffic Engineering Database (TED) used by a PCE. In > addition, the document examines areas for potential standardization within > these alternative approaches. This document does not extend or alter any > existing protocols or dictate a particular approach. > > The benefits of this document to the PCE working group include: > (a) Further elaboration with examples of the concepts presented in section > 4.3 of the PCE Architecture document (RFC4655). > > (b) Compares various approaches to achieving the concepts of section 4.3 > of > RFC4655. > > (c) Points the way for possible future standardization work. > > The eventual goal would be for this document to become an informational WG > document/RFC. > > Best Regards > > Young and Greg > ------------------------------ > > Message: 2 > Date: Wed, 25 Mar 2009 10:07:18 -0500 > From: "Bardalai, Snigdho" <[email protected]> > Subject: [Pce] Comments on draft-lee-pce-ted-alternatives-01.txt > To: <[email protected]> > Message-ID: > <[email protected]> > Content-Type: text/plain; charset="us-ascii" > > Hi > > > > I believe capturing this information is important in order to attain a > consistent behavior for the PCC and PCE implementations. Also, this > provides engineering guidelines for system design. > > > > Given that I would propose that we either add solution options to this > ID or create a separate one. > > > > Thanks, > > Snigdho > > > > _______________________________________________ > Pce mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
