Hi Adrian, Thanks for the response.
Please see below. Dean > -----Original Message----- > From: Adrian Farrel [mailto:[EMAIL PROTECTED] > Sent: Friday, September 08, 2006 6:07 AM > To: Dean Cheng (dcheng); [EMAIL PROTECTED] > Subject: Re: [Pce] Fw: Posting of draft-yasukawa-pce-p2mp-req-01.txt > > Hi Dean, > > Thanks for your thoughts: > > > 1) Relate to Section 2.1.1/2.1.2/2.1.3 > > > > In case a path computation is required just for > > a P2P "short path" (could be a branch of a P2MP LSP, > > such as a last segment leading to a leaf node) > > where the semantics is not that different from > > a simple P2P path, it would be possibly be performed > > just by a PCE that is not capable of computing > > P2MP path in general. > > > > If this is correct, this PCE does not need to > > know the requested path is part of a P2MP LSP, > > as long as there is no P2MP specific parameters > > contained in the PCEP request message. On the > > other hand, the PCC in this case does not need to > > include P2MP specific parameters in the request message. > > I'm a bit confused. Are you talking about adding a branch > (e.g. adding a > leaf) into an existing P2MP tree? > > There are two questions to be addressed when you do that: > 1. Choice of branch node in order to optimise the path from > the tree to the leaf. > 2. Choice of path from tree to the leaf considering the > constraints on the whole tree. > > But, if the choice of 1 is determined simply by running CSPF > from root to leaf, and if the choice of 2 is determined > simply by running CSPF from branch to leaf, then you are > correct. However: > > a. This is a really BIG "if" that doesn't (or shouldn't) > apply to P2MP TE path computation b. If that is what you > want, then you are not doing a P2MP computation and this I-D > simply doesn't apply. What I meant is that sometimes there is a need to compute a P2P LSP that is part of a P2MP LSP, and when that occurs, the PCC (although it knows the P2P LSP is a part of a P2MP LSP) may need just to ask a PCE for a route for that P2P LSP, where the PCEP message does not need to contain any P2MP specific paremeters, which the PCE may not understand, and the PCE only needs to compute a P2P path. This P2P LSP may be between a branch node and a leaf node, or between a intermediate node and a branch node (a trunk path), etc. One other reason doing so may be because a PCC has learnt that some PCEs cannot compute routes for a P2MP LSP as a whole during discovery process. But (as you suggested) in this case, it has nothing to do with this I-D; but it may be helpful to add one sentence for this scenario to clarify. > > > 2) Section 2.1.9 > > > > The 3rd line of the second paragraph. > > > > "availablity" => "availability" > > Thanks. > > > 3) Section 2.1.10 > > > > The second word. > > > > "varitation" => "variation" > > Thanks. > > > 4) Section 2.1.10 > > > > 4a) For leaf additions, in addition to the "indications" > > included in the PCEP request message, as listed in > > current text (three bullets now), the following may > > also be useful: > > > > - Which branch nodes currently on the P2MP LSP must > > still or must not be used. > > Yes? Can you suggest why this would be useful? > I can see that when you place a P2MP LSP you might want to > constraint the branches, to come from a set, but why would > you want this specific function? > > No problem adding this PCECP requirement, but I just want to > be able to back it up with an underlying functional requirement. I think this is a policy based function. The default for optimization of a tree/subtree is relying on the PCE's computation algorithm. But a policy may be imposed so that an existing branch node must stay as is (even a better option exists), or the opposite. > > > - The subtree rooted at a specific branch node currently > > on the P2MP LSP must not be recomputed. > > That is good, I think. > > > - The subtree rooted at a specific branch node currently > > on the P2MP LSP may be recomputed for re-optimization > > purpose. > > Converse of above. > Yes. Yes the two above can be combined as one with an "or". > > > 4b) If modification/optimization occurs when deleting one > > or more leaf nodes, some of the "indications" currently > > listed for leaf additions (include the 4a above) are > > equally applied. If agreed, perhaps these indications > > should be listed for both cases (certainly, indications > > for which leaf nodes are to be added or deleted need > > to be specifically expressed), for simplicity. > > Yes. Makes sense. > > > 5) Section 4 > > > > For security and confidentiality, there may be special > > considerations for P2MP LSP using PCE. For example, > > subtrees that have the same root or branch node may be in > > different areas/domains such that the handling/requirements > > for confidentiality/security are different, and therefore PCE > > and PCEP must be able to deal with it. > > Right. > These things probably need to be brought out in their own section. > I suspect that what you are suggesting is that it MUST be > possible to require that the tree has no more than one entry > point into any domain? And possibly other issues. Yes, the number of entries and which ones are security concerns and should be part of the constraints for path findings. > > Do you want to have a go at some text for that? Sure, I'll propose some text for that. > > > Many thanks. > > If you want to bring ay or all of this to the PCE mailing > list, that would be really helpful. OK > > Cheers, > Adrian > _______________________________________________ Pce mailing list [email protected] https://www1.ietf.org/mailman/listinfo/pce
