Picon

RE: WG feed-backs on PCEP

JP, All,

Here are a few comments on the PCEP I-D.

General comments:

1. Nice job, good technical solution, quite complete for a first draft.
2. So far we only have PCE Communication Protocol Generic Requirements
http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol-gen-req
s-00.txt, although we expect application-specific requirements as
specified in Section 6.1.9 of that document.  How do we know that the
proposed PCEP satisfies the application-specific requirements when we
have no such requirements at this point?  Don't we need some of the
application-specific requirements first, such as:
- intra-area path computation
- inter-area path computation
- inter-AS intra provider and inter-AS inter-provider path computation?
3. You list requirements that are satisfied in Section 5.  It would be
good to identify in general how the proposed PCEP satisfies all the
requirements in
http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol-gen-req
s-00.txt.  In particular, it is not entirely clear how/where the
following requirements are addressed in the PCEP I-D: 6.1.4, 6.1.6 -->
6.1.10, 6.2.1 --> 6.2.3, 6.3.3.
4. You mention that PCEP is extensible, but it isn't clear how this
extensibility would be accomplished.  For example, in Section 7.2, RE
'format of a PCReq message', how do we extend the list of attributes in
case other attributes in the PCReq message need to be added in the
future?  Same comment on PCRep message in Section 7.3, etc.

(Continue reading)

JP Vasseur | 8 Jun 17:06 2005
Picon

Re: WG feed-backs on PCEP

Hi Jerry,

First of all thanks for your comments. See in line,

On Jun 6, 2005, at 3:11 PM, Ash, Gerald R ((Jerry)), ALABS wrote:

JP, All,

Here are a few comments on the PCEP I-D.

General comments:

1. Nice job, good technical solution, quite complete for a first draft.

Thanks.

2. So far we only have PCE Communication Protocol Generic Requirements
s-00.txt, although we expect application-specific requirements as
specified in Section 6.1.9 of that document.  How do we know that the
proposed PCEP satisfies the application-specific requirements when we
have no such requirements at this point?  Don't we need some of the
application-specific requirements first, such as:
- intra-area path computation
- inter-area path computation
- inter-AS intra provider and inter-AS inter-provider path computation?

Well as with any protocol, we will first start with the basics and extend it to meet further requirements. This is why we made PCEP as extensible as possible by offering the ability to quite easily add messages and objects in the future without compromising the protocol infrastructure. The aim of this first version is to cover the protocol basics and extensions might be added in the future to meet application-specific requirements.

3. You list requirements that are satisfied in Section 5.  It would be
good to identify in general how the proposed PCEP satisfies all the
requirements in
s-00.txt. 

"The PCE Working Group has produced a set of requirements for the PCE communication protocols ([PCE-COM-GEN-REQ]) which served as input to the design of the PCEP protocol "

In particular, it is not entirely clear how/where the
following requirements are addressed in the PCEP I-D: 6.1.4,

You're absolutely right and a detailed "Security" section must be added to the PCEP draft. Will be done in the next revision.

6.1.6 -->
6.1.10, 6.2.1 --> 6.2.3, 6.3.3.

I think that there are various requirements that are satisfied. Trying to analyze them one by one is a good idea. To avoid a quite long email, may I suggest to have separate emails (one per item) ?

4. You mention that PCEP is extensible, but it isn't clear how this
extensibility would be accomplished.  For example, in Section 7.2, RE
'format of a PCReq message', how do we extend the list of attributes in
case other attributes in the PCReq message need to be added in the
future?  Same comment on PCRep message in Section 7.3, etc.


That really depends on the attribute ... could be as simple as a new flag in the REQUEST-ID object or require an entirely new object carried in both the PCReq and PCRep messages.

Specific comments:

1. Section 5, last line: 'regular PCE' and 'PCE itself acting as a PCC'
are not terms used in [PCE-ARCH].  For instance, the latter is defined
as a 'composite PCE' in [PCE-ARCH].  It would be best to use terminology
consistent with [PCE-ARCH].

Good point ! Will fix that.

2. Section 6: I agree with Dean Cheng that open, close, and hello are
not needed, and that detailed capability discovery is needed upon PCEP
connection setup.

ok thanks for the feed-back.

3. Section 8.2, RE 'P (Partial)':  We define 'explicit PCE path' and
'strict/loose PCE path' in [PCE-ARCH], rather than 'Partial'.  Again,
consistent terminology would be good.

Also agree.

4. Section 8.4: Is 'Bandwidth' the only traffic descriptor allowed?
What if other descriptors (e.g., token bucket) are desired, how are
these going to be included if needed in the future?

As simple as new objects. I think that we will likely see new such object in the future, but let's start with the required minimum. 

5. Section 8.5: What if 'path jitter', 'path bit error rate', and other
path QoS parameters, in addition to 'path delay', are desired?  How are
these going to be included if needed in the future?

Well we may either decide to:
- Have a single object with all such attributes
- Have multiple object

This will be discussed once such requirements will be known.

6. Section 8.7, line 1: 'Section 8' --> 'Section 9'

Thanks.

7. Section 8.8, RE 'An implementation may decide to cancel such
notification if the PCC is in down state for a specific period. A
RECOMMENDED value for such delay is 1 hour.'  What is the 1-hour
recommendation based on, sounds pretty arbitrary?

Yes indeed ... from the time the ID potentially moves forward we should have implementations providing a better idea of the suggested value.

8. Section 16.2: Why are [PCE-ARCH] and [PCE-GEN-COM-REQ] informative
references, shouldn't these be normative references?


Thanks.

JP.

Thanks,
Regards,
Jerry

-----Original Message-----
From: pce-bounces <at> lists.ietf.org [mailto:pce-bounces <at> lists.ietf.org] On
Behalf Of JP Vasseur
Sent: Thursday, May 26, 2005 11:42 AM
Subject: [Pce] WG feed-backs on PCEP

Dear WG,

A new ID has recently been posted 
proposing a new PCE communication protocol. There are several aspects 
for which Jean-Louis, Eiji, Alia, Arthi and myself would be happy to 
get your feed-backs (see section 6). Comments are also very welcome on 
the other parts of the ID of course.

Thanks.

JP.


_______________________________________________
Pce mailing list
Pce <at> lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce
JP Vasseur | 9 Jun 14:15 2005
Picon

Requirements for Inter-Area MPLS Traffic Engineering: RFC4105

Dear WG,

Just wanted to let you know that "Requirements for Inter-Area MPLS  
Traffic Engineering" has been published as RFC4105. Section 7 of this  
RFC contains several detailed requirements that could be used to  
define the PCE-based inter-area TE LSP path computation. Some of you  
mentioned to Adrian and myself that they were willing to produce a  
PCE-based inter-area requirement ID. Thanks to take RFC4105 into  
account.

Thanks.

JP.
Adrian Farrel | 10 Jun 13:22 2005
Picon

Fw: Internet-Drafts Submission Cutoff Dates for the 63rd IETF Meeting in Paris, France

For your information
----- Original Message ----- 
From: <ietf-secretariat <at> ietf.org>
To: <ietf-announce <at> ietf.org>
Sent: Friday, June 10, 2005 5:00 AM
Subject: Internet-Drafts Submission Cutoff Dates for the 63rd IETF Meeting
in Paris, France

>
> There are two (2) Internet-Draft cutoff dates for the 63rd
> IETF Meeting in Paris, France:
>
> July 11th: Cutoff Date for Initial (i.e., version -00)
> Internet-Draft Submissions
>
> All initial Internet-Drafts (version -00) must be submitted by Monday,
> July 11th at 9:00 AM ET. As always, all initial submissions with a
> filename beginning with "draft-ietf" must be approved by the
> appropriate WG Chair before they can be processed or announced.  The
> Secretariat would appreciate receiving WG Chair approval by Tuesday,
> July 5th at 9:00 AM ET.
>
> July 18th: Cutoff Date for Revised (i.e., version -01 and higher)
> Internet-Draft Submissions
>
> All revised Internet-Drafts (version -01 and higher) must be submitted
> by Monday, July 18th at 9:00 AM ET.
>
> Initial and revised Internet-Drafts received after their respective
> cutoff dates will not be made available in the Internet-Drafts
> directory or announced until on or after Monday, August 1st at 9:00
> AM ET, when Internet-Draft posting resumes.  Please do not wait until
> the last minute to submit.
>
> PLEASE NOTE THE CHANGE OF PROCEDURE:  If you submit an initial or
> revised Internet-Draft after their respective cutoff deadlines, then
> your document will be retained and posted when Internet-Draft
> processing resumes.  You will no longer be required to resubmit the
> document.
>
> Thank you for your understanding and cooperation. If you have any
> questions or concerns, then please send a message to
> internet-drafts <at> ietf.org.
>
> The IETF Secretariat
>
> FYI: The Internet-Draft cutoff dates as well as other significant dates
> for the 63rd IETF Meeting can be found at
http://www.ietf.org/meetings/cutoff_dates_63.html.
>
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf-announce
>
>
Zhang Renhai | 14 Jun 03:40 2005

Please comment draft-zhang-pce-comm-app-model-00

Dear WG,

A new ID has just been finished and posted
(http://www.ietf.org/internet-drafts/draft-zhang-pce-comm-app-model-00.txt),
which proposed a application model. Thinking of the satuation where the 
network resources are reserved and released frequently, for instance, VoIP
environment,this draft give a mechanisms on this respect, mostly on resolving
race conditions and on computation load balancing.
It's 10 pages long. Comments are very welcome.

Thanks and Regards.
Rh Zhang
_______________________________________________
Pce mailing list
Pce <at> lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce

PCE Disco Reqs v01

Hi all,

Version 01 of the PCE discovery reqs ID has just been published
http://www.ietf.org/internet-drafts/draft-leroux-pce-discovery-reqs-01.txt

This version takes into account comments received during Minneapolis session and on the list.

Here are the major changes since 00:
-Added multi-area network case in the problem statement
-Added application scenario (section 4)
-Section 5.1 on capability discovery modified as per discussions on the list:
        -Discovery of PCE location, PCE scopes and domain(s) under control is mandatory
        -Capability discovery is no longer a MUST
       The list of capabilities is now out of the scope and should be addressed in a
       separate document.
      
-Added section 5.6 on extensibility
-Added Security section

Section 5.5 (Discovery of PCE capacity and congestion) requires WG feedback:
-Is there a need for the discovery of PCE capacity in terms of computation power? This static parameter could be used to ensure weighted load balancing of requests in case PCEs do not have the same capacity.

-Would it be useful that a PCE report its status as "congested" in case it is too busy? PCCs may then use this dynamic information to prefer a different PCE.

Your comments/feedback would be highly welcome, especially on the above point

Best Regards,

JL

<div>

<p>Hi all,
</p>

<p>Version 01 of the PCE discovery reqs ID has just been published

<br><a href="http://www.ietf.org/internet-drafts/draft-leroux-pce-discovery-reqs-01.txt">http://www.ietf.org/internet-drafts/draft-leroux-pce-discovery-reqs-01.txt</a>
</p>

<p>This version takes into account comments received during Minneapolis session and on the list.
</p>

<p>Here are the major changes since 00:

<br>-Added multi-area network case in the problem statement

<br>-Added application scenario (section 4) 

<br>-Section 5.1 on capability discovery modified as per discussions on the list:

<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -Discovery of PCE location, PCE scopes and domain(s) under control is mandatory

<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -Capability discovery is no longer a MUST

<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The list of capabilities is now out of the scope and should be addressed in a 

<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; separate document.

<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 

<br>-Added section 5.6 on extensibility 

<br>-Added Security section
</p>

<p>Section 5.5 (Discovery of PCE capacity and congestion) requires WG feedback:

<br>-Is there a need for the discovery of PCE capacity in terms of computation power? This static parameter could be used to ensure weighted load balancing of requests in case PCEs do not have the same capacity. </p>

<p>-Would it be useful that a PCE report its status as "congested" in case it is too busy? PCCs may then use this dynamic information to prefer a different PCE. </p>

<p>Your comments/feedback would be highly welcome, especially on the above point
</p>

<p>Best Regards,
</p>

<p>JL
</p>

</div>
Picon

RE: PCE Disco Reqs v01

Hi JL,

> -Would it be useful that a PCE report its status as "congested"
> in case it is too busy? PCCs may then use this dynamic
> information to prefer a different PCE. 

Yes, it would be useful.  Also, this is a requirement in
http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol-gen-req
s-00.txt (see Sections 6.1.3 and 6.1.6).

Thanks,
Regards,
Jerry

RE : PCE Disco Reqs v01

Hi Jerry,

Yes, I know that this is also a requirement for the PCC-PCE com proto :-)
Actually here we are wondering if it would be useful to also rely on the dynamic PCE discovery mechanism to
disclose PCE congestion status? 
It may be useful that a PCC be aware of the PCE status even in the absence of a PCC-PCE  communication session,
this could avoid PCC-PCE communication setup failure...

Regards,

JL

>-----Message d'origine-----
>De : Ash, Gerald R (Jerry), ALABS [mailto:gash <at> att.com] 
>Envoyé : mercredi 29 juin 2005 15:03
>À : LE ROUX Jean-Louis RD-CORE-LAN; pce <at> ietf.org
>Cc : Ash, Gerald R (Jerry), ALABS
>Objet : RE: [Pce] PCE Disco Reqs v01
>
>
>Hi JL,
>
>> -Would it be useful that a PCE report its status as "congested" in 
>> case it is too busy? PCCs may then use this dynamic information to 
>> prefer a different PCE.
>
>Yes, it would be useful.  Also, this is a requirement in 
>http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protoco
l-gen-req
s-00.txt (see Sections 6.1.3 and 6.1.6).

Thanks,
Regards,
Jerry

JP Vasseur | 30 Jun 15:53 2005
Picon

Adoption of draft-leroux-pce-discovery-reqs-01.txt as WG document ?

Dear WG,

draft-leroux-discovery-reqs has just been re-published, addressing several of comments received during the last meeting and on the list (very few remaining open items).

Could you provide us your feed-back on adopting draft-leroux-discovery-reqs-01.txt as a WG document ?

JP and Adrian.

<div>
<p><span class="Apple-style-span"><span class="Apple-style-span">Dear WG,</span></span></p>
<p>draft-leroux-discovery-reqs has just been re-published, addressing several of comments received during the last meeting and on the list (very few remaining open items).</p>
<p>Could you provide us your feed-back on adopting draft-leroux-discovery-reqs-01.txt as a WG document ?</p>
<p>JP and Adrian.</p>
</div>
JACQUENET C ROSI/DRLD/ITP | 30 Jun 15:57 2005

RE: Adoption of draft-leroux-pce-discovery-reqs-01.txt as WGdocument ?

Hi,
 
I'm in favor of adopting this draft as a pce WG document.
 
Cheers,
 
Christian.
-----Message d'origine-----
De : pce-bounces <at> lists.ietf.org [mailto:pce-bounces <at> lists.ietf.org]De la part de JP Vasseur
Envoyé : jeudi 30 juin 2005 15:53
À : pce <at> ietf.org
Objet : [Pce] Adoption of draft-leroux-pce-discovery-reqs-01.txt as WGdocument ?

Dear WG,

draft-leroux-discovery-reqs has just been re-published, addressing several of comments received during the last meeting and on the list (very few remaining open items).

Could you provide us your feed-back on adopting draft-leroux-discovery-reqs-01.txt as a WG document ?

JP and Adrian.

<div>
<div><span class="686145713-30062005">Hi,</span></div>
<div>
<span class="686145713-30062005"></span>&nbsp;</div>
<div><span class="686145713-30062005">I'm in favor of adopting this draft as a pce WG 
document.</span></div>
<div>
<span class="686145713-30062005"></span>&nbsp;</div>
<div><span class="686145713-30062005">Cheers,</span></div>
<div>
<span class="686145713-30062005"></span>&nbsp;</div>
<div><span class="686145713-30062005">Christian.</span></div>
<blockquote dir="ltr">
  <div class="OutlookMessageHeader" dir="ltr" align="left">-----Message d'origine-----<br>De&nbsp;: 
  pce-bounces <at> lists.ietf.org [mailto:pce-bounces <at> lists.ietf.org]De la part 
  de JP Vasseur<br>Envoy&eacute;&nbsp;: jeudi 30 juin 2005 
  15:53<br>&Agrave;&nbsp;: pce <at> ietf.org<br>Objet&nbsp;: [Pce] Adoption of 
  draft-leroux-pce-discovery-reqs-01.txt as WGdocument ?<br><br>
</div>
  <p><span class="Apple-style-span"><span class="Apple-style-span">Dear 
  WG,</span></span></p>
  <p>draft-leroux-discovery-reqs has just been 
  re-published, addressing several of comments received during the last meeting 
  and on the list (very few remaining open items).</p>
  <p>Could you provide us your feed-back on 
  adopting draft-leroux-discovery-reqs-01.txt as a WG document ?</p>
  <p>JP and Adrian.</p>
</blockquote>
</div>

Gmane