Hi,
As I understand this discussion, the resolution is that there is no change
needed to the P2MP Requirements draft.
So WG last call completed without any changes needed.
Ready to move on?
Cheers,
Adrian
----- Original Message -----
From: "JP Vasseur" <[email protected]>
To: "Daniel King" <[email protected]>
Cc: <[email protected]>
Sent: Thursday, December 17, 2009 6:17 PM
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 it’s 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
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
