Hi JP, thanks for the clarifications and suggestions! Br, Dan.
From: JP Vasseur [mailto:[email protected]] Sent: 17 December 2009 18:17 To: Daniel King Cc: [email protected] Subject: Re: [Pce] WG Last Call on I-D Action:draft-ietf-pce-p2mp-req-04.txt Hi Dan, On Dec 15, 2009, at 5:51 PM, Daniel King wrote: Hi JP, All, As a co-editor of the P2MP Solutions (draft-ietf-pce-pcep-p2mp-extensions-05) I would like to state that the authors of the P2MP Requirements (draft-ietf-pce-p2mp-req-04) added all the additional requirements that we identified during the development of the P2MP solutions document. So I believe that the P2MP Requirements document is in fairly good shape. We do however have one outstanding issue regarding the solutions document. I do not believe this directly impacts the P2MP Requirements document itself, but its certainly worth discussing the issue on the list. The P2MP Requirements draft mentions the requirement for reoptimization of P2MP TE LSPs: >> 2.1.10. Reoptimization of P2MP TE LSPs R11: Reoptimization MUST be supported for P2MP TE LSPs as described for P2P LSPs in [RFC4657]. << There is a further request in this section that states "that a P2MP Path Computation Request SHOULD contain a parameter that allows the PCC to express a cost-benefit reoptimization threshold for the whole LSP as well as per destination". This seems like a sensible request. After all, why switch to a new path if the reoptimization request returns a path that's no better, or even worse, than the existing path? We support Objective Functions [RFC5541] in the P2MP Solutions document, and our solutions allows a path to be computed using a Shortest Path Tree (SPT) or Minimum Cost Tree (MCT), these will be processed according to the rules defined in RFC5541, but we do not currently have a "reoptimization threshold" function. Some of the authors of the P2MP Solution draft think the reoptimization threshold function is relevant to both P2P and P2MP, and threshold solution should be applicable to both P2P and P2MP. Therefore the current P2MP Solutions would state that this requirement will be resolved in a future document. We would really like to hear comments or suggestions regarding the threshold reoptimization function. Both from the perspective of a future solution that supports both P2P and P2MP, and/or this feature should be specifically part of the existing P2MP Solutions draft. Good question and for people having long memories, this was discussed almost 5 years ago (!). I had personally advocated for such a solution so I'm clearly in favor of it and I also believe that the same mechanism should apply to both P2P and P2MP. Of course, there might be a need for specific threshold in light of the OF. For example, if we end up defining an OF for P2MP according which the objective is to minimize the path cost difference between each leaf and the head-end (to guaranty fairness delivery for mcast traffic for example), we may need a P2MP specific threshold. So let's try to make the threshold mechanisms as generic and modular as possible. Back to your question I would suggest to leave it out from the P2MP solution draft and have a separate ID covering both the P2P and P2MP threshold solutions. Thanks. JP. Br, Dan/P2MP Solutions Authors. From: [email protected] [mailto:[email protected]] on Behalf Of JP Vasseur Sent: 07 December 2009 19:08 To: [email protected] Subject: [Pce] WG Last Call on I-D Action:draft-ietf-pce-p2mp-req-04.txt Dear WG, Although the discussion on this ID has been relatively moderate, the document has been stable for a while and discussed at several WG meetings. This starts a 2-week WG Last Call on I-D Action:draft-ietf-pce-p2mp-req-04.txt. Please send your comment to the authors and copy the list by Dec 15, noon ET. Thanks. JP and Julien. _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
