Re: [Pce] WG Last Call on draft-ietf-pce-pce-initiated-lsp-02 and draft-ietf-pce-stateful-sync-optimizations-01
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:pce-boun...@ietf.org] On Behalf Of Dhruv Dhody Sent: lunedì 22 dicembre 2014 11:44 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 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 Pce@ietf.orgmailto:Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce ___ Pce mailing list Pce@ietf.orgmailto:Pce@ietf.org https
Re: [Pce] WG Last Call on draft-ietf-pce-pce-initiated-lsp-02 and draft-ietf-pce-stateful-sync-optimizations-01
On 12/22/2014 11:44 AM, Dhruv Dhody wrote: Hi Robert, Hello Dhruv, See inline 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). Right, but that would also mean that a PCE-initiated LSP cannot be reported to backup PCEs, as that would mean the LSP is delegated to multiple PCEs at the same time... I am not sure what text in section 3.2 paragraph 4 is an issue? The specific text is this: Once instantiated, the delegation procedures for PCE-initiated LSPs are the same as for PCC initiated LSPs as described in [I-D.ietf-pce-stateful-pce https://tools.ietf.org/html/draft-ietf-pce-pce-initiated-lsp-02#ref-I-D.ietf-pce-stateful-pce]. This applies to the case of a PCE failure as well. Which is precisely what I understand you are implying in your response below. 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 Bye, Robert 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
Re: [Pce] WG Last Call on draft-ietf-pce-pce-initiated-lsp-02 and draft-ietf-pce-stateful-sync-optimizations-01
for which the C flag is 0, the TLV MUST be ignored the PCC MUST send a PCErr message with Error- type 23 (Bad parameter value) and error value 2 (Speaker identity included for an LSP that is not PCE-initiated). To ease procedure, why not allow it? this can be set to the PCC SPEAKER-IDENTITY-ID for that matter, or simply ignored, it can be up to the PCE. Why is the error necessary here? Section 5.4: - OLD: If the PLSP-ID specified in the PCInitiate message was not created by the PCE, the PCC MUST send a PCErr message indicating LSP is not PCE initiated (Error code 19, error value TBD). - NEW: If the PLSP-ID specified in the PCInitiate message was not created by a PCE, the PCC MUST send a PCErr message indicating LSP is not PCE initiated (Error code 19, error value TBD). (In case of multiple PCEs) - TLV presence rules are missing: - is symbolic path name, lsp identifiers, ..etc allowed or ignored? - does it make sense to allow the SPEAKER-IDENTITY TLV for debugging purpose in the subsequent PCRpt ? Section 6: - For the delegation bit, adding to the PCE the LSP is delegated to would make the text more clear - What does contains the PCErr message of type 19 (Invalid Operation) and value TBD Delegation for PCE-initiated LSP cannot be revoked? I believe it should at least contains the LSP object. - 'A PCE MAY return a delegation to the PCC, to allow for LSP transfer between PCEs. Doing so MUST trigger the State Timeout Interval timer ([I-D.ietf-pce-stateful-pce]).' the state timeout interval is defined as time period before flushing LSP state associated with that PCEP session (in case of session closed) In the context of a PCE returning the delegation, the State Timeout interval should only apply to the LSP, not the the state associated to the session. This should be stated - To obtain control of a PCE-initiated LSP, a PCE (either the original or one of its backups) sends a PCInitiate message, ... It feels a bit of a patch, I believe the PCC can redelegate the LSP to the original PCE or to the preferred PCE by itself (Policies and SPEAKER-IDENTITY-ID would allow for that), rather than adding an exception (who wins in case the timeout is long and several PCEs connect at the same time, for say a network failure?) Section 8. - Missing the new bit definition of Section 4.1. Stateful PCE Capability TLV (according to draft-ietf-pce-stateful-pce-10, section 8.6.) I : bit 29 - Missing the new bit definition of Section 5.2. The R flag in the SRP Object - The bit number should be defined (bit 31), should a new registry be defined at this point? Section 8.3 - As described before, error-type=23, error-value=2 is not needed - Error-type=24, error-value=3 : OLD: RSVP signaling error , NEW: signaling error The type of error is included in the TLV, Restricting the error to RSVP is too stong. Section 9.1: Rapid flaps triggered by the PCE can also be an attack vector. This will be discussed in a future version of this document. Its rather time to document them The exception mechanism also introduce another attack (restart the session and steal LSPs) Was the END-POINTS under PCE control considered? This would allow a malicious PCE to strain other AS/domains. On 22 December 2014 at 05:59, BELOTTI, SERGIO (SERGIO) sergio.belo...@alcatel-lucent.com wrote: 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:pce-boun...@ietf.org] On Behalf Of Dhruv Dhody Sent: lunedì 22 dicembre 2014 11:44 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 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
Re: [Pce] WG Last Call on draft-ietf-pce-pce-initiated-lsp-02 and draft-ietf-pce-stateful-sync-optimizations-01
Hi Robert, (snip) 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). Right, but that would also mean that a PCE-initiated LSP cannot be reported to backup PCEs, as that would mean the LSP is delegated to multiple PCEs at the same time... [Dhruv]: A clarification that one is referring to the PCE that initiated the LSP in the paragraph should clear that up. I am not sure what text in section 3.2 paragraph 4 is an issue? The specific text is this: Once instantiated, the delegation procedures for PCE-initiated LSPs are the same as for PCC initiated LSPs as described in [I-D.ietf-pce-stateful-pcehttps://tools.ietf.org/html/draft-ietf-pce-pce-initiated-lsp-02#ref-I-D.ietf-pce-stateful-pce]. This applies to the case of a PCE failure as well. Which is precisely what I understand you are implying in your response below. [Dhruv]: 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 Bye, Robert 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.commailto: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.orgmailto:Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] WG Last Call on draft-ietf-pce-pce-initiated-lsp-02 and draft-ietf-pce-stateful-sync-optimizations-01
Hit sent by mistake while I was still typing my response, jumping directly to it inline... snip I am not sure what text in section 3.2 paragraph 4 is an issue? The specific text is this: Once instantiated, the delegation procedures for PCE-initiated LSPs are the same as for PCC initiated LSPs as described in [I-D.ietf-pce-stateful-pcehttps://tools.ietf.org/html/draft-ietf-pce-pce-initiated-lsp-02#ref-I-D.ietf-pce-stateful-pce]. This applies to the case of a PCE failure as well. Which is precisely what I understand you are implying in your response below. [Dhruv]: I guess the basic delegation procedure is same, but the difference comes out in revoking of delegation, re-delegation etc, so I agree a better clarifying text is needed. snip Regards, Dhruv ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] WG Last Call on draft-ietf-pce-pce-initiated-lsp-02 and draft-ietf-pce-stateful-sync-optimizations-01
Hi, I have the following comments on draft-ietf-pce-stateful-sync-optimizations-01. Section 3 : The documents proposes different optimizations, spending a paragraph or two to describe the different optimizations, then a list of extensions, and finish with procedures would help. Section 3.2 - A bit INCLUDE-DB-VERSION (IDB) is defined, section 7 defines the S bit. Section 3.2.2 - OLD: The type of the TLV is [TBD] and it has a a variable length, which MUST be greater than 0 and padded to 4-octet alignment (, and padding is not included in the Length field). NEW: The type of the TLV is [TBD] and it has a a variable length, which MUST be greater than 0. The Value is padded to 4-octet alignment. The padding is not included in the Length field The value field is padded, not the lenght Section 4. - Incremental is not allowed, because Paragraph 6 of section 3.2 indicates: Otherwise, the PCC MUST perform state synchronization to the stateful PCE. Section 3.2 should take into consideration all the bits defined, moving the procedures after all the object definition would allow for an easier understanding. - proposes- defines Section 4.2. - Figure 7: I believe this is the D flag, not the T flag Section 5. The use case is different from section 6, but they use the same bit to advertize that capability, so if T bit is set, the PCC MUST/SHOULD/MAY wait the trigger from the PCE?? Section 6.2. - OLD: The PCC MUST respond with a PCRpt message and SHOULD include the SRP-ID-number of the PCUpd that triggered the resynchronization. NEW: The PCC MUST respond with a PCRpt message with the LSP state, SYNC Flag set to 0 and MUST include the SRP-ID-number of the PCUpd that triggered the resynchronization. SHOULD - MUST. draft-ietf-pce-stateful-pce-10, section 5.6.2 indicates that the PCRpt MUST include the SRP id in the subsequent PCErr or PCRpt. I see no justification in the text to change the mechanism described in draft-ietf-pce-stateful-pce-10. The SYNC flag MUST be set to 0, otherwise it may be confused with a full sync. - I believe all those updates are scoped only to the session that triggered the delta/PCE triggered sync, adding it explicitly would be good, as its a change in the PCRpt mechanism of the PCC. - What happens if the PCE sends multiple resync requests while the a full resync is in progress? Section 7: - This should under section 3.3. PCEP Extensions, and refer to the section defining the bit behavior, - D bit requires the S bit to be set, correct? A corresponding error is missing - The behavior of T bit is not clear, see comment of section 5. - T bit and DS bit combination : it seems the T bit behavior does not depend on the INCLUDE-DB-VERSION and Delta, so it can be set independently. This should be specified. Manageability section is missing. Section 8.3. Suggested values are off, 29 is the suggested value of the I bit of draft-ietf-pce-pce-initiated-lsp-02. I believed this should be: TBD(suggested value 27) DELTA-LSP-SYNC-CAPABILITY This document TBD(suggested value 28) TRIGGERED-SYNC This document TBD(suggested value 30) INCLUDE-DB-VERSION This document Section 9. The document introduces new messages that may introduce load on the PCC, a malicious PCE may flood the PCC with resync requests, this should be mentioned. On 1 December 2014 at 12:18, 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
Re: [Pce] WG Last Call on draft-ietf-pce-pce-initiated-lsp-02 and draft-ietf-pce-stateful-sync-optimizations-01
could be usefull, its now distributed over different sections and levels. Section 5.3.1. - Is there any specific reason to have the flag defined as a subsection of the instantiation procedure rather than a separate section as the R flag? - Nits : draft-ietf-pce-stateful-pce-10 define Flag, the document defines Flags, name should be aligned - If the TLV appears for an LSP for which the C flag is 0, the TLV MUST be ignored the PCC MUST send a PCErr message with Error- type 23 (Bad parameter value) and error value 2 (Speaker identity included for an LSP that is not PCE-initiated). To ease procedure, why not allow it? this can be set to the PCC SPEAKER-IDENTITY-ID for that matter, or simply ignored, it can be up to the PCE. Why is the error necessary here? Section 5.4: - OLD: If the PLSP-ID specified in the PCInitiate message was not created by the PCE, the PCC MUST send a PCErr message indicating LSP is not PCE initiated (Error code 19, error value TBD). - NEW: If the PLSP-ID specified in the PCInitiate message was not created by a PCE, the PCC MUST send a PCErr message indicating LSP is not PCE initiated (Error code 19, error value TBD). (In case of multiple PCEs) - TLV presence rules are missing: - is symbolic path name, lsp identifiers, ..etc allowed or ignored? - does it make sense to allow the SPEAKER-IDENTITY TLV for debugging purpose in the subsequent PCRpt ? Section 6: - For the delegation bit, adding to the PCE the LSP is delegated to would make the text more clear - What does contains the PCErr message of type 19 (Invalid Operation) and value TBD Delegation for PCE-initiated LSP cannot be revoked? I believe it should at least contains the LSP object. - 'A PCE MAY return a delegation to the PCC, to allow for LSP transfer between PCEs. Doing so MUST trigger the State Timeout Interval timer ([I-D.ietf-pce-stateful-pce]).' the state timeout interval is defined as time period before flushing LSP state associated with that PCEP session (in case of session closed) In the context of a PCE returning the delegation, the State Timeout interval should only apply to the LSP, not the the state associated to the session. This should be stated - To obtain control of a PCE-initiated LSP, a PCE (either the original or one of its backups) sends a PCInitiate message, ... It feels a bit of a patch, I believe the PCC can redelegate the LSP to the original PCE or to the preferred PCE by itself (Policies and SPEAKER-IDENTITY-ID would allow for that), rather than adding an exception (who wins in case the timeout is long and several PCEs connect at the same time, for say a network failure?) Section 8. - Missing the new bit definition of Section 4.1. Stateful PCE Capability TLV (according to draft-ietf-pce-stateful-pce-10, section 8.6.) I : bit 29 - Missing the new bit definition of Section 5.2. The R flag in the SRP Object - The bit number should be defined (bit 31), should a new registry be defined at this point? Section 8.3 - As described before, error-type=23, error-value=2 is not needed - Error-type=24, error-value=3 : OLD: RSVP signaling error , NEW: signaling error The type of error is included in the TLV, Restricting the error to RSVP is too stong. Section 9.1: Rapid flaps triggered by the PCE can also be an attack vector. This will be discussed in a future version of this document. Its rather time to document them The exception mechanism also introduce another attack (restart the session and steal LSPs) Was the END-POINTS under PCE control considered? This would allow a malicious PCE to strain other AS/domains. On 22 December 2014 at 05:59, BELOTTI, SERGIO (SERGIO) sergio.belo...@alcatel-lucent.com wrote: 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:pce-boun...@ietf.org] On Behalf Of Dhruv Dhody Sent: lunedì 22 dicembre 2014 11:44 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 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
Re: [Pce] WG Last Call on draft-ietf-pce-pce-initiated-lsp-02 and draft-ietf-pce-stateful-sync-optimizations-01
El 01/12/2014 a las 18:18, julien.meu...@orange.com escribió: Dear all, As planned, this message ignites a 3-week WG Last Call on both draft-ietf-pce-pce-initiated-lsp-02 Hi authors, all, A fast review of the draft, please note: * Error: To indicate a delete operation, the PCE MUST use the R flag in the SRP object in a PCUpd message. As a result of the deletion request, the PCC MUST remove all state related to the LSP, and send a PCRpt with the R flag set in the LSP object for the removed state it should be PCInitiate, as later described in Section 5.4 PCE-initiated removal of a PCE-initiated LSP is done by setting the R (remove) flag in the SRP Object in the PCInitiate message from the PCE. as well as the RBNF (note that, personally I would favor being picky as in in the SRP object of the PCE-initiated-lsp-instantiation within the PCInitiate message etc. notably when multiple lsp requests can be in a message) * Confused by the sentence Every request from the PCE receives a new SRP-ID-number. This number is unique per PCEP session and is incremented each time an operation (initiation, update, etc) is requested from the PCE i.e., the unicity-per-session (although the intent is clear) * Indent 0,1,2,3 digits to describe bit position in the SRP object format. * Minor nit: IANA considerations section should mention new R flag in SRP. * Error-value=13: LSP cleanup TLV missing - this looks like a leftover from an old version? * I would have some very minor comments about error conditions, hopefully triggering some discussion - I am a bit confused about the differences between ET=19 -Invalid operation- and ET=24 -LSP instantiation error- (Is the error a result of an invalid operation? ;) - Why is non-zero plsp-id an invalid operation rather than a bad parameter value? - Why is Speaker identity included for an LSP that is not PCE-initiated a bad parameter rather than an invalid operation? - Why is there a type bad parameter value yet the error unacceptable instantiation parameters a value within the instantiation error type? I am aware there may be deployments and changing this may be problematic, Best regards Ramon ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
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. 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. 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
Re: [Pce] WG Last Call on draft-ietf-pce-pce-initiated-lsp-02 and draft-ietf-pce-stateful-sync-optimizations-01
Support as co-author. On Mon, Dec 1, 2014 at 9:18 AM, 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
Re: [Pce] WG Last Call on draft-ietf-pce-pce-initiated-lsp-02 and draft-ietf-pce-stateful-sync-optimizations-01
Support. - Hari On 01/12/2014 17:18, julien.meu...@orange.com 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
Re: [Pce] WG Last Call on draft-ietf-pce-pce-initiated-lsp-02 and draft-ietf-pce-stateful-sync-optimizations-01
Support on both On 12/2/14, 11:49 AM, Hariharan Ananthakrishnan h...@packetdesign.com wrote: Support. - Hari On 01/12/2014 17:18, julien.meu...@orange.com 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
Re: [Pce] WG Last Call on draft-ietf-pce-pce-initiated-lsp-02 and draft-ietf-pce-stateful-sync-optimizations-01
Yes/support Cheers, Jeff -Original Message- From: julien.meu...@orange.com julien.meu...@orange.com Organization: Orange Date: Monday, December 1, 2014 at 9:18 AM To: pce@ietf.org pce@ietf.org Subject: [Pce] WG Last Call on draft-ietf-pce-pce-initiated-lsp-02 and draft-ietf-pce-stateful-sync-optimizations-01 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
