Subject: RE: [Pce] Opinion on adopting draft-ash-pce-architecture-01 as aP CE WG document ?

From: "Morris, Stephen" <[email-masked]>
Date: Wed, 9 Mar 2005 13:24:18 -0500

Hi Adrian
Very good document. I vote yes.

I had a few minor comments.

1) Is there an assumption that the PCE would be single tasking in nature? If
it handles multiple path requests simultaneously then would this have an
effect on the result? Maybe a comment is needed to clarify this
2) I'm interested to see how the PCE capabilities (e.g., around section 4.4)
would be exposed to an external management system. Maybe a few lines or a
placeholder paragraph would keep this in scope, e.g., the API might be
SNMP-based or use an RPC mechanism
3) In section 4.4, does anyone actually create CE-to-CE LSPs? This seems not
to fit in the context of RFC2547
4) Section 4.5 heading: "Plan" should be "Plane"

I look forward to the next draft!
Best wishes
Stephen Morris

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Adrian Farrel
Sent: 08 March 2005 22:23
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [Pce] Opinion on adopting draft-ash-pce-architecture-01 as
aPCE WG document ?

Hi,

Yes (and thanks for the off-line discussions).

It seems that the co-chairs are a little confused about what is an
architecture I-D and what is a framework I-D.
We will get some advice form our ADs when we meet them tomorrow morning,
and come back to y'all.

With regard to defining "what is state?"; this is clearly important to the
definition of what is "stateful". There is clearly a very wide spectrum of
state information, and many of the differences in opinion about the
meta-question must be dependent on different opinions of what comprises
state and how much state we are talking about. Clearly more discussion and
debate is needed.

In the context of a framework I-D, it is probably sufficient to state a
desire for (or against) stateful PCE, and to give a few examples to set
expectations of the range of potential options. In the context of a
requirements draft, it is necessary to understand which scenarios are
being addressed and what state is required to be retained.

So where does an architecture I-D fit in?
I'm not sure.

Adrian

----- Original Message ----- 
From: "dimitri papadimitriou" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>; "JP Vasseur" <[email-masked]>;
<[email-masked]>
Sent: Tuesday, March 08, 2005 10:08 PM
Subject: Re: [Pce] Opinion on adopting draft-ash-pce-architecture-01 as
aPCE WG document ?

>
> hi adrian, i don't think the point has been well understood then, the
> question is not whether you can or not find an example where it could be
> used but whether it is appropriate as part of this "architecture"
document
>
> now, to be more accurate here it can be advisable to start discussing
> what a path computation state more precisely means (in particular make
> the distinction between a path state and path computation state since
> they are different beasts) - which information it maintains and how this
> maintenance is expected to occur e.g. incremental - otherwise
> determination of the feasibility of this approach sounds difficult as
> part of this document
>
> hope this clarifies my concerns,
> - dimitri.
>
> Adrian Farrel wrote:
> > Hi Dimitri,
> >
> >
> >>from my record the "statefull PCE" comment is also to be addressed as
> >>cases for which this would be useful is not described in the document
> >
> >
> > I beg to differ.
> > Section 6.8 contains...
> >
> >    Note that although this allows for optimal path
> >    computation and increased path computation success
> >
> > ...which is an implicit use case.
> >
> > But also section 6.8 contains...
> >    There is benefit in knowing which LSPs exist, and their routing, to
> >    support such applications as placing a high priority LSP in a
crowded
> >    network such that it preempts as few other LSPs as possible.  Note
that
> >    preempting based on the minimum number of links might not result in
the
> >    smallest number of LSPs being disrupted.  Another application
concerns
> >    the construction and maintenance of a Virtual Network Topology
[MRN].
> >    It is also helpful to understand which other LSPs exist in the
network
> >    in order to decide how to manage the forward adjacencies that exist
or
> >    need to be set up. The cost-benefit of stateful PCE computation
would
> > be
> >    helpful to determine if the benefit in path computation is
sufficient
> > to
> >    offset the additional drain on the network computational resources.
> >
> > ...which gives several applications.
> >
> >
> >>it may be actually be interesting to list all the comments that would
> >>require further work
> >
> >
> > Yes, I think that would be useful.
> > In fact, I hope the editor is doing this to track the work for the
draft.
> >
> > Do either of these comments lead you to an answer to JP's question?
> >
> > Thanks,
> > Adrian
> >
> >
> >>JP Vasseur wrote:
> >>
> >>>All,
> >>>
> >>>We discussed yesterday draft-ash-pce-architecure-01
> >>>
> >
> >
(http://www.ietf.org/internet-drafts/draft-ash-pce-architecture-01.txt)
> >
> >>>for which there was a pretty large consensus in the room to adopt it
> >
> > as
> >
> >>>a WG document.
> >>>
> >>>Let us know bring this question on the list.
> >>>
> >>>Could you please express your opinion on whether this draft should be
> >>>adopted as a working group document (Y/N) ?
> >>>
> >>>ps: note that comments were made yesterday (include a paragraph on
> >>>unsolicited PCE path computation, ...) which should be taken care of
> >
> > in
> >
> >>>the next revision.
> >
> >
> >
> > .
> >
>
>

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

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 9 Mar 2005 18:53:26 -0000

Hi,

Thanks for your comments.
In line...

Adrian

> effect on the result? Maybe a comment is needed to clarify this

Certainly there is no attempt to constrain (or even discuss)
implementation choices.

Clearly different algorithms or orders of computation will make a
difference to the paths that are derived.
In fact, using multiple PCEs responsible for a single domain would have
the same effect.

However, this is not SPF.
- The MPLS TE path computed by PCE must be the "best" at
   the time of computation.
- It is always possible that a computed path cannot be provisioned
  (failure of resources, provisioning of other LSPs, etc., etc., etc.)
Thus, I believe that this is an implementaiton issue only.

We could add a few wise words to this if the WG thinks it would be
helpful, but I don't want to go into much detail in the draft.

> SNMP-based or use an RPC mechanism

OK. I think the ability to configure, manage and inspect a PCE will be the
subject of a MIB module. However, there is a fine line for us to draw.
Operational or implementation choices that describe the computation in a
PCE are out of scope. Functioning of the protocols are in scope. Thus
(silly example!):
- configure the number of CPUs that can be dedicated to PCE processing
    - out of scope
- inspect the value for CPU congestion and capablities reported by the
  PCE discovery protocol
    - in scope

> to fit in the context of RFC2547

LSPs are not only used in the context of RFC2547 :-)

Hint1: GMPLS Overlay draft
Hint2: GVPN draft

> 4) Section 4.5 heading: "Plan" should be "Plane"

Thanks.

---

From: JP Vasseur <[email-masked]>
Date: Wed, 9 Mar 2005 17:07:38 -0600

Hi,

Few comments in line,

> In fact, using multiple PCEs responsible for a single domain would have

Fully agree with Adrian's comments here. Note that indeed, an 
implementation may decide to serialize path computation requests or 
perform some requests packing under specific conditions but as already 
pointed out, this is implementation specific.

> However, this is not SPF.

Just to avoid confusion ... of course, CSPF algorithms could be used on 
the PCE.

JP.

>> 2) I'm interested to see how the PCE capabilities (e.g., around 
>> section
> 4.4)
>> would be exposed to an external management system. Maybe a few lines 
>> or
> a
>> 3) In section 4.4, does anyone actually create CE-to-CE LSPs? This 
>> seems
> not