Dear Greg, without getting into implementation details I'd add third important mechanism used by IGPs to maintain reasonably up-to-date LSDB - exchange of Hello/Keepalive messages between immediate neighbors.
Regards, Greg On Thu, Apr 23, 2009 at 8:23 AM, Greg Bernstein <[email protected] > wrote: > Hi Peng, I think Young is out of the office this week. > On the statement "One key function is to ensure that the network > information obtained from nodes or elsewhere is relatively timely, or not > stale " . > This is similar to the requirements we see on link state IGPs and seemed > appropriate here as an important maintenance procedure. > > By the way link state IPGs use two mechanisms: (a) link state update > messages (there is some rate control on how often these can be sent, but the > latency can be significantly under 1 second), (b) aging of link state > advertisements (LSAs) -- OSPF terminology --. In the "aging" mechanism > information gets removed from the TED if not refreshed (typically many > minutes). However we didn't want to get into implementation details. > > Best Regards > > Greg (trying to fill in for Young) > > > Peng He wrote: > > Hello Young, > > This is definitely a very interesting draft. Have a question here: > you mentioned at page 13 that "One key function is to ensure that the > network information obtained from nodes or elsewhere is relatively > timely, or not stale "; > > I'd like to know if you have considered how to make sure the obtained > information is NOT stale? what is the metric to justify it? what is > the bottom line?say, 1 second, or i minute? maybe the question is too > detail :) Thanks a lot. > > > Regards, > Peng > > On Tue, Apr 21, 2009 at 1:59 PM, Igor Bryskin <[email protected]> > <[email protected]> wrote: > > > 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]> > <[email protected]> > To: Young Lee <[email protected]> <[email protected]> > Cc: Igor Bryskin <[email protected]> <[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] <[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 [email protected]https://www.ietf.org/mailman/listinfo/pce > > > > -- > =================================================== > 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
