Young. Please see my comments in line.
Igor ________________________________ From: Young Lee <[email protected]> To: Igor Bryskin <[email protected]>; Greg Bernstein <[email protected]> Cc: [email protected] Sent: Tuesday, April 28, 2009 4:21:45 PM Subject: RE: Comments on draft-lee-pce-ted-alternatives-01.txt Hi Igor, I have a couple of comments on your “network planner” application using PCEP. - First of all, this is specific to PCEP implementation which we need to address in the solutions draft once the PCE-TED draft idea has been accepted in the WG. We need to separate detail discussion on a particular implementation from the current draft. But I think your suggested application is worth to revisit once we have a solution draft. IB>> I know you want to avoid to talk about specific solutions to IGP-TE alternative at this stage. But this is not a requirements document. So IMO it is OK to give an example of one obvious (at least to me) such solution - extended PCEP - because: a) no matter how TED is managed on the PCE, each NE will have to support the PCC side of PCEP to take advantage of the remote path computation service, so why use/invent other protocols? b) PCEP already addresses (or at least is supposed to address) such important aspects as security, reliable and in-order message delivery, client-server session support, etc. c) I also remember discussions in PCE WG about having PCEP provide an opaque option to deliver arbitrary information between PCC and PCE, everybody agreed (as I remember) that this is a reasonable and quite easy thing to do; and this is exactly what we need for the PCE-TED application - The intention of PCE-TED draft is not necessarily to replace the whole IGP-TE as information disseminating mechanism but to suggest that certain applications may warrant alternative methods that can co-exist with IGP-TE. We don’t want to reinvent the new wheel necessarily with the current scope of the draft. We would want to stay as “complementary” to IGP-TE. IB>> I think we need to consider two cases: 1) All path computations are performed on PCEs (no local path computations) 2) Some path computations are performed on PCEs, while some locally. In case 1) I don't really see why PCE-TED should co-exist with IGP-TE. If two mechanisms perform exactly the same function, and one is better than the other, what sense does it make to advertise certain things via one and other things using the other? It makes perfect sense to me just to pick the better one; In case 2) it does make some sense to have IGP-TE and PCE-TED co-exist. One example of such co-operation is that you can break your optical layer network into multiple areas in such a way that intra-area paths would not require optical impairments aware path computations, while inter-area paths should be computed with optical impairments constraints in mind. So now you can split: a) advertising: IGP-TE for all non-impairement related information; PCE-TED for all impairement related information; b) computation: local for intra-area paths; PCE for inter-area paths. One last note. My understanding, Young, that you have in mind to use PCE-TED for all WSON-related information, and IGP-TE for everything else. This path, I think, is not correct for the following reasons: a) as I mentioned above such cooperation only makes sense when you assume that at least some path computations are performed locally (not via remote PCE); b) in the optical layer network link level path computations (what you call routing without lambda assignment in a hope that somebody else (signaling or PCE) assign proper lambdas over computed link-level paths) are very impractical (to say the least) . Because local TEDs won't contain in this case lambda and switching assymetricity information, local path computations will produce no value, hence all computations eventually would have to be performed on PCEs which (as I mentioned above) will make the PCE-TED and IGP-TE cooperation unnecessary. Cheers, Igor Thanks. Regards, Young ________________________________ From:Igor Bryskin [mailto:[email protected]] Sent: Tuesday, April 21, 2009 12:59 PM To: Greg Bernstein; Young Lee Cc: [email protected] Subject: Re: Comments on draft-lee-pce-ted-alternatives-01.txt 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
