Hi Igor,
Thanks for your comments on the draft. Please see in-line for my reply. 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. Young>> Yes, we meant IGP, IGP-TE. 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. Young>> I agree. This sounds like a helpful discussion within the draft highlighting the motivation for this work. 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." Young>> What the statement above meant was for general case. For WSON case, we see great value considering alternative methods that can replace IGP-TE. On the other hands, there are applications (as you mentioned in 2) where current method (IGP-TE) works perfectly well. 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). Young>> Again, I tend to agree with you that these cases would justify PCE based alternative method. 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. Young>> Yes, cooperation between IGP-TE and alternative methods can prove some cases. I was envisioning that IGP-TE would continue distribute existing TE while WSON related info would be distributed via a new alternative. 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? Young>> I was thinking a similar method that runs a separate OPSF-TE instance over the tunnels taking advantage of OSPF's database synchronization and updates capability with neighbors. 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. Young>> We can correct this. 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. Young>> This is fair to put in the document. That's why if we can re-use many of the IGP-TE's mechanism (for instance for architectural option #3, we can re-use OSPF-TE between PCE-PCE for TED synch, 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? Young>> This was the original motivation for this work. We need to elaborate this point in the update. Thanks. Cheers, Igor
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
