Subject: [Pce] Working group last call draft-ietf-pce-monitoring-02.txt

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 15 Dec 2008 12:30:44 -0000

This email begins a working group last call on 
draft-ietf-pce-monitoring-02.txt

The last call will run for three weeks to give people a little extra time 
over the Christmas period.
Thus, the call will end on 5th January 2009 at noon GMT

Please send your comments to the mailing list.

Thanks,
Adrian 

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 18 Dec 2008 23:01:39 -0000

Hi,

A few nitty comments on this draft.

Adrian

===

Abstract. Second sentence.

"In PCE-based environments, it is thus critical..."
I don't think this follows as a conclusion from the previous sentence. In
particular, there is no definition of a "path computation chain" and no
explanation of the process involved in PCE that leads to the conclusion that
certain things need to be monitored or troubleshooted.

I suggest inserting a new second sentence to give some background. Something
like...

   Path Computation Clients (PCCs) send computation requests to PCEs,
   and these may forward the requests to and cooperate with other PCEs
   forming a "path computation chain".

You can then put in a paragraph break and continue with your text.

===

Section 1

You need to expand "PCC" and "TE LSP" on first usage as the Terminology 
section comes later.

===

Section 3

Please include a reference to draft-farrel-rtg-common-bnf-07.txt.
At this stage you should (and can safely) make this a normative reference. 
The RBNF draft will go to IETF last call in early January and will be ahead 
of this draft in the processing queue.

===

Section 3

s/Computation Monitoring request/Computation Monitoring Request/

===

Section 3.1

<request> is shown to optionally contain the RRO.

The text that follows refers to the ERO.

I think the text is wrong.

===

Section 3.1

s/metric(s)/metrics/

===

Section 3.1

Examples 1 and 3 should also include a note that the requested information 
is returned in a PCMonRep.

===

Section 3.2

Are you sure that you want to send an Error message in response to a bad 
PCMonRep?

Sending an Error in response to a PCMonReq is useful because it cancels the 
request and means the sender does not continue to wait or a PCMonRep. But 
sending an Error in response to a PCMonRep does not seem to have any use 
except to load the network. For example, what is the state of the 
outstanding PCMonReq in this situation? What is the sender of the PCMonRep 
supposed to do when it receives the Error message?

More appropriate would be for the receiver of the bad PCMonRep to raise an 
alert to the operator and to put the sender of the bad message on a 
blacklist so that it never send it another PCMonReq.

===

Section 3.2

It would be useful to include references for the objects listed in the BNF 
as you do in Section 3.1.

===

Section 3.2

I'm slightly confused by the BNF.

   <metric-pce>::=[<PCE-ID>]
                  [<PROC-TIME>]
                  [<CONGESTION>]

This means that <metric-pce> can be completely empty.
Surely <PCE-ID> is mandatory within <metric-pce> ?

===

Section 4

You state that the P and I flags in the new objects are cleared.

I think you mean "SHOULD be set to zero and MUST be ignored"

===

Section 4
Second paragraph.

The case of "in band" monitoring seems to be described twice.

===

Section 4.2

The object has previously been referred to as the PCE-ID object. That seems 
like a better name. Can you check the whole I-D to make sure this is 
consistent.

===

Section 4.3

   If allowed by policy, the PCE includes a PROC-TIME object within a
   PCMonRep or a PCRep message if the P bit of the MONITORING object

This conflicts with Section 4.1

   P (Processing Time) - 1 bit: the P bit of the MONITORING object
   carried in a PCMonReq or a PCReq message is set to indicate that the
   processing times is a metric of interest, in which case a PROC-TIME
   object MUST be inserted in the corresponding PCMonRep or PCRep
   message.

I prefer the "if allowed by policy" which means you need to change the text 
Section 4.1.

===

Section 4.3
s/algorithm(s)/algorithms/  (twice)

===

Section 4.3

   Flags: 18 bits - No Flags are currently defined:

Looks like 16 bits, and one flag is defined!

===

Section 4.3
s/computation(s)/computations/

===

Section 4.3

   Unassigned bits are considered as reserved and MUST be set to zero on
   transmission.

Move this text to immediately after the definition of the E bit

===

Section 4.3

   More granularity may be introduced in further revision of this
   document to get a monitoring metric for a general request of a
   particular class (e.g. all PCReq of priority X).

I guess you decided not to do this. Delete the text.

===

Section 4.4

- Rather than one bit and a reserved field, shouldn't you have a
  flags field (with one bit assigned) and a reserved field.
- You need to explain that setting the C bit and a congestion
   duration of zero has meaning. If it has no meaning, you don't
   need the C bit.
- Although it verges on telling the implementer how to write code
  I think some advice is needed on what to do when a
  CONGESTION object is received with the C bit set. There
  are two aspects...
  - How long has the CONGESTION object taken to propagate
     from the reporting PCE to the PCC (might not be one hop)?
  - What should the receiver do with the Congestion Duration
     value?
- It may also be worth noting whether a PCE in the middle of a
   chain is allowed to look at the CONGESTION information
   that it receives from a downstream PCE and plans to pass on
   to an upstream PCE or PCC.

===

Section 6

   Reception of a PCMonReq message: upon receiving a PCMonReq message:

Can you sort out the over-use of colons?

===

Section 6, case 1)

I think you should refer explicitly to Section 6.9 of [PCEP] because that 
includes not only the error message, but some important back-off and 
shutdown procedures.

===

Section 6, case 2)

You should refer back to Section 5.
But note also that you have an explicit case (section 4.3) where policy 
causes the message to be processed but an object to be left out of the 
reply.

===

Section 6

You need a similar set of text for the in band case.

===

Section 7.2
s/MAY/may/

===

Section 7.6

   An implementation SHOULD allow handling PCReq messages with
   a higher priority than PCMonReq messages.

And when the monitoring is in band?

===

Section 8

It would be helpful to IANA if you split this into subsections for each 
registry/subregistry.
Also nice if you could try to cut and paste from the registry naming used in 
[PCEP].

===

Section 8

The IANA section doesn't seem to be complete.

For example:
- The flags field in the Monitoring Object
   (be careful to get the bit numbering correct :-)
- The flags field in the PROC-TIME object
- The flags field in the CONGESTION object

===

Section 9

Does the information gathered by monitoring represent any additional 
vulnerability? Could an attacker gain interesting information by snooping 
this?

I think the Congestion object is a good and lightweight way to attack a PCE 
deployment. You should note this and suggest that this makes the use of 
security mechanisms important. You may also need to node that there is a 
chain of trust model here such that even if one PCE ensures that it uses 
security, the information it supplies can be changed on a hop further 
upstream. Therefore, a consistent security model across all cooperating PCEs 
is desirable.

===

Section 11.2

[I-D.ietf-pce-disco-proto-isis] is not referenced (did you run I-D nits?)

[I-D.ietf-pce-of] and [I-D.ietf-pce-pcep-xro] are normative since they 
define objects that you cite explicitly.

---

From: "Fabien Verhaeghe" <[email-masked]>
Date: Mon, 29 Dec 2008 17:52:04 +0100

Hi,

Below my comments on monitoring draft:

Section 3.1: 

Example 3: The request must also contain a MONITORING object.

Section 3.2:

The format of a PCReq message is as follows:

Must be 

The format of a PCMonRep message is as follows:

Section 4.1:

Seems the first sentence is repeated twice.
Besides it is said that the Monitoring object MAY be included in PCReq and
PCRep so I think it would be good to add the enhanced PCReq and PCRep BNF
description.

General comment:

The in-band monitoring request is not fully clear to me.

If there are several path computation requests in the PCREq which one is
targeting?
i.e. Must the PCE return the processing time for each request seperatly or a
single processing time for all requests?

In first case what happens if there is an SVEC object and Path Requests are
spread in multiple PCRep messages. Must the Monitoring object be repeated?

If a PCRep contains a Monitoring object, is it possible that
this PCRep contains Path replies not related to the Monitoring request?

BR
Fabien

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la part de
> Adrian Farrel
> Envoyé : vendredi 19 décembre 2008 00:02
> À : [email-masked]
> Objet : [Pce] Last call comments on draft-ietf-pce-monitoring-02.txt
> 
> Hi,
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 31 Dec 2008 19:07:41 -0000

That is my fault :-(

The I-D is at revision -03

http://www.ietf.org/internet-drafts/draft-ietf-pce-monitoring-03.txt

You still have until Monday next week if you want to make comments.

As my punishment, I have gone through Fabien's email to check which of his 
coments still apply...

> Example 3: The request must also contain a MONITORING object.

Issue stands.

> The format of a PCMonRep message is as follows:

Issue stands

> Seems the first sentence is repeated twice.

Fixed in revision -03

> Besides it is said that the Monitoring object MAY be included in
> PCReq and PCRep so I think it would be good to add the enhanced
> PCReq and PCRep BNF description.

Issue stands

Also in 4.1
s/PCEReq/PCReq/

> If there are several path computation requests in the PCReq
> which one is targeting?
> i.e. Must the PCE return the processing time for each request seperatly
> or a single processing time for all requests?
>
> In first case what happens if there is an SVEC object and Path Requests
> are spread in multiple PCRep messages. Must the Monitoring object be
> repeated?
>

Issue stands.

Happy New Year

Adrian