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
_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
