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

From: "Morris, Stephen" <[email-masked]>
Date: Fri, 11 Mar 2005 11:13:56 -0500

Thanks for the comments Adrian
I just had one observation. You're right, there is a fine line between
operational and implementation choices. I'm increasingly thinking that
manageability is a genuine architectural quality attribute (along with
extensibility, availability, security, etc.). 

Ultimately, manageability (e.g., of a PCE entity) is embodied in the
workflows that occur during use. Leaving this until definition of the MIB
module almost seems a little late for consideration of manageability (if the
latter is architectural :-)). So, ideally I try to think about manageability
prior to MIB design. I'm not sure when is the best time in this context :-).

Does anyone have any thoughts on this?
Best wishes
Stephen

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]]
Sent: 09 March 2005 18:53
To: Morris, Stephen
Cc: [email-masked]
Subject: Re: [Pce] Opinion on adopting draft-ash-pce-architecture-01 as
a PCE WG document ?

Hi,

Thanks for your comments.
In line...

Adrian

> 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

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.

> 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

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

> 3) In section 4.4, does anyone actually create CE-to-CE LSPs? This seems
not
> 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.

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

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 12 Mar 2005 16:29:02 -0000

Oh, I agree completely.
(draft-farrel-rtg-manageability-requirements-00.txt)

So, yes, the manageability of PCE must show up both in the architecture
and in the requirements.

Thanks,
Adrian
----- Original Message ----- 
From: "Morris, Stephen" <[email-masked]>
To: "'Adrian Farrel'" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, March 11, 2005 4:13 PM
Subject: RE: [Pce] Opinion on adopting draft-ash-pce-architecture-01 as a
PCE WG document ?