Subject: [Pce] I-D ACTION:draft-ietf-pce-architecture-01.txt

From: [email-masked]
Date: Tue, 19 Jul 2005 15:50:02 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Path Computation Element Working Group of the IETF.

	Title		: Path Computation Element (PCE) Architecture
	Author(s)	: A. Farrel, et al.
	Filename	: draft-ietf-pce-architecture-01.txt
	Pages		: 29
	Date		: 2005-7-19
	
Constraint-based path computation is a fundamental building block for
   traffic engineering systems such as Multiprotocol Label Switching
   (MPLS) and Generalized Multiprotocol Label Switching (GMPLS)
   networks. Path computation in large, multi-domain, multi-region or
   multi-layer networks is highly complex and may require special
   computational components and cooperation between the different
   network domains.

   This document specifies the architecture for a Path Computation
   Element (PCE)-based model to address this problem space. This
   document does not attempt to provide a detailed description of all
   the architectural components, but rather it describes a set of
   building blocks for the PCE architecture from which solutions may be
   constructed.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pce-architecture-01.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pce-architecture-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-pce-architecture-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Pce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pce

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 20 Jul 2005 12:05:30 +0100

Hi,

We did a largely editorial pass on the Architecture I-D. That is, no new
technical aspects.

Changes are listed below.

I am aware that the I-D would benefit from some restructuring and an
editorial pass dedicated to clarity, but I would ask that we now have a
really thorough technical review of the document.

Thanks,
Adrian

===

Reformatted the text so that it is correctly aligned

Remove spurious blank lines

Align indented paragraphs

Re-draw figure 3 to fit on page

Updated the boilerplate

Removed the RFC2219 references

Renumbered the sections

Resolve and correct cross-references

Remove double spaces

Change single quotes to double quotes

Updated references

Use "reoptimize" throughout.

Fix references to VNT since it was discussed before it was referenced

Add Manageability Considerations Section (section 8)

Add penultimate paragraph to section 6.6 to cover comments from Takao
Shimizu

Add final paragraph to section 6.8 to cover comments from Takao Shimizu

Add 2nd sentence to first paragraph of section 7 to cover comments from
Takao Shimizu

Add 2nd paragraph to section 6.1 to cover comments from Vivek Dubey

Rewrite parts of section 6.3 which was garbled and add comments from Vivek
Dubey and Richard

Rewrite 2nd paragraph of section 6.5 to handle comments from Vivek Dubey

Fix sundry typos found on casual reading

Add section 6.11 in response to discussions in the last WG meeting

Section 3 2) add 2nd sentence to clarify for Arthi.

Rewrite 6.7 3) because it implied that LSP information is held in the TED
and comments form Arthi

Add final sentence to section 7 bullet 1 to cover our discussion of Igor's
comments

Section 4.5 clarify the PCC's role in the management plane in response to
Richard.

Section 5.4 clarify that the multiple PCE with inter-PCE communication
scenario is not a case of a distributed computation algorithm.

Fill out Acknowledgements section

Spell-check

Repaginate and index

Run idnits and make fixes

---

From: dimitri papadimitriou <[email-masked]>
Date: Sat, 23 Jul 2005 14:36:33 +0200

hi adrian

> really thorough technical review of the document.

do you have any specific timeframe for such technical review beside 
charter milestone

thanks,
- dimitri.

> .

---

From: JP Vasseur <[email-masked]>
Date: Sat, 23 Jul 2005 09:24:54 -0400

Hi Dimitri,

> do you have any specific timeframe for such technical review beside  

We think that the ID is pretty stable in term of technical content.  
As Adrian pointed out, there might be some editorial work to be done  
before WG last call. So the short answer is "as soon as possible".

Thanks.

JP.

---

From: dimitri papadimitriou <[email-masked]>
Date: Sat, 23 Jul 2005 18:45:09 +0200

hi,

> We think that the ID is pretty stable in term of technical content.  As 
> Adrian pointed out, there might be some editorial work to be done  

ok thanks -

this said i asked the question because adrian's e-mail speaks about a 
thorough *technical* review and wanted to know whether you wanted to 
have a specific review before last call ?

---

From: JP Vasseur <[email-masked]>
Date: Sat, 23 Jul 2005 13:05:47 -0400

Hi,

On Jul 23, 2005, at 12:45 PM, dimitri papadimitriou wrote:

>>> do you have any specific timeframe for such technical review  
>>> beside  charter milestone
>>>
>> We think that the ID is pretty stable in term of technical  
>> content.  As Adrian pointed out, there might be some editorial  
>> work to be done  before WG last call. So the short answer is "as  
>> soon as possible".
>>
>
> ok thanks -
>
> this said i asked the question because adrian's e-mail speaks about  
> a thorough *technical* review and wanted to know whether you wanted  
> to have a specific review before last call ?
>

It would indeed be nice to do it prior to last call.

Thanks.

JP.

---

From: Lou Berger <[email-masked]>
Date: Tue, 26 Jul 2005 19:14:09 -0400

>before WG last call. So the short answer is "as soon as possible".

JP/Adrian/Jerry,
         As you say, the draft has come together very nicely.  The 
primary comment I have on the document is related to how policy is 
presented in the draft:

The draft does mention policy in multiple places, but these mentions 
are more "in-passing" than as major component.  It seems to me that 
Policy and the ability to support path computation based on, or 
influenced by policies, must be a major part of the PCE 
architecture.  I do agree with draft in that "policy between domains 
and between PCEs, and is achieved through configuration not through 
protocol communications."  That said, the PCC-PCE and PCE-PCE 
communication protocols must support the communication of all 
information needed to support the installed policies, as well as 
support any policy triggered transactions that may result due to a 
policy (or change in policy).  Also, in order to deliver viable 
policy to PCE, policy must not be an after thought.  (Consider how 
successful original RSVP was with bringing in policy after the core 
work was complete.)

In short, I think policy should be more prominent in the draft and in 
the PCE architecture.

I suggest to:
- add policy related motivations in section 4,
- add a policy component to the PCE architecture(s) presented in section 5,
- add a full fledged Policy sub-section to section 6 that is separate 
from confidentiality.
- and add a policy related evaluation metric to section 7.

Please let me know what you think.

I'll put together some specific text for fodder....

Lou

---

From: "Igor Bryskin" <[email-masked]>
Date: Wed, 27 Jul 2005 10:00:42 -0400

Hi,

I think Lou has just brought up a very important discussion.

A PCE can apply a policy for a particular path computation request only IFF
it can identify original requestor. Consider the situation when a single
request involves 2 PCEs: PCC<=>PCE1<=>PCE2.

PCE1 can identify the PCC and apply the polices for this PCC or this class
of PCCs. However, PCE2 will not be capable to identify PCC ( we seem to
agree already that PCC-PCE and PCE-PCE is the same protocol, hence PCE2 will
see PCE1 as PCC), and will apply a wrong policy. For instance, it may invoke
a computationally expensive algorithm, which it won't do if the PCC
requested computation directly from PCC2.

So, in the architecture document the reasons should be described why the
identity of the original requestor should be available for all PCEs involved
in particular path computation request. Secondly, the same point should be
reflected in the path computation communication protocol requirements.

Igor

----- Original Message ----- 
From: "Lou Berger" <[email-masked]>
To: "JP Vasseur" <[email-masked]>; "Adrian Farrel"
<[email-masked]>; "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, July 26, 2005 7:14 PM
Subject: Re: [Pce] Changes in the new revision of the architecture I-D

---

From: Lou Berger <[email-masked]>
Date: Wed, 27 Jul 2005 10:33:05 -0400

Igor,
         My primary point was that we need to ensure that we fully 
consider policy in the architecture (and the resulting instantiation 
of the architecture).

The point you raise is a reasonable one up due to such consideration. 
Although rather than make a statement on the requirement, I would ask 
the question, does policy being applied at PCE2 need to know the 
identity of PCC?
(I'm not sure...)

Much thanks,
Lou

At 10:00 AM 7/27/2005, Bryskin, Igor wrote:

> <https://www1.ietf.org/mailman/listinfo/pce>https://www1.ietf.org/mailman/listinfo/pce 
>
> >

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 27 Jul 2005 19:25:39 +0100

Thanks Lou,

You raise an important point.
Looking forward to seeing your text.

 Cheers,
Adrian
----- Original Message ----- 
From: "Lou Berger" <[email-masked]>
To: "JP Vasseur" <[email-masked]>; "Adrian Farrel"
<[email-masked]>; "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, July 27, 2005 12:14 AM
Subject: Re: [Pce] Changes in the new revision of the architecture I-D

---

From: Lou Berger <[email-masked]>
Date: Wed, 27 Jul 2005 16:05:50 -0400

Typing some text up at the moment. Based on the immediate (and 
unforeseen) specific discussion my bet is that the text will hit just 
the tip of the iceberg!

Lou

---

From: JP Vasseur <[email-masked]>
Date: Wed, 27 Jul 2005 15:46:17 -0400

Hi Lou,

On Jul 27, 2005, at 10:33 AM, Lou Berger wrote:

> consider policy in the architecture (and the resulting  
> instantiation of the architecture).
>
> The point you raise is a reasonable one up due to such  
> consideration. Although rather than make a statement on the  
> requirement, I would ask the question, does policy being applied at  
> PCE2 need to know the identity of PCC?
> (I'm not sure...)
>

This is exactly what I was also about to reply. Indeed, I think that  
we all welcome your useful suggestion to devote more text to Policy  
in the architecture ID since it deserves more focus. On the other  
hand, this does require more discussion on the mailing list to  
determine what the requirements are. Furthermore, requirements should  
not be discussed in the architecture ID and it is pretty likely that  
new requirements related to policy will arise when discussing the  
application-specific requirements IDs.

Thanks.

JP.

>> content.
>> > - add a policy component to the PCE architecture(s) presented in  
>> section
>> 5,

---

From: Lou Berger <[email-masked]>
Date: Fri, 29 Jul 2005 08:22:47 -0400

JP,
         See below.
At 03:46 PM 7/27/2005, JP Vasseur wrote:

>determine what the requirements are.

100% agree.  Input from the community is need.

>Furthermore, requirements should

I think limiting the policy discussion in the arch document to 
ensuring it is include and excluding the definition of specific 
policies is reasonable.  I also agree that policy will come up in the 
definition of other WG documents.  Furthermore, it probably makes to 
have a standalone document devoted to the types/models of policy 
supported by PCE and to provide a framework for this.  I think we can 
discuss this further next week.

Lou

> <<https://www1.ietf.org/mailman/listinfo/pce>https://www1.ietf.org/mailman/listinfo/pce>https:// 
>
> >> www1.ietf.org/mailman/listinfo/pce
> >> >
> >

---

From: "Igor Bryskin" <[email-masked]>
Date: Fri, 29 Jul 2005 08:44:58 -0400

Hi JP,

I think that the architectureID is exactly the right context. It seems to me
a hole in the arhcitecture, what other context do you have in mind?

Igor

----- Original Message ----- 
From: "JP Vasseur" <[email-masked]>
To: "Lou Berger" <[email-masked]>; "Igor Bryskin" <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>; "Ash, Gerald R (Jerry), ALABS"
<[email-masked]>; <[email-masked]>
Sent: Wednesday, July 27, 2005 3:46 PM
Subject: Re: [Pce] Changes in the new revision of the architecture I-D

---

From: "Igor Bryskin" <[email-masked]>
Date: Fri, 29 Jul 2005 09:35:18 -0400

Hi,

This is from the architectureID:

 2) a. In "single PCE path computation," a single PCE is used to
         compute a given path in a domain. There may be multiple PCEs in
         a domain, but only one PCE per domain is involved in any single
         path computation.

      b. In "multiple PCE path computation," multiple PCEs are used to
         compute a given path in a domain.

   3) a. "Centralized computation model" refers to a model whereby all
         paths in a domain are computed by a single, centralized PCE.

      b. Conversely, "Distributed computation model" refers to the
         computation of paths in a domain being shared among multiple
         PCEs.
 I believe (as I once have indicated to the authors of the draft) that the
definition of Centralized/distributed path computation is too simplistic. A
PCC co-located with an LSP ingress LSR views centralized/distributed path
computation quite differently. When the PCC requests one or more paths from
a PCE,  it is concerned about how many other path computation requests will
have to be *issued* from the same or different PCCs in order to determine
all segments of the LSP path.Ideally, the ingress PCC would like to get 100%
explicit paths in the very first path computation response, because these
would be conceptually the best paths (best degree of satisfaction of
specified constraints, optimizations and diversities, which is virtually
impossible to achieve in subsequent requests). That's how PCC views the
Centralized path computation (it does not care whether the paths are
computed by a single PCE or a federation of PCEs). On the other hand,
additional path computations could be satisfied by the *same* (possibly
single in the domain) PCE, and it would still be adistributed path
computation as far as the PCC is concerned.On more general note, what IMO ID
lacks is the angle from the PCC's point of view. After all this is the guy
who ultimately pays for the service.Igor

---

From: JP Vasseur <[email-masked]>
Date: Fri, 29 Jul 2005 17:33:36 +0200

Hi Lou,

On Jul 29, 2005, at 2:22 PM, Lou Berger wrote:

> policies is reasonable.  I also agree that policy will come up in  
> the definition of other WG documents.  Furthermore, it probably  
> makes to have a standalone document devoted to the types/models of  
> policy supported by PCE and to provide a framework for this.  I  
> think we can discuss this further next week.
>

Sure, we're in sync.

cheers

JP.

>> >> > <<https://www1.ietf.org/mailman/listinfo/pce>https:// 
>> www1.ietf.org/mailman/listinfo/pce>https://