Hi Dhruv, Doing my archivist's job for her, I find two emails from you not responded.
Sorry. Herewith, number 1 A > -----Original Message----- > From: Dhruv Dhody [mailto:[email protected]] > Sent: 03 October 2013 10:40 > To: [email protected] > Cc: [email protected] > Subject: RE: [Pce] I-D Action: draft-ietf-pce-questions-01.txt > > Hi, > > Some comments inline! > > Also I made comments during the adoption call [http://www.ietf.org/mail- > archive/web/pce/current/msg03168.html]. Some of the editorial comments have > been handled and would like to know the Author's opinion on the rest. > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] On Behalf Of > > Adrian Farrel > > Sent: 02 October 2013 20:42 > > To: [email protected] > > Subject: Re: [Pce] I-D Action: draft-ietf-pce-questions-01.txt > > > > Hi, > > > > I did an update to this I-D to clean up the typos and references. No new text > > of substance. > > > > It would be really good if people could comment on which issues are not clear, > > and also suggest additional questions to be answered by the document. > > > > During the discussion of adoption by the WG, Xian said: > > > (snip) > > > > > 2: In Section 3, it states > > > "Note that this exchange of PCE capabilities is in the form of an > > > announcement, not a negotiation. That is, a PCC that wants specific > > > function from a PCE must examine the advertised capabilities and > > > select which PCE to use for a specific request. There is no scope > > > for a PCC to request a PCE to support features or functions that it > > > does not offer or announce." > > > > > > From what we currently have in Section 5.3 of draft-ietf-pce-stateful- > > > pce-04, it seems to me that LSP modification capability is negotiated > > > *not* advertised. > > > The reason is obvious since it is a two-way thing. Just wonder whether > > > phrase likes "stateful PCE capability negotiation" in the WG draft or the > > > text above should be modified to avoid confusion? > > > > I went back and read section 5.3 of the -06 version of the draft. I agree > > that the PCE and PCC "negotiate" which functions they are going to use, but > > only in the sense that they each say whether they support the features and, > > if they both do, they agree to use them. Thus, just as with PCEP pre-stateful > > extensions, the speakers are announcing their capabilities, not requesting a > > service of choosing from a set of available features. I reckon that doesn't > > count as negotiation. > > > > Thoughts? > > > [DD] I agree! And I suggest [draft-ietf-pce-stateful-pce] section 5.3 should be > renamed to Capability Advertisement. OK, but out of scope for this document > > > 3: Section 18, it states > > > LSP delegation [I-D.ietf-pce-stateful-pce] is the process where a PCC > > > (usually an ingress LSR) passes responsibility for triggering > > > reoptimization or re-routing of an LSP to the PCE." > > > > > > LSP delegation covers wider purpose than stated above, right? For > > > example providing protection paths, as described in draft-ietf-pce- > > > stateful-pce-00. > > > > I don't agree with this. > > Delegation (according to the -06 version) grants the PCE rights to modify the > > parameters of an LSP. > > I don't see how this is related to providing protection paths. > > I suppose that one could set up two LSPs without worrying about whether they > > share resources, and then delegate them to the PCE to sort them out and make > > them disjoint. Seems a bit extreme to me. > > > > Furthermore, section 5.7 of draft-ietf-pce-stateful-pce-06 says... > > > > LSP protection and interaction with stateful PCE, as well as the > > extensions necessary to implement this functionality will be > > discussed in a separate draft. > > > [DD]Going back to the original text (and not focusing on protection), I mentioned > in my earlier mail... > > This sections gives an impression that the delegation of LSP > can only be done once the LSP is setup and then LSR (PCC) passes > responsibility for triggering reoptimization or re-routing of an > LSP to the PCE. In case of a new tunnel configuration with > delegation enabled, IMHO the PCC should be able to delegate > even when it has no path right now. > > I suggest rewording to not limit delegation to "passing responsibility for triggering > reoptimization or re-routing". > Maybe use the wording of the draft-ietf-pce-stateful-pce-06: > > "LSP delegation [I-D.ietf-pce-stateful-pce] is the process where > a PCC (usually an ingress LSR) grants the right to update LSP > attributes of an LSP to the PCE." Well, I don't call that delegation. Others may disagree, but I don't see any difference between what you described as "delegation before LSP establishment" and any other request to the Active PCE to cause an LSP to be set up. I think there is also some subtlety in the text you quoted from the stateful PCE draft. Is a PCC obliged to act on the update it receives from a PCE? I think there is always the case where the PCC tries to act, but fails for some reason (for example, there has been a change in the network in the meantime). So we have the possibility for the PCC to say "sorry, but no." So the only question is whether the PCC can say that for its own reasons. I believe the answer is "yes" and the magic unicorn in this picture is called "Policy". A _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
