Hi, In my comments I forgot to mention IMO a very good argument in favor and a strong drive for using an alternative to IGP-TE method for managing TED.
Consider a "network planner" type of applications which try various "what if?" scenarios on network topologies that do not (fully or partially) exist yet but could be provisioned under certain circumstances. These applications , of course, require numerous complex path computations and are great candidates to play the PCC role. But, as Eve Varma said on the last IETF, our path computations are only as good as our advertisements. So, for a Network Planner it would be quite easy to use PCEP and send the necessary resource state information to a PCE for not yet existing links on behalf of not yet existing NEs, request the path computation(s) and then clean up the PCE's TED. It is much more difficult (if not impossible) to do the same things using IGP-TE (e.g. have unexisting NEs originate TE LSAs and then flush them out when they are not needed anymore). So there are two important byproducts that a PCEP based method of managing TED gives compared to the IGP-TE method: a) ability to send TE info updates on behalf of unexisting links and NEs; b) determine the moment when all the necessary TE info is installed in the PCE's TED, and it is possible to request the path computations. Note that b) in its own right is quite non-trivial problem to solve when one uses the IGP-TE method for the TED management. Cheers, Igor ________________________________ From: Greg Bernstein <[email protected]> To: Young Lee <[email protected]> Cc: Igor Bryskin <[email protected]> Sent: Thursday, April 16, 2009 5:37:08 PM Subject: Re: Comments on draft-lee-pce-ted-alternatives-01.txt Great to have help with the editing and concept development! Cheers Greg Young Lee wrote: Hi Igor, Thanks a lot for your comments. They are all valuable ones and we can put most of them in the update. I will send you the WORD template of the existing version so that you may be able to participate editing exercise with other co-authors. Thanks. Regards, Young ________________________________ From:Igor Bryskin [mailto:[email protected]] Sent: Thursday, April 16, 2009 2:15 PM To: Young Lee; [email protected] Subject: Comments on draft-lee-pce-ted-alternatives-01.txt Hi, Here is my comments on the draft “Alternative Approaches to Traffic Engineering Database Creation and Maintenance for Path Computation Elements” http://tools.ietf.org/id/draft-lee-pce-ted-alternatives-01.txt General comments. 1. Everywhere you say IGP you mean, I am sure, IGP-TE. It is worth to make it clear. I know that many people think that IGP-TE is an extension of IGP for TE purposes, but in fact, the two are completely different protocols with completely different purposes: one is to dynamically manage IP forwarding tables, and the other is to discover network resources of various network layers and use this information for constraint based path computations. The only thing that the two have in common is that they may share the same instance of the IGP flooding/synchronization machinery (even this becomes increasingly untrue: today many use separate instances, look for the OSPF transport instance and multi-instance activities in the OSPF WG). Other then that, the two protocols have nothing in common; and this is especially true in the context of this document. It is quite reasonable to imagine, for example, that within the PCE Architecture one can completely eliminate use of IGP-TE by using, say, PCEP instead, to send local resource updates directly to PCE(s). However, one will still need IGP for forwarding control plane traffic. So my point here is that we want alternative methods to IGP-TE and not to IGP. 2. I’d like to see in the draft a discussion on why the flooding of TE information and the PCE architecture is not a good match. And this is because flooding of any type of information works well on homogeneous topologies, where all participants originate, distribute and use the information. That’s why IP OSPF, for example, works well: all OSPF speakers originate LSAs, flood local and remote LSAs and use them in route calculations. The PCE architecture is by definition asymmetrical with respect to the information used in path computations: many elements originate, but only few use it, and the flooding under these circumstances could be very inefficient for all these reasons that you mentioned: memory, CPU, bandwidth, etc. Specific comments: 1. You write: “ This draft does not advocate that the alternative methods specified in this draft should completely replace the IGP as the method of creating the TED.” Why not? I mean there is a variety of ways how the alternative methods could relate to the IGP-TE method of managing TEDs. And I’d like to see a section describing different use cases and examples of IGP-TE and the alternatives cooperating with each other. One such use case is, for example, a network built of simple optical NEs managed by a tiny control plane that consists of: 1) PCC instance to send updates to remote PCE(s) on local resources status and also request path computations; 2) Very limited RSVP-TE instance for signaling fully explicit EROs provided by the PCE(s). In this case IGP-TE is not involved at all. There could be different ways how the alternatives can cooperate with IGP-TE. One such cooperation, as you suggested, could be a split of what information is distributed by IGP-TE and what via alternatives. For example, it makes sense to distribute “static” (rarely modified) and sizable data – e.g. NE switching asymmetricity – via methods other than IGP-TE, while more frequently changed data via IGP-TE. This could significantly decrease the IGP-TE information and its footprint on all speakers. Another type of cooperation between the IGP-TE method and its alternatives is limiting number and type of elements participating in IGP-TE. Your architectural option #3 requires inter-PCE TED synchronization. How about interconnecting PCEs into one or more rings via IP-IP tunnels and use an instance of IGP-TE over the tunnels for the sole purpose of TED synchronization between the PCEs? 2. You wrote: “In OSPF the information directly related to IP connectivity (and hence the control communications plane for all three technologies) is kept in the link state database (LSDB), while additional information related to traffic engineering used by MPLS and GMPLS is kept in a (conceptually) separate traffic engineering database (TED)”. This is not accurate. All IP and non-IP advertisements are stored in LSDB. Additionally, TE info is kept in TED. 3. In section 2.0 you describe the advantages of using alternative to IGP-TE methods. You also need here to clearly state the disadvantages, which are: a) necessity of mechanisms that we take for granted when use IGP-TE: removal of stale information, reliable delivery of updates to all participants; recovery after reboots/crashes/upgrades, etc. b) additional security concerns; c) protocol to discover PCEs that are capable and willing to accept direct updates; d) protocol to send the updates; etc. 4. Why not PCEP? This is not a requirement document. So I think it would be beneficial to suggest a solution for the protocol to be used by NEs to send resource updates to PCE(s). Considering that this protocol is supposed to: a) discover PCE(s) capable and willing to receive such updates; b) maintain sessions between NEs and PCE(s); c) address all the security concerns for PCE(s) to accept such updates; d) guarantee reliable delivery of the updates; why not to extend PCEP for this purpose since it is already doing all these things? Cheers, Igor -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
