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

From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Fri, 5 Aug 2005 11:54:28 +0200

Hi Andrew,
 
Thanks a lot for these valuable comments.
 
Please see inline,

________________________________

	De : Andrew Dolganow [mailto:[email-masked]] 
	Envoyé : mercredi 3 août 2005 10:27
	À : LE ROUX Jean-Louis RD-CORE-LAN
	Cc : [email-masked]
	Objet : comments to draft-ietf-pce-discovery-reqs-01.txt 

	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. 
	[JLLR] Agreed, we will clarify as per your proposal 

	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. 
	 
	[JLLR] OK, we will clarify  

	We could also add a role (Main, alternate) in capabilities summary section earlier on.
	[JLLR] Not sure that this can be considered as a capability 

	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?
	[JLLR] 

	The PCE MUST allow detection of a change of any disclosed PCE information. This comprises mandatory information and also optional information that may be disclosed...

	that is, if the PCE discovery is used so as to disclose optional info then it MUST allow detecting a change of this optional info...

	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). 
	[JLLR] OK, we are in sync, this is inline with my above comment  

	We will clarify as per your suggestion

	4. Section 6.5

	I would like to propose that detection of congestion would happen as part of PCE-PCC communication protocol. 
	[JLLR] Yes, but one could argue that a PCC may want to be aware of a PCE congestion even in the absence of a PCC-PCE communication session. this may be useful with the per-request session mode, if adopted in PCEP (see also session on required feedback in PCEP)

	  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.
	[JLLR] One may want to be proactive, so as to minimize path computation service disruption... 

	Again thanks a lot Andrew for these useful comments

	Best Regards,

	JL

	Regards,

	Andrew 

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

---

From: "Andrew Dolganow" <[email-masked]>
Date: Mon, 8 Aug 2005 09:10:44 -0400

Jean-Louis,
 
I believe we are in synch functionally and the only thing we are discussing
what is the place to describe such proactive congestion mechanism. If this
ID will change into a session-control (which we could probably do
considering content) than I agree with you that this should be here. A more
reactive way can then also be described in the protocol itself.
 
Andrew

  _____  

From: LE ROUX Jean-Louis RD-CORE-LAN
[mailto:[email-masked]] 
Sent: Friday, August 05, 2005 5:54 AM
To: Andrew Dolganow
Cc: [email-masked]
Subject: RE: comments to draft-ietf-pce-discovery-reqs-01.txt

Hi Andrew,

Please see inline,

  _____  

Jean Louis et al,

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. 
[JLLR] Agreed, we will clarify as per your proposal 

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. ):

We could also add a role (Main, alternate) in capabilities summary section
earlier on.
[JLLR] Not sure that this can be considered as a capability 

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?
[JLLR] 

The PCE MUST allow detection of a change of any disclosed PCE information.
This comprises mandatory information and also optional information that may
be disclosed...

that is, if the PCE discovery is used so as to disclose optional info then
it MUST allow detecting a change of this optional info...

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). 
[JLLR] OK, we are in sync, this is inline with my above comment  

4. Section 6.5

I would like to propose that detection of congestion would happen as part of
PCE-PCC communication protocol. 
[JLLR] Yes, but one could argue that a PCC may want to be aware of a PCE
congestion even in the absence of a PCC-PCE communication session. this may
be useful with the per-request session mode, if adopted in PCEP (see also
session on required feedback in PCEP)

  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.
[JLLR] One may want to be proactive, so as to minimize path computation
service disruption... 

Best Regards,

JL

Regards,

Andrew