Hi Robert, See inline...
> -----Original Message----- > From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Robert Varga > Sent: 18 December 2014 20:15 > To: julien.meu...@orange.com; pce@ietf.org > Subject: Re: [Pce] WG Last Call on draft-ietf-pce-pce-initiated-lsp- > 02 and draft-ietf-pce-stateful-sync-optimizations-01 > > Hello, > > donning the implementer (as opposed to co-author) hat, I have > comments pertaining to draft-ietf-pce-pce-initiated-lsp, specifically > to Section 6. In general it seems to contradict the general outline > of the extension as stated in section 3.2 paragraph 4. > > The first paragraph clearly forbids the use of PCRpt D=0 for PCE- > initiated LSPs. It is not clear whether this restriction applies to > all PCRpts, or only the PCRpt solicited by the PCInitiate message. > Section 3.2 paragraph 4 seems to indicate this applies to solicited > PCRpts only, which is what makes sense. A clarification is definitely > needed. But http://tools.ietf.org/html/draft-ietf-pce-stateful-pce-10#section-5.5.1 says.. Note that for an LSP to remain delegated to a PCE, the PCC MUST set the Delegate flag to 1 on each LSP Status Report sent to the PCE. So the D flag must be set on all PCRpts (including the solicited (first) PCRpt and any other PCRpt message). I am not sure what text in section 3.2 paragraph 4 is an issue? > > The third paragraph seems to be replacing the normal delegation > mechanics with a PCInitiate-driven exchange. It does not specify > whether it is legal for a PCE to send PCUpd(D=1) after a session flap > or not. It feels like it is not legal and PCInitiate is intended to > fully replace it, but that would contradict section 3.2 paragraph 4. > This needs to be clarified. I think some clarification is needed. The text says.. In case of PCEP session failure, control over PCE-initiated LSPs reverts to the PCC at the expiration of the redelegation timeout. To obtain control of a PCE-initiated LSP, a PCE (either the original or one of its backups) sends a PCInitiate message, including just the SRP and LSP objects, and carrying the PLSP-ID of the LSP it wants to take control of. During state synchronization itself (full or incremental) the D flag could be set while reporting the status of PCE-Initiated LSP (with C flag set) if re-delegation is not done to another PCE. I feel the same behavior make sense for PCC-Initiated LSP as well incase one wants to delegate to the same PCE again after session down. It should not be mandatory to send PCInitiage message in all cases. Regards, Dhruv > > My preference would be to remove pretty much all of this paragraph, > bringing the mechanics to what section 3.2 outlines. Unfortunately > there are already some implementations deployed, so we need to factor > in the compatiblity with the installed base. Can we perhaps allocate > another bit in the Stateful PCE Capability TLV and mark the current > one as reserved/deprecated? > > Thanks, > Robert > > On 12/01/2014 06:18 PM, julien.meu...@orange.com wrote: > > Dear all, > > > > As planned, this message ignites a 3-week WG Last Call on both > > draft-ietf-pce-pce-initiated-lsp-02 and > > draft-ietf-pce-stateful-sync-optimizations-01. It will end on > Monday > > December 22 at 11:59 PM, HST. > > > > Please send your comments to the PCE mailing list. > > > > Thanks, > > > > JP & Julien > > > > > > > _____________________________________________________________________ > _ > > ___________________________________________________ > > > > > > Ce message et ses pieces jointes peuvent contenir des informations > > confidentielles ou privilegiees et ne doivent donc pas etre > diffuses, > > exploites ou copies sans autorisation. Si vous avez recu ce message > > par erreur, veuillez le signaler a l'expediteur et le detruire > ainsi > > que les pieces jointes. Les messages electroniques etant > susceptibles > > d'alteration, Orange decline toute responsabilite si ce message a > ete > > altere, deforme ou falsifie. Merci. > > > > This message and its attachments may contain confidential or > > privileged information that may be protected by law; they should > not > > be distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender > and > > delete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that > have > > been modified, changed or falsified. > > Thank you. > > > > _______________________________________________ > > Pce mailing list > > Pce@ietf.org > > https://www.ietf.org/mailman/listinfo/pce > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
