Subject: [Pce] Comments and questions of draft-ietf-pce-stateful-pce-00

From: Ramon Casellas <[email-masked]>
Date: Tue, 27 Mar 2012 16:19:23 +0200

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]          |           Length=12           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   IPv4 Tunnel Sender Address                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             LSP ID            |           Tunnel ID           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Session Address / IPv4 tunnel Endpoint (??)         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

- Extended tunnel ID: mentions 128 bits for v4?
  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)

* 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?

* "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.

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

Thanks and best regards

Ramon

---

From: Ina Minei <[email-masked]>
Date: Thu, 29 Mar 2012 11:31:05 -0700

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: [email-masked] [mailto:[email-masked]] On Behalf Of Ramon Casellas
Sent: Tuesday, March 27, 2012 7:19 AM
To: [email-masked]
Subject: [Pce] Comments and questions of draft-ietf-pce-stateful-pce-00

[snip]

* 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. 

* $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. 

- 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

### It's a good idea. We need to think some more how exactly to structure it. 

### It should not be there :-), will be updated

### 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

### Thank you for catching these, will fix in the next revision. 

Thanks and best regards

Ramon

_______________________________________________
Pce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pce