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

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" <Stephen.Morris@marconi.com>
To: "'Adrian Farrel'" <adrian@olddog.co.uk>
Cc: <pce@ietf.org>
Sent: Friday, March 11, 2005 4:13 PM
Subject: RE: [Pce] Opinion on adopting draft-ash-pce-architecture-01 as a
PCE WG document ?

> 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:adrian@olddog.co.uk]
> Sent: 09 March 2005 18:53
> To: Morris, Stephen
> Cc: pce@ietf.org
> 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
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce