Hi Dan, Sorry for my late response. I just got back to office. Please see in-line for my response to your comments. Thanks.
Regards, Young _____ From: Daniel King [mailto:[email protected]] Sent: Monday, April 20, 2009 8:43 AM To: 'Young Lee' Cc: [email protected] Subject: RE: [Pce] Comments on draft-lee-pce-ted-alternatives-01.txt Hi Young, et al. I thought the draft was well written and an interesting area for discussion. I had the following general comments. a) A key goal of the work is to gather necessary network management information for offline complex path computation. Its logical to assume that the complex offline path computation might be centralized. It might be worth stating this as an assumption. Young>> We are not necessarily assuming centralised offline PCE regime in this draft. As we explore many architecture options that include multiple PCE options and possibly using some on-line protocols in disseminating TED related information, I am a little hesitant to state your suggested assumption. b) We should not get to caught up in the details of proposed mechanisms or solutions. This is after all an architecture document. Young>> Yes, this document is basically an architecture/framework document. We are not proposing any particular mechanisms or solutions here. We simply stated a set of candidate mechanisms/solutions to give a more realistic perspective. We will clean up the texts in the revision to make sure your point is addressed. c) A hybrid approach to performing path computation in the network might be considered as there is motivation for performing path computation (simple versus complex) in different parts of the network. All planning and complex path computation could be performed by the offline and centralized PCE. Rapid restoration and local repair could then distributed to the local PCEs. Each distributed PCE can always signal the centralized PCE for reoptimization after the initial local path computation, in order to request a path computation that considers more complex constraints. Young>> Good point! As you point out, there may be cases where both node-based PCE and server-based PCE may need to interact. I can also envision that complex path computation like IA-RWA solely depend on server-based PCE while quick calculation has to be done at the node level such as restoration, etc. We can add a section that discusses usage scenarios. d) Fundamentally we should use the right mechanism to distribute the data according to where it is needed. If some form of path computation is needed on LSRs, then in my opinion the necessary information should be distributed using the IGPs. We should be careful about recommending a solution that does not use the IGP at all. In a model where there are many nodes with path computation capabilities, we effectively need to flood information to each PCE. The IGPs have been designed for this. If we use PCEP to distribute information to go in the TED we may end up trying to turn PCEP into a flooding protocol that replaces the IGPs. Young>> Yes, we are NOT proposing replacement of IGP-TE in favour of alternative mechanisms. I envision that IGP-TE and the alternative mechanism would be complementary to each other. It all depends on where path computation would be done. Route calculation can be done easily at the node level while WA (Wavelength Assignment) and IV (Impairment Validation) can be done at the server PCE although all of them can be done at the server level or at the node level. I envision that whatever is defined in the current IGP-TE, we should continue to use them using IGP-TE's flooding while new information may be transported using new mechanism. e) As mentioned in point (b), we should avoid getting into solution details. As an architecture/requirements document, this draft should maybe not mention any protocols at all except in the context of what they already do and are used for. So, discussing using PCEP for data distribution, or discussing LDAP may be out of scope (even for an Appendix). But it is very valid to describe the data model, and I think that bit that is not generally flooded is a distributed database just like in the LDAP model. Young>> I think we discussed this issue previously. f) I made some minor comments and suggestions along the points above as change modifications in a word document. I will unicast the document to you shortly. Young>> Thanks for your help! We have a quite a few comments/suggestions so far for this work. I will put them together in the revision and let the WG know the changes from the previous version. Look forward to seeing your modifications. Br, Dan.
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
