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. 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? 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. 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. 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. 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. 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
