Hi Adrian,
Thanks for the detailed review. We'll soon propose a text for the
Manageability and Security sections. In the meantime, let me know if this
addresses all your comments/suggestions.
On 8/8/08 1:40 PM, "Adrian Farrel" <[EMAIL PROTECTED]> wrote:
>
>
>
>
> Hi,
>
>
>
> In Dublin, JP indicated that the authors of this I-D thought it was pretty
> much
>
> ready for working group last call, so here is my review as WG chair before we
> get
>
> into the business of a last call.
>
>
>
> I think there are sections still needing to be filled in.
>
Skipping the comments that have been addressed.
> ===
>
> Abstract
>
> s/where a domain is referred to as/where a domain referrs to/
>
> s/PCE-based environments/PCE-based environments,/
>
> s/states, statistics/states, and statistics/
>
> ===
>
> 1. Terminology
>
> Please re-order sections so that Section 1 is the Introduction.
>
> This will mean that you need to expand all of the acrinyjms in the
> Introduction.
>
>
>
> On the other hand...
>
>
>
> AS: Autonomous System.
>
> Not used in the document.
>
>
>
> LSR: Label Switching Router.
>
> Not used in the document.
>
>
>
> TED: Traffic Engineering Database.
>
> Not used in the document.
>
> ===
>
> 2. Introduction
>
> s/where a domain is referred to as/where a domain referrs to/
>
> s/states, statistics/states, and statistics/
>
>
>
> This document specifies procedures and extensions to the Path
>
> Computation Element Protocol (PCEP) ([I-D.ietf-pce-pcep]) in order to
>
> monitor the path computation chain and gather various performance
>
> metrics.
>
> I think you need to introduce the concept of a âpath computation chainâ
> before
>
> talking about monitoring it. I would simply move this paragraph to after the
> next
>
> paragraph, but even then the term is not clearly explained. There is a good
>
> paragraph in section 3.1.
>
>
Yes, I added the following paragraph:
As defined in [RFC4655], there are circumstances where more than one
PCE is involved in the computation of a TE LSP. A typical example is
when the PCC requires the computation of a TE LSP where the head-end
and the tail-end of the TE LSP do not reside in adjacent domains and
there is no single PCE with the visibility of both the head-end and
tail-end domain. We call path computation chain the set of PCEs
involved in the computation of a TE LSP. As further discussion in
Section 3.1, the PCE chain may either be static (pre-configured) or
dynamically determined during the path computation process.
>
> 3.1. Path Computation Monitoring Request message (PCMonReq)
>
>
>
> You need to mention how this message will be handled by a âlegacyâ PCE
> that
>
> does
>
> not recognise the message. Also how it would be handled by a PCC.
>
Suggestion:
In PCEP,
Add: "A PCEP implementation that received an unrecognized PCEP message MUST
send a PCErr message with Error-value=2 (capability not supported).
Then add a new Reasons value in the CLOSE object (still in [PCEP]):
Reasons
Value Meaning
1 No explanation provided
2 DeadTimer expired
3 Reception of a malformed PCEP message
4 Reception of an unacceptable number of
unknown requests/replies
=> 5 Reception of an unacceptable number of
unrecognized PCEP messages
And in PCE-Monitoring: "As specified in [PCEP], a PCEP peer receiving an
unrecognized PCEP message must send a PCErr message with Error-value=2
(capability not supported)."
>
>
>
> ===
>
> 3.2. Path Monitoring Reply message (PCMonRep)
>
> If the Monitoring
>
> object is missing, the receiving PCE MUST send an error message to
>
> the requesting PCC.
>
>
>
> Which error code?
Oops, good catch thanks. New error-value added:
Also reported in section 3.1
>
>
> Please indent the bit numbering correctly
>
>
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> | Reserved | Flags |I|C|P|G|L|
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> Very unusual split. 10 bits reserved and 22 bits of flags.
>
>
>
>
>
> OLD
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> | monitoring-id-number |
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> NEW
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> | Monitoring-id-number |
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>
> s/Flags: 18 bits/Flags: 22 bits/
>
>
Fixed to a 8-bit flag field.
>
>
>
> The P bit MUST always be set in a PCMonRep message if also
>
> set in the corresponding PCMonReq message.
>
> No objection, but why? Doesnât the PROC-TIME object convey the same
> information?
Yes, we could also just ignore the value of the P bit of the MONITORING
object in a PCMonRep or PCRep messages.
>
> I note that the L and G bits are not defined in the PCMonRep.
Right. It might be actually simpler to just ignore the values of the L, G, P
and C (not I of course) in PCMonRep and PCRep messages. Agree ?
>
> Anyway, you need to talk not just about PCMonReq/Rep, but the use in PCReq/Rep
> (cf
>
> C bit).
>
Yes (already stated though). What do you think of the proposal above ?
>
>
>
>
> OLD
>
> I (Incomplete) - 1 bit: the I bit MUST be set by a PCE that supports
>
> the PCMonReq message, which does not trigger any policy violation but
>
> that cannot provide the set of requested performance metrics for
>
> unspecified reasons.
>
> NEW
>
> I (Incomplete) - 1 bit: If a PCE supports a received PCMonReq
>
> message and that message does not trigger any policy violation, but
>
> the PCE cannot provide any of the set of requested performance
>
> metrics for unspecified reasons, the PCE MUST set the I bit. The I
>
> bit has no meaning in a request and SHOULD be ignored on receipt.
>
Fixed.
>
>
>
>
> Question...
>
> Monitoring-id-number (32 bits). The monitoring-id-number value
>
> combined with the source IP address of the PCC and the PCE address
>
> uniquely identify the monitoring request context.
>
> âthe PCE addressâ?
>
> The request is not specifically targeted at a PCE, or may include a list of
> PCEs.
>
> How does this work? Isnât the PCC ID and the monitoring-id-number
> sufficient?
You're quite right.
>
> Later
>
> you say that the same monitoring-id-number can be used for requests sent to
>
> different PCEs, but this seems to be ambiguous for chains of PCEs. And you say
>
> âThe
>
> path computation monitoring reply is unambiguously identified by the IP source
>
> address of the replying PCEâ but the replying PCE might not be known by the
>
> source
>
> PCC.
>
Agree. There are two ways to address this but I would propose just the easy
one: impose to the PCC to always increment the monitoring-id-number
(otherwise PCE along the chain would have to check the PCE chain along with
the PCC ID to disambiguate the request) and indicate that the
{monitoring-id-number,PCC ID} uniquely identifies the request.
>
>
> Question
>
> The monitoring-id-
>
> number MUST be incremented each time a new monitoring is sent to a
>
> PCE.
>
> Same problem as was raised by the IESG for PCEP. The requirement is just that
> this
>
> number allows disambiguation of active requests/responses. Why do you
>
> require âincrementâ and by what value should the increment be made?
Let's adopt a similar approach as for the SID:
OLD:
Monitoring-id-number (32 bits). The monitoring-id-number value combined with
the source IP address of the PCC and the PCE address uniquely identify the
monitoring request context. The monitoring-id-number MUST be incremented
each time a new monitoring is sent to a PCE. The value 0x0000000 is
considered as invalid. If no reply to a monitoring request is received from
the PCE, and the PCC wishes to resend its path computation monitoring
request, the same monitoring-id-number MUST be used. Conversely, different
monitoring-id-number MUST be used for different requests sent to a PCE. The
same monitoring-id-number may be used for path computation monitoring
requests sent to different PCEs. The path computation monitoring reply is
unambiguously identified by the IP source address of the replying PCE.
NEW:
Monitoring-id-number (32 bits): The monitoring-id-number value combined with
the PCEP-ID of the PCC identifies the monitoring request context. The
monitoring-id-number MUST be incremented each time a new monitoring is sent
to a PCE. Each increment SHOULD have a value of 1 and may cause a wrap back
to zero. The value 0x0000000 is considered as invalid. If no reply to a
monitoring request is received from the PCE, and the PCC wishes to resend
its path computation monitoring request, the same monitoring-id-number MUST
be used. Conversely, a different monitoring-id-number MUST be used for
different requests sent to a PCE. The path computation monitoring reply is
unambiguously identified by the monitoring-id-number and the PCEP-ID of the
replying PCE.
>
>
>
>
>
> No optional TLVs are currently defined.
>
> So, why do we have TLVs? Would it be better to put some of the response
> objects
>
> into this object as TLVs? E.g., PROC-TIME, CONGESTION, etc.
>
That's another option but does not buy that much. The idea was to
potentially allow for TLVs to be carried within the MONITORING object to
express more complex monitoring requests.
>
>
> ===
>
> 4.2. PCE-ID Object
Actually, let's call PCEP-ID since it could also be used to identify a PCC.
>
> A set of PCE-ID objects may be inserted within a PCReq or a PCMonReq
>
> message to specify the PCE for which PCE state metrics are requested
>
> and in a PCMonRep or a PCRep message to record the IP address of the
>
> PCE reporting PCE state metrics or that was involved in the path
>
> computation chain.
>
> So...
>
> If I send a PCReq with a list of PCE-IDs because these are the PCEs I want to
>
> process the request, can I control the list of PCEs that supply the monitoring
>
> information? For example, I way want the processing time form just the last
> PCE of
>
> a chain of PCEs.
Nope ... We would use the same list to indicate the PCE chain and list of
PCE for which we need monitoring data. We could have two list here, one of
path computation, one for monitoring request but this would increase the
complexity. Looks much simpler to me when the PCC wants to impose a PCE
chain and requires monitoring data to use the same list.
OK ?
>
>
>
>> A PCE MUST use the same IP address as the address used in the PCE-
>
> ADDRESS sub-TLV defined in [RFC5088] and [RFC5089] should a dynamic
>
> discovery mechanism be used for PCE discovery.
>
> Should that read âA PCC MUST ...â ? After all, the PCE has no control over
> the
>
> PCE-
>
> ID supplied in a request.
>
Ah well, it is both in fact. The PCC MUST use the same IP address as the one
used by the PCE to advertise itself and the PCE must also use this address
in its replies.
NEW Text:
When a dynamic discovery mechanism is used for PCE discovery, a PCE
advertises its PCE address in the PCE-ADDRESS sub-TLV defined in
[RFC5088] and [RFC5089]. A PCE MUST use this address in PCReq and
PCMonReq messages and a PCE MUST also use this address in PCRep and
PCMonRep messages.
>
>
> ===
>
> 4.3. PROC-TIME Object
>
>
>
> The PROC-TIME object MUST be present within a PCMonRep or a PCRep
>
> message if the P bit of the MONITORING object carried within the
>
> corresponding PCMonReq or PCReq message is set.
>
> âMUSTâ?
>
> Compare with the I bit.
>
> Consider local policy that says âI am not going to answer thatâ
>
Yes it should read: " If allowed by policy, the PCE inclused a PROC-TIME
object is within a PCMonRep or a PCRep message if the P bit of the
MONITORING object carried within the corresponding PCMonReq or PCReq message
is set."
>
>
>
>
> Please align the bit numbers correctly.
>
>
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> | Reserved | Flags |
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> | Processing-time |E|
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> Wouldnât it be more sensible to move the E bit into the Flags field so that
> all
>
> time fields are the same format?
Good suggestion indeed, bit moved.
>
>
>
>
>
> ===
>
> 4.4. CONGESTION Object
>
> C (Congestion) - 1 bit: when set, this indicates that PCE is
>
> congested, in which case the congestion duration may be non nul.
>
> When cleared this indicates that the PCE is not congested.
>
>
>
> Congestion duration - 16 bits: This field indicates in seconds the
>
> estimated congestion duration.
>
>
>
> Confused! What is the meaning of C-bit set, Congestion Duration = 0?
>
OLD:
C (Congestion) - 1 bit: when set, this indicates that PCE is congested, in
which case the congestion duration may be non nul. When cleared this
indicates that the PCE is not congested. Congestion duration - 16 bits: This
field indicates in seconds the estimated congestion duration.
NEW:
C (Congestion) - 1 bit: when set, this indicates that PCE is congested, in
which case the congestion duration may be non nul. When cleared this
indicates that the PCE is not congested and the "Congestion Duration" field
MUST be set to 0x0000. Congestion duration - 16 bits: This field indicates
in seconds the estimated congestion duration.
>
>
> ===
>
> 4.5. TIMESTAMP Object
>
>
>
> A TIMESTAMP object will be specified in a further revision of this
>
> document
>
>
>
> Will you do this before WG last call, or will you delete this section?
>
>
It has been deleted.
>
> ===
>
> 5. Multi-destination monitoring
>
>
>
>
> In a further revision of this document, a new object will be
>
> specified allowing a PCC or a user to gather PCE state metrics for a
>
> set of destinations using a single PCMonReq message.
>
>
>
> Need to resolve this TBD.
>
Yes this was a placeholder for a potential addition, which may be useful for
a "targeted subnet" or more likely P2MP. That said, it is probably better at
this stage to stabilize the document and work on a potential P2MP extensions
once the P2MP PCEP ID will have evolved.
>
>
> ===
>
> 7. Elements of procedure
>
>
>
> I bit processing: as indicated in section Section 4.1, the I bit MUST
>
> be set by a PCE that supports the PCMonReq message, which does not
>
> trigger any policy violation but that cannot provide the set of
>
> required performance metrics for unspecified reasons. Once set, the
>
> I bit MUST NOT be changed by a receiving PCE.
>
> Revise for clarity as proposed for section 4.1
>
>
>
>
>
> Reception of a PCMonReq message: upon receiving a PCMonReq message:
>
>
>
> 1) If the PCE does not support the PCMonReq message, the PCE MUST
>
> send a PCErr message with Error-type=14 and Error-value=1.
>
>
>
> Wait a moment. You are defining a new error code to handle non-support of a
> new
>
> feature. Surely you should use an existing error code as see in the PCEP spec.
> For
>
> example, error-type=2
>
Yes, this has been addressed in the earlier in this email. We should delete
that new Error-type here.
>
>
> ===
>
> 8. Manageability Considerations
>
>
>
> To be addressed in a further revision of this document.
>
>
>
> Please resolve this TBD
>
Yes we'll flesh this out.
>
>
> ===
>
> 9. To be considered in a further revision of this document
>
>
>
> It might be desirable to modify the format of the PCMonReq and
>
> PCMonRep messages to support the bundling of multiple performance
>
> metrics collection for a set of TE LSPs.
>
>
>
> Please resolve this TBD
Removed.
>
>
>
> ===
>
> 10. IANA Considerations
>
>
>
> Need to give better references to the registries defined in the PCEP I-D.
>
>
>
> ===
>
> 11. Security Considerations
>
>
>
> To be addressed in a further revision of this document.
>
>
>
> Hmmm?
>
In the works.
Thanks !
JP.
>
>
>
>
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
