[Pce] Comments and questions of draft-ietf-pce-stateful-pce-00
Dear Edward, co-authors, all, Although a bit later than I had hoped, please find below some comments / questions on your stateful PCE draft (draft-ietf-pce-stateful-pce-00) I hope they are useful, and your answers / clarifications are much appreciated. We can discuss after the PCE session specially if I don't make any sense :) General Comments / Questions === * A first question / comment is whether you plan to focus exclusively on MPLS networks or whether you would also consider including GMPLS in general. In my humble opinion, there is no strong reason to exclude GMPLS, although this may have some implications on the proposed protocol extensions (e.g. notably, the use of the RFC5440 4-byte floating point PCEP BANDWIDTH object could be replaced by e.g. a GENERALIZED_BANDWIDTH, or the fixed-size RSVP-TE ERROR_SPEC). As it is now, it cannot be directly implemented / deployed in e.g our WSON. * Minor comment: although at the end it is a matter of taste ;-) I am not fond of the naming scheme for your proposed messages. Reporting about LSP state or Updating an LSP is, to some extent, not directly related to "Path Computation". For example, your message named "Path Computation State Report", that reports the status of an LSP, is confusing IMHO and the prefix "Path Computation" could be removed. Would you consider a naming scheme more in the lines of, e.g. "LSP State Report" (LSPRpt) or "LSP Update Request" (LSPUpd)?. As a side note, it would be slightly less error prone since we have now PCReq / PCRep / PCRpt / PCUpd. In my personal preference, I would only qualify messages with Path Computation if they are actually related to the Path Computation procedure itself (although I admit that it is not always the case, for example, PCNtf messages that do not refer to a given request). State Cleanup --- * I guess you will address state cleanup more deeply in a newer version (in $5.8 you mention state cleanup after session termination) although I am not sure how this coexists with maintaining state between sessions - In short, what would be the suggested procedure? after the (persistent) connection is terminated for some reason, a PCC/PCE is supposed to maintain the state for a given period of time, which is greater than the Delegation Timeout? Also, how do you recognize a given PCC that reconnects after a (persistent) connection was terminated? I am not sure whether some kind of PCC identifier would be needed, since in a given host, several entities may behave as PCCs at different times from the same IP address using ephemeral ports. Recognizing a (Reconnecting) PCC by its IP address may not be a good idea (and for multi-homed hosts, it may change). Do you think a say TLV in the OPEN message or a PCC_REQ_ID as in Monitoring could be necessary to unambiguously identify a PCC? -- I believe that the tuple (PCC_REQ_ID, Session-internal LSPid) may be needed to unambiguously identify an LSP. I would not rely on the IP address of the TCP connection to identify a client. Delegation and Revocation - * $5.2.2 "When a PCC's PCEP session with the PCE terminates, the PCC SHALL wait a time interval specified in 'Delegation Timeout Interval' and then revoke all LSP delegations to the PCE" -> I am not sure I understand this part. If the session is terminated, how does the PCC revoke? it just assumes that the PCE is no longer responsible for the LSPs and a PCE will do something similar? In other words, I was confused by the sentence "A PCC may revoke this delegation at any point during the lifetime of the PCEP session", yet the timer refers to a procedure that happens after the termination of the connection. If the connection is reestablished before the Delegation Timeout Interval runs out, and sync is skipped, delegations are assumed to stay as they were and the timer is stopped? what if the timer runs out while the PCEP peers are handshaking? don't we risk cases where the actual delegation could be undefined? Object ordering * The draft mandates a given object ordering but it does not specify the position of the LSP object within PCReq and PCRep messages (stated in $7.2). Where would you suggest adding the LSP object? LSP identifiers * I am a bit lost by Figures 18 and 19: it looks like a merge of SENDER_TEMPLATE and SESSION objects, but I am not sure it is correct. When using LSP_TUNNEL session from RFC3209, the Extended tunnel id is typically either set to 0 or using the ingress node. Your object also refers to the Tunnel Sender Address, which is also again the LSP ingress node. Did you mean IPv4 tunnel endpoint (i.e. Session address)? 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=[TBD] |
Re: [Pce] Comments and questions of draft-ietf-pce-stateful-pce-00
Ramon, Thank you for the thorough review and feedback. Please find the consolidated answers from the authors inline below, look for ###. Thank you, Ina -Original Message- From: pce-boun...@ietf.org [mailto:pce-boun...@ietf.org] On Behalf Of Ramon Casellas Sent: Tuesday, March 27, 2012 7:19 AM To: pce@ietf.org Subject: [Pce] Comments and questions of draft-ietf-pce-stateful-pce-00 [snip] General Comments / Questions === * A first question / comment is whether you plan to focus exclusively on MPLS networks or whether you would also consider including GMPLS in general. In my humble opinion, there is no strong reason to exclude GMPLS, although this may have some implications on the proposed protocol extensions (e.g. notably, the use of the RFC5440 4-byte floating point PCEP BANDWIDTH object could be replaced by e.g. a GENERALIZED_BANDWIDTH, or the fixed-size RSVP-TE ERROR_SPEC). As it is now, it cannot be directly implemented / deployed in e.g our WSON. ### You are right, we do not want to exclude GMPLS, and this was brought up during the last review as well. Addressing different profiles (e.g. MPLS, GMPLS) should be possible within the same framework, and should probably be addressed in separate drafts. * Minor comment: although at the end it is a matter of taste ;-) I am not fond of the naming scheme for your proposed messages. Reporting about LSP state or Updating an LSP is, to some extent, not directly related to "Path Computation". For example, your message named "Path Computation State Report", that reports the status of an LSP, is confusing IMHO and the prefix "Path Computation" could be removed. Would you consider a naming scheme more in the lines of, e.g. "LSP State Report" (LSPRpt) or "LSP Update Request" (LSPUpd)?. As a side note, it would be slightly less error prone since we have now PCReq / PCRep / PCRpt / PCUpd. In my personal preference, I would only qualify messages with Path Computation if they are actually related to the Path Computation procedure itself (although I admit that it is not always the case, for example, PCNtf messages that do not refer to a given request). ### This is a good suggestion, will update in the next version. State Cleanup --- * I guess you will address state cleanup more deeply in a newer version (in $5.8 you mention state cleanup after session termination) although I am not sure how this coexists with maintaining state between sessions - In short, what would be the suggested procedure? after the (persistent) connection is terminated for some reason, a PCC/PCE is supposed to maintain the state for a given period of time, which is greater than the Delegation Timeout? Also, how do you recognize a given PCC that reconnects after a (persistent) connection was terminated? I am not sure whether some kind of PCC identifier would be needed, since in a given host, several entities may behave as PCCs at different times from the same IP address using ephemeral ports. Recognizing a (Reconnecting) PCC by its IP address may not be a good idea (and for multi-homed hosts, it may change). Do you think a say TLV in the OPEN message or a PCC_REQ_ID as in Monitoring could be necessary to unambiguously identify a PCC? -- I believe that the tuple (PCC_REQ_ID, Session-internal LSPid) may be needed to unambiguously identify an LSP. I would not rely on the IP address of the TCP connection to identify a client. ### Your suggestion for an identifier for the PCC makes sense. State cleanup will be addressed more fully in the next version. Delegation and Revocation - * $5.2.2 "When a PCC's PCEP session with the PCE terminates, the PCC SHALL wait a time interval specified in 'Delegation Timeout Interval' and then revoke all LSP delegations to the PCE" -> I am not sure I understand this part. If the session is terminated, how does the PCC revoke? it just assumes that the PCE is no longer responsible for the LSPs and a PCE will do something similar? In other words, I was confused by the sentence "A PCC may revoke this delegation at any point during the lifetime of the PCEP session", yet the timer refers to a procedure that happens after the termination of the connection. If the connection is reestablished before the Delegation Timeout Interval runs out, and sync is skipped, delegations are assumed to stay as they were and the timer is stopped? what if the timer runs out while the PCEP peers are handshaking? don't we risk cases where the actual delegation could be undefined? ### The delegation timeout is for state cleanup on a session failure. The timer should be stopped the moment there is another delegation request on this LSP. We need a better name for this timer too, the current name is confusing. Object ordering * The d
