Subject: [Pce] comments to draft-ietf-pce-discovery-reqs-01.txt

From: "Andrew Dolganow" <[email-masked]>
Date: Wed, 3 Aug 2005 04:26:42 -0400

Jean Louis et al,
 
Here is few comments/questions to the draft I have:
 
1. Section 6.1:
 
Propose to change the first paragraph (for clarity) with:
The PCE discovery mechanism MUST allow disclosing mandatory, PCE information
that will allow PCCs to select appropriate PCEs. The PCE discovery mechanism
MAY allow disclosing optional , as defined below PCE information that will
allow PCCs to select appropriate PCEs. 

2. Section 6.4.1

The draft states that a PCE should advertise alternate PCEs. If that's the
case, do you expect those other PCEs to also advertise themselves? If yes
(which I expect) then we should add for clarity at the end of that section
something like ( is required to allow PCCs to select a Main PCE over an
alternate even if the alternate PCE is discovered first by a PCC. ):

The alternate PCEs MUST advertise the main PCE(s) for which they alternate. 

We could also add a role (Main, alternate) in capabilities summary section
earlier on.

3 Section 6.3

The section states in the first paragraph that a PCE MUST allow detection of
a change of any information advertised to a PCC (capabilities). Why is this
a MUST, if advertising of capabilities is a MAY in section 6.1 above?

For clarity we should probably add qualification that If a PCE supports
advertising of capabilities, then it MUST allow detection. Here is a
proposed new text:

Iff a PCE supports advertising of optional information, then the PCE
discovery mechanism MUST allow a PCC to detect any change in the information
related to a PCE (e.g. capability modifications). 

4. Section 6.5

I would like to propose that detection of congestion would happen as part of
PCE-PCC communication protocol. For simplicity we may have a reactive mode
(i.e. a failure to a computation request to a PCC due to congestion would
include for example a time value required for that PCC to back-off before
sending a next request to a given PCE). If we would need something more
proactive, then we could add that in protocol draft and not in here.

Regards,

Andrew 

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