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 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? ### Good point. This is for the passive stateful PCE - the PCE should be able to correlate path computation requests with status updates coming from the PCC. Will update in the next version. 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)? ### Yes, thank you for catching this. 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] | Length=12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Tunnel Sender Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSP ID | Tunnel ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session Address / IPv4 tunnel Endpoint (??) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Extended tunnel ID: mentions 128 bits for v4? ### Good catch, this is a typo Extended Tunnel ID: contains the 128-bit 'Extended Tunnel ID' identifier defined in [RFC3209] --> Contains the 32 bit Session Address / IPv4 tunnel endpoint. Other & misc --------------------------- * Would you consider (variable sized) IF_ID ERROR_SPEC with TLVs rather than fixed Ects RROR_SPEC objeto 8 bytes? I believe that having TLVs to identify not only the failed (unnumbered) interface id but stacking failed elements as stated in RFC4920 (cranckback) is useful information for a stateful PCE which may be able to react faster than relying on the TED update mechanism (e.g. in the case of failure) ### It's a good idea. We need to think some more how exactly to structure it. * For $7.2.2 what happens if a LSP is re-routed and the LSPid chages due to, for example, make-before-break with SE and a new lspid? Can we change the LSPid in successive PCRpt messages as long as we mantain the 20-bit LSP identifier? * What is the semantic of the IRO object in a PCUpd message? ### It should not be there :-), will be updated * "Session-internal LSP-ID (20 bits): Per-PCEP session identifier for an LSP". I am confused by the qualification of "Per-PCEP session" identifier. In case of connection termination and reconnect, skipping sync, the identifier is kept the same. In other words, the id has to be kept the same for the lifetime of the connection, but it can go past that, right? OTOH nothing precludes a PCC to assign the same ses-internal LSP-ID to several PCEs, right? could you please clarify? -- in other words, I am not sure of the need to qualify on a per-PCEP session basis. ### Right. What we wanted to say is that it has meaning and stays the same for the duration of the PCEP session. Note that there is also an LSP Name, which is supposed to be persistent (i.e. survive between PCEP sessions). Typos and other nits =============================== $3.1.2 capitalize TED -> Out-of-band TED synchronization ... $3.1.2 grammar -> "and the and" $5.2 The PCRep message is described in $6.1 -> The PCRpt message is. ... $5.3 The PCEP protocol exensions for stateful PCEs MAY - would this be a MUST? $5.4 Incomplete sentence (see ) Figures 6,7,8 refer to a PCOpen message. I take it you mean Open? $5.6.1 mentions a "PC Reply" -> PCRep ? $5.6.2 the passive stateful PCE is the model for stateful PCE is described in ... -> as? $/.8 page 35 delegating the LSP the PCE -> to the PCE? - Align Figure 14 to 32 bits? why are you limiting to 16? padding needs to be included in any case. - Below Figure 18 caption: "the type of TLV is... and has a fixed length of 8 octets. It also says two fields? -> 4 fields, different size - Below Figure 19 caption: "the type of TLV is... and has a fixed length of 20 octets. It also says two fields) -> 4 fields, different size ### Thank you for catching these, will fix in the next revision. Thanks and best regards Ramon _______________________________________________ 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
