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. > > 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." (snip) Regards, Dhruv --------------------------------------------------------------- Dhruv Dhody System Architect, Huawei Technologies India Pvt. Ltd., Banagalore Mobile: +91-9845062422 This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
