Hi all, I agree in terms of a solution this is fairly simple. In addition to the tunnels and LSA filtering (i.e. PCE filters LSAs over an adjacency with a PCC) you also need to identify whether the neighbor is a PCC or a PCE which could be based on the PCE discovery mechanisms.
Regards Snigdho -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Greg Bernstein Sent: Wednesday, April 15, 2009 12:13 PM To: Young Lee Cc: [email protected] Subject: Re: [Pce] PCE TED work Hi all a couple more comments on top of Young's and Fabien's. See inline below. Best Regards Greg Young Lee wrote: > -- snip -- > 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. > > --->> Agree, initially, this is a good place to start especially for small WSONs. > -- snip -- > 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. > ---- Greg >> This case was trying to cover lots of PCE and the scaling issue of the NEs talking to the PCEs. > 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. > > -- Greg >> The new OSPF multiple-instance drafts could also help in this area. -- snip --- -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
