Hi Druhv, as I pointed out in mail,
in section 3.2 , when you talked about R flad in SRP, the fleg is new and is introduced in the following chapter. For me text should be: (2) In sec 3.2, OLD: To indicate a delete operation, the PCE MUST use the R flag in the SRP object in a PCUpd message. NEW: To indicate a delete operation, a new R flag is introduced in the SRP object and to be used in a PCInitiate message. Thanks Sergio -----Original Message----- From: Pce [mailto:[email protected]] On Behalf Of Dhruv Dhody Sent: lunedì 22 dicembre 2014 11:44 To: [email protected]; [email protected] Subject: Re: [Pce] WG Last Call on draft-ietf-pce-pce-initiated-lsp-02 and draft-ietf-pce-stateful-sync-optimizations-01 Hi All, > As planned, this message ignites a 3-week WG Last Call on both > draft-ietf-pce-pce-initiated-lsp-02 Support with following comments: (1) We should align the tone of the draft to http://tools.ietf.org/html/rfc7399#section-20 which differentiates between the recommendation for instantiation (this draft), and the actual (NMS like) instantiation of the LSPs (marked out of scope). This could either be done by a suitable text in Introduction and/or use of phrase 'recommend instantiation' in the document. (2) In sec 3.2, OLD: To indicate a delete operation, the PCE MUST use the R flag in the SRP object in a PCUpd message. NEW: To indicate a delete operation, the PCE MUST use the R flag in the SRP object in a PCInitiate message. I guess Ramon pointed this out already! (3) In sec 5.3.1, we are changing the meaning of the SPEAKER-IDENTITY-ID TLV, which was earlier used in OPEN to identify the exact PCEP-Speaker but now here it identifies the PCE that initiated the LSP. This looks like a hack, a better idea would be to define a new TLV type PCE-INITIATED-IDENTITY-ID with the same format. (4) Section 9.1, it says... Rapid flaps triggered by the PCE can also be an attack vector. This will be discussed in a future version of this document. The text for this needs to be added. (5) It would be nice to have a manageability consideration section. (6) Few lines on state synchronization should also be added - If the DB did not survive the PCC restart, PCE must send the PCE initiated message again. During state synchronization the PCE should get the status of PCE Initiated LSPs with C flag set in the LSP object. Incase of redelegation to a different PCE the same should be reported during state synchnronization with D=0. The original PCE should also be allowed to send PCInitiate to get back the delegation. (this is not allowed in the current text as PCInitiate with non-zero PLSP-ID is allowed only during State Timeout timer) Nits - Reference to 2119, as SHOULD, MUST are used in the document - Expand on first use LER, LSR etc - Reference to SRP, LSP, PLSP-ID as defined in [I-D.ietf-pce-stateful-pce] - section 3.2 s/PCinitiate/PCInitiate/ - section 4 s/A PCC indicates its ability.../A PCEP speaker indicates its ability/ (because both PCC and PCE needs to do this) - section 4.1 Type=16 should be removed as its TBD in the base document as well http://tools.ietf.org/html/draft-ietf-pce-stateful-pce-10#section-7.1.1 - section 4.1 OLD: If set to 1 by a PCE, the I flag indicates that the PCE will attempt to instantiate LSPs. NEW: If set to 1 by a PCE, the I flag indicates that the PCE can attempt to instantiate LSPs. > and draft-ietf-pce-stateful-sync- > optimizations-01. Support (As a co-author) Regards, Dhruv > 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 > [email protected]<mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/pce
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
