Subject: RE: [Pce] draft-leroux-pce-of-00.txt

From: "ASH, GERALD R, ATTLABS" <[email-masked]>
Date: Fri, 2 Mar 2007 18:53:31 -0600

Hi JL,

Looks like a good start.  

Looking through the IANA section, I don't see registration of the
objective functions (OFs) required in Section 5.1.17 of
http://www.ietf.org/internet-drafts/draft-leroux-pce-of-00.txt:

"  The PCECP MUST support at least the following "unsynchronized"
   functions:

- Minimum cost path with respect to a specified metric
     (shortest path)
   - Least loaded path
   - Maximum available bandwidth path

   Also, the PCECP MUST support at least the following "synchronized"
   objective functions:

   - Minimize aggregate bandwidth consumption on all links
   - Maximize the residual bandwidth on the most loaded link
   - Minimize the cumulative cost of a set of diverse paths"

Shouldn't these standard OFs and their parameters be registered from the
start?

It would also be useful to illustrate how each of these OFs are encoded,
perhaps in an illustrative appendix.

How can new OFs be specified, i.e., how will extensibility of OFs and
their parameters be accommodated?

Thanks,
Regards,
Jerry

________________________________

From: LE ROUX Jean-Louis RD-CORE-LAN
[mailto:[email-masked]] 
Sent: Wednesday, February 28, 2007 11:39 AM
To: [email-masked]
Subject: [Pce] draft-leroux-pce-of-00.txt 

Hi all, 

This new draft defines PCED and PCEP extensions for the encoding of
objective functions. 
We are waiting for WG feedback/comments. 

http://www.ietf.org/internet-drafts/draft-leroux-pce-of-00.txt.

Regards, 

JL

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

---

From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Wed, 7 Mar 2007 00:49:42 +0100

Hi Jerry,

Thanks for the feedback and comments.

Please see inline, 

> -----Message d'origine-----
> De : ASH, GERALD R, ATTLABS [mailto:[email-masked]] 
> Envoyé : samedi 3 mars 2007 01:54
> À : LE ROUX Jean-Louis RD-CORE-LAN; [email-masked]
> Cc : ASH, GERALD R, ATTLABS
> Objet : RE: [Pce] draft-leroux-pce-of-00.txt 
> 
> Hi JL,
> 
> Looks like a good start.  
> 
> Looking through the IANA section, I don't see registration of 
> the objective functions (OFs) required in Section 5.1.17 of
> Shouldn't these standard OFs and their parameters be 
> registered from the start?

Actually we prefer to keep this draft generic, and define specific objective functions in other documents. For instance draft-lee-pce-global-concurrent-optimization-02.txt requests for three code points within the OF registry.

> 
> It would also be useful to illustrate how each of these OFs 
> are encoded, perhaps in an illustrative appendix.
> 
> How can new OFs be specified, 
>i.e., how will extensibility of 
> OFs and their parameters be accommodated?

The OF is identified by a 16 bit code point.
A document that defines a new OF will request IANA for a code point within the OF code point registry.
We will clarify in next revision.

Regards, 

JL

> This new draft defines PCED and PCEP extensions for the 
> encoding of objective functions.

---

From: Wenhu Lu <[email-masked]>
Date: Tue, 06 Mar 2007 17:18:48 -0800

Hi Jean-Louis,

It came to my attention that the acronym PCEP was used throughout this draft
whereas the acronym PCECP was used in drafts such as this one -

_PCE Communication Protocol (PCECP) Specific Requirements for Inter-Area 
Multi Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) 
Traffic Engineering 
<http://www.ietf.org/internet-drafts/draft-ietf-pce-pcecp-interarea-reqs-05.txt> 
(26301 bytes)._

Are these two acronyms going to converge at some time?

Regards,
-wenhu

LE ROUX Jean-Louis RD-CORE-LAN wrote:
> _http://www.ietf.org/internet-drafts/draft-leroux-pce-of-00.txt_
>
> Regards,
>
> JL
>
>
> ------------------------------------------------------------------------
>

---

From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Wed, 7 Mar 2007 12:08:16 +0100

Hi Wenhu

The acronym PCECP is a generic term that refers to any protocol for communication between PCC and PCE. It does not refer to a specific protocol. This term has been used in requirement documents.

PCEP refers to a specific PCECP protocol, this is the protocol defined by the PCE WG. 

Does that clarify?

Regards,

JL

> De : Wenhu Lu [mailto:[email-masked]] 
> Envoyé : mercredi 7 mars 2007 02:19
> À : [email-masked]
> Objet : Re: [Pce] draft-leroux-pce-of-00.txt
> 
> Hi Jean-Louis,
> 
> It came to my attention that the acronym PCEP was used 
> throughout this draft whereas the acronym PCECP was used in 
> drafts such as this one -
> 
> _PCE Communication Protocol (PCECP) Specific Requirements for 
> Inter-Area Multi Protocol Label Switching (MPLS) and 
> Generalized MPLS (GMPLS) Traffic Engineering

---

From: JP Vasseur <[email-masked]>
Date: Wed, 7 Mar 2007 08:53:57 -0500

Hi,

On Mar 6, 2007, at 8:18 PM, Wenhu Lu wrote:

> _PCE Communication Protocol (PCECP) Specific Requirements for Inter- 
> Area Multi Protocol Label Switching (MPLS) and Generalized MPLS  
> (GMPLS) Traffic Engineering <http://www.ietf.org/internet-drafts/ 
> draft-ietf-pce-pcecp-interarea-reqs-05.txt> (26301 bytes)._
>

The term PCECP is used in the requirement drafts because they refer  
to requirements for a PCE Communication Protocol: PCEP is the  
protocol that has been defined.

Hope this clarifies.

JP.

>> This new draft defines PCED and PCEP extensions for the encoding  
>> of objective functions.

---

From: Wenhu Lu <[email-masked]>
Date: Wed, 07 Mar 2007 17:36:53 -0800

JP Vasseur wrote:
>> Inter-Area Multi Protocol Label Switching (MPLS) and Generalized MPLS 
>> (GMPLS) Traffic Engineering 
> The term PCECP is used in the requirement drafts because they refer to 
> requirements for *a* PCE Communication Protocol: PCEP is the protocol 
> that has been defined.
>
> Hope this clarifies.
Thank you JP, point taken.
I'm a little bit concerned about the symmetries of PCED and PCEP.
It's not as easy in relating "Communication" to PCEP as "Discovery" to PCED.
Maybe I missed something.

Regards,
-wenhu
>>> [email-masked] <mailto:[email-masked]>
>> [email-masked] <mailto:[email-masked]>

---

From: JP Vasseur <[email-masked]>
Date: Thu, 8 Mar 2007 14:53:49 -0500

On Mar 7, 2007, at 8:36 PM, Wenhu Lu wrote:

>>> Inter-Area Multi Protocol Label Switching (MPLS) and Generalized  
>>> MPLS (GMPLS) Traffic Engineering <http://www.ietf.org/internet- 
>>> drafts/draft-ietf-pce-pcecp-interarea-reqs-05.txt> (26301 bytes)._
>>>
>> The term PCECP is used in the requirement drafts because they  
>> refer to requirements for *a* PCE Communication Protocol: PCEP is  
>> the protocol that has been defined.
>>
>> Hope this clarifies.

Not sure to see what you're concerned about ?

JP.

---

From: "ASH, GERALD R, ATTLABS" <[email-masked]>
Date: Thu, 8 Mar 2007 22:28:27 -0600

Hi JL,

> -----Original Message-----
> Sent: Tuesday, March 06, 2007 6:50 PM
> To: ASH, GERALD R, ATTLABS; [email-masked]
> Subject: RE: [Pce] draft-leroux-pce-of-00.txt 
> 
> Hi Jerry,
> 
> > http://www.rfc-editor.org/rfc/rfc4657.txt:
> > 
> >    Also, the PCECP MUST support at least the following 
> >    "synchronized" objective functions:
> > 
> Actually we prefer to keep this draft generic, and define 
> specific objective functions in other documents. For instance 
> draft-lee-pce-global-concurrent-optimization-02.txt requests 
> for three code points within the OF registry.

I guess I have the same question.  Which PCEP document(s) will specify the missing 6 objective functions, listed above, as required in Section 5.1.17 of the PCECP Generic Requirements (RFC 4657)?  I don't think these should be specified in 'other' (unnamed) documents, they should appear in the main PCEP specification document http://www.ietf.org/internet-drafts/draft-ietf-pce-pcep-07.txt, or perhaps in draft-leroux-pce-of-00.txt.

Thanks,
Regards,
Jerry

---

From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Wed, 14 Mar 2007 18:51:36 +0100

Hi Jerry, 

> Envoyé : vendredi 9 mars 2007 05:28
> > > De : ASH, GERALD R, ATTLABS [mailto:[email-masked]] Envoyé 
> : samedi 3 
> > > mars 2007 01:54 À : LE ROUX Jean-Louis RD-CORE-LAN; 
> [email-masked] Cc 
> > > : ASH, GERALD R, ATTLABS Objet : RE: [Pce] 
> > > draft-leroux-pce-of-00.txt
> > > 
> > > Hi JL,
> > > 
> > > Looks like a good start.  
> > > 
> > Actually we prefer to keep this draft generic, and define specific 
> > objective functions in other documents. For instance 
> > draft-lee-pce-global-concurrent-optimization-02.txt 
> requests for three 
> > code points within the OF registry.
> 
> I guess I have the same question.  Which PCEP document(s) 
> will specify the missing 6 objective functions, listed above, 
> as required in Section 5.1.17 of the PCECP Generic 
> Requirements (RFC 4657)?

Two objective functions listed in 5.1.17 are specified in section 5.1 of
draft-lee-pce-global-concurrent-optimization-02.txt.
We can add other synchronized objective functions in the next revision of the gco draft.

> I don't think these should be 
> specified in 'other' (unnamed) documents, they should appear 
> in the main PCEP specification document 
> http://www.ietf.org/internet-drafts/draft-ietf-pce-pcep-07.txt

Hum, this would create dependancy between the PCEP spec which is stable and this new OF draft.

> , or perhaps in draft-leroux-pce-of-00.txt.

We don't really like this option as we want to keep the OF draft generic.

One could write a short draft that would define a set of straightforward unsynchronized objective functions including those we listed in 4657.

Regards,

JL

---

From: "ASH, GERALD R, ATTLABS" <[email-masked]>
Date: Wed, 14 Mar 2007 15:16:51 -0500

Hi JL, 

> Sent: Wednesday, March 14, 2007 1:52 PM
> > : > samedi 3 
> > > specific 
> Hum, this would create dependency between the PCEP spec which 
> is stable and this new OF draft.
> 
> One could write a short draft that would define a set of 
> straightforward unsynchronized objective functions including 
> those we listed in 4657.

IMO an important missing PCECP requirement is identified in http://www.ietf.org/internet-drafts/draft-ietf-pce-pcep-07.txt Appendix A (Compliance with the PCECP Requirement Document):

"   Here is the list of currently unsatisfied requirements:

   o  Allow to select/prefer from advertised list of standard objective
      functions/options

   o  Allow to customize objective function/options

   o  Support "unsynchronized" & "synchronized" objective functions"

They all deal with the missing 6 objective functions required in RFC 4657, and are an important omission in PCEP, so far.

You say that PCEP is 'stable' so you don't want to add them there?  Does that mean no further changes to PCEP before WGLC?  If so, the omission would be brought up during WGLC as an important gap in PCEP.

You don't want them in the OF draft, OK, your call.

Finally, once again, I don't think other new drafts (e.g., draft-lee-pce-global-concurrent-optimization-02.txt) that specify perhaps *new* PCEP requirements, should be satisfying the original RFC 4657 PCECP requirements on PCEP.  You also say 'We can add other synchronized objective functions in the next revision of the gco draft.'  I don't think that's the right place to satisfy the PCECP requirements.  And furthermore you say that yet another draft 'would define a set of straightforward unsynchronized objective functions including those we listed in 4657.'  It doesn't make sense IMO, rather, all 6 of these objective functions should be specified in the PCEP document.

It would be good to have other opinions on this.

Thanks,
Regards,
Jerry

---

From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Wed, 14 Mar 2007 23:37:42 +0100

Hi Jerry, 

> Envoyé : mercredi 14 mars 2007 21:17
> : vendredi 
> > > 9 mars 2007 05:28 À : LE ROUX Jean-Louis RD-CORE-LAN; 
> [email-masked] 
> [email-masked] 
> > > > > Cc
> > > I guess I have the same question.  Which PCEP document(s) will 
> > > specify the missing 6 objective functions, listed above, 
> as required 
> > > in Section 5.1.17 of the PCECP Generic Requirements (RFC 4657)?
> > 
> > Two objective functions listed in 5.1.17 are specified in 
> section 5.1 
> > of draft-lee-pce-global-concurrent-optimization-02.txt.
> > We can add other synchronized objective functions in the 
> next revision 
> > of the gco draft.
> > 
> > > specified in 'other' (unnamed) documents, they should 
> appear in the 
> > > main PCEP specification document 
> > Hum, this would create dependency between the PCEP spec which is 
> > stable and this new OF draft.
> > 
> > straightforward unsynchronized objective functions 
> including those we 
> > listed in 4657.
> 
> IMO an important missing PCECP requirement is identified in 
>  Appendix A (Compliance with the PCECP Requirement Document):
> 
> They all deal with the missing 6 objective functions required 
> in RFC 4657, and are an important omission in PCEP, so far.

In montreal we indicated that objective functions would not be covered in the base PCEP spec. 
There was no objection. This was recalled in San Diego, again no objection...

> 
> You say that PCEP is 'stable' so you don't want to add them 
> there?  

What I say is that this would create dependancy between PCEP and OF drafts which is not good. The base PCEP draft should not have any dependancy with other drafts.

> Does that mean no further changes to PCEP before 
> WGLC? 

Definitely no!

But, again, note that it was agreed that objective functions would not be covered in the base spec.

> If so, the omission would be brought up during WGLC as 
> an important gap in PCEP.

As far as I know in 4657 we don't say that all MUST requirements MUST be covered in the same document...

> Finally, once again, I don't think other new drafts (e.g., 
> draft-lee-pce-global-concurrent-optimization-02.txt) that 
> specify perhaps *new* PCEP requirements, should be satisfying 
> the original RFC 4657 PCECP requirements on PCEP.  

Why?

Draft-lee specifies two objective functions listed in 4657, where is the problem?

> You also 
> say 'We can add other synchronized objective functions in the 
> next revision of the gco draft.'  I don't think that's the 
> right place to satisfy the PCECP requirements.

Why? 

>  And 
> furthermore you say that yet another draft 'would define a 
> set of straightforward unsynchronized objective functions 
> including those we listed in 4657.'  It doesn't make sense 
> IMO, rather, all 6 of these objective functions should be 
> specified in the PCEP document.
> 

Regards,

JL

---

From: "ASH, GERALD R, ATTLABS" <[email-masked]>
Date: Thu, 15 Mar 2007 16:55:03 -0500

Hi JL, 

> There was no objection. This was recalled in San Diego, again 

Well that doesn't cast it in concrete, I'll register my objection.
Without objective functions, PCE would not be able to do much to
optimize path computation.  I think it's important for PCEP to include
the objective functions required in the PCECP generic requirements in
the base PCEP spec.
 
> What I say is that this would create dependency between PCEP 
> and OF drafts which is not good. The base PCEP draft should 
> not have any dependency with other drafts.
> 

See above comments.
 
> > I don't think other new drafts (e.g., 

Several.  No rationale to put generic PCECP requirements in some other
draft besides the base PCEP draft.  The draft isn't a WG draft.  There
isn't any compelling reason to not specify the objective functions in
the base PCEP draft.

> > right place to satisfy the PCECP requirements.

See above comments.

Thanks,
Regards,
Jerry

---

From: JP Vasseur <[email-masked]>
Date: Fri, 16 Mar 2007 00:27:34 +0100

Hi Jerry,

>>> in RFC 4657, and are an important omission in PCEP, so far.

Let's try to step back for a minute.
1) PCEP has been designed so as to support the functionalities listed  
above.
RFC 4657 does not mandate to define the objective functions but to  
allow to
select objective functions, ... and that is clearly feasible with the  
PCEP design.
As such I don't see any particular issues.
2) Yes, defining such functions is a good idea, thus the proposed  
draft, which is
not at this point a WG ID indeed. Thanks for helping out on the  
content of this draft.
3) Whether to add those functions and other features in the base spec  
has indeed
been debated during the last two WG meetings and the agreement was to
freeze the current spec in order to stabilize the specification, wait  
to see implementations,
interop reports, ... As you know, we have to draw the line somewhere  
and if we keep
adding feature, the base protocol spec will not stabilize. The PCE  
being a new path
computation concept, it is crucial to first stabilize a set of core  
features, acquire some
experience based on deployments rather than keep adding features.

Does that make sense ?

Cheers.

JP.