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

[Ramon Casellas <[e-mail]>]

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