Subject: [Pce] Re: Management Issues

From: Stephen Morris <[email-masked]>
Date: Sun, 4 Sep 2005 22:30:41 +0100 (BST)

Hi All
Any comments on my message below :-)?
Best wishes
Stephen

--- Stephen Morris <[email-masked]> wrote:

> Hi All
> I have a few comments/suggestions about the
> architecture document sections 8.1, 8.3, & 10:
> 
> (1) Section 8.1
> I suggest we allow path computations to be initiated
> using SNMP (e.g., set a variable). This potentially
> opens up PCE technology to existing NMS/OSS
> products.
> Just a new (PCE) MIB module and some backend code is
> needed to integrate PCE technology in this case.
> 
> Path computation completion might be indicated by an
> informational notification or an SNMP response.
> Another approach might be the use of polling to
> allow
> a PCC to query PCE completion of a path request.
> 
> (2) Section 8.3
> Correctness - maybe provide ping access through
> SNMP?
> 
> (3) Section 10
> IANA might be needed for the MIB module?
> 
> (4) A further manageability item is deployment or
> software distribution. Let's say I have LSR X from
> vendor Y and I want to upgrade LSR X to include PCE
> capability. Or let's say I want to upgrade a number
> of
> LSRs to support PCE. While this is mostly an NMS/OSS
> issue (ftp, tftp etc.), the PCE element can help by
> supporting software version data (i.e., deployment
> data).
> 
> Best wishes
> Stephen Morris
> 
> 
> 		
>
___________________________________________________________
> 
> To help you stay safe and secure online, we've
> developed the all new Yahoo! Security Centre.
> http://uk.security.yahoo.com
> 

___________________________________________________________ 
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 5 Sep 2005 13:42:58 +0100

Hi Stephen,

We're just revising the Architecture I-D, so this is a timely discussion.

> > needed to integrate PCE technology in this case.

This is potentially feasible. I guess you are suggesting that it is easier for an existing NMS to utilize the SNMP code that it already includes than it is for it to support a new protocol.

I'm slightly concerned that the PCC-PCE request would normally be considered as transaction-based with no residue on the PCE. That is, the PCC sends a request which creates temporary state on the PCE. When the PCE sends its response, the state is deleted from the PCE. I'm not clear how this would work with SNMP because the NMS would need to create the state (all of the constraints related to the computation request) through a series of SETs. Once the state has been created, the computation can be easily triggered as you say, and there are a variety of ways to extract the solution as you suggest below (although I think Polling probably does not scale, and Notifications are not reliable). But how would we remove the state from the PCE?

I'd also point out that the amount of MIB objects we would be looking at for the set of constraints already under discussion is non-trivial, but this might not be such a problem since many of them have been demonstrated to be encodable in the MPLS TE MIB.

Are there any MIB modules you can point us at that do a similar thing in another context?

> > allow a PCC to query PCE completion of a path request.

> > Correctness - maybe provide ping access through

I presume you are refering to the 'correctness' of PCC-PCE connectivity, not to the correctness of the computed path. I'm not sure why you think providing access to 'ping' through SNMP would help for this issue. Since the PCC has connected to something that it believes is the correct PCE using an IP-based protocol we may assume that it has correctly attached to the IP address that it thinks it should have attached to. Using ping will confirm this, but will not confirm that we are attached to the correct PCE. That requires application level authentication.

> > IANA might be needed for the MIB module?

You're absolutely correct. Any MIB module that is written will definitely require IANA to assign a place in the MIB tree. Similarly, any protocols written for discovery or for PCC-PCE communicaitons will need IANA to manage thier codespaces.

This section, however, describes specific IANA actions requested by this document, and there are none.

> > of LSRs to support PCE. While this is mostly an 
> > NMS/OSS issue (ftp, tftp etc.), the PCE element can
> > help by supporting software version data (i.e., 
> > deployment data).

We need to distinguish standards and implementation issues. The version of a protocol supported is a standards issue. The version of a software package supported is an implementation issue. The former is the subject of information that should be carried in the protocol and might be made available in a standard MIB module. The latter is proprietary and cannot be standardised, but might be included in a proprietary MIB module or extension.

But you have raised an interesting point here. PCE should support graceful shut-down so that it can be upgraded. Such shut-down might involve:
- advertising a new status of 'unusable'
- closing the input queues to new requests
- flushing queued requests by 
  - rejecting them
  - passing them on to another PCE (which
    would have to respond to the PCC direct)
  - servicing them and responding

I will add something about this to the Architecture document.

Cheers,
Adrian

---

From: Stephen Morris <[email-masked]>
Date: Tue, 6 Sep 2005 22:48:18 +0100 (BST)

Hi Adrian & All
Comments inline.
Best wishes
Stephen

--- Adrian Farrel <[email-masked]> wrote:

> This is potentially feasible. I guess you are
> suggesting that it is easier for an existing NMS to
> utilize the SNMP code that it already includes than
> it is for it to support a new protocol.
> 
> I'm slightly concerned that the PCC-PCE request
> would normally be considered as transaction-based
> with no residue on the PCE. That is, the PCC sends a
> request which creates temporary state on the PCE.
> When the PCE sends its response, the state is
> deleted from the PCE. I'm not clear how this would
> work with SNMP because the NMS would need to create
> the state (all of the constraints related to the
> computation request) through a series of SETs. Once
> the state has been created, the computation can be
> easily triggered as you say, and there are a variety
> of ways to extract the solution as you suggest below
> (although I think Polling probably does not scale,
> and Notifications are not reliable). But how would
> we remove the state from the PCE?

My point was just in relation to gaining access to PCE
functions, i.e., initiating a path compute from an NMS
(or PCC). By allowing SNMP access, we open up the PCE
work to a huge number of existing NMS/OSS applications
- with minimal operational impact. So, an NMS selects
a PCE, specifies the required constraints and these
can then be communicated to the PCE either via SNMP or
via the PCC-PCE protocol. The path computation occurs
and is communicated back to the client either via SNMP
or via the PCC-PCE protocol. You're right in your
point about polling/notifications, but if a response
was lost, then the computation can always be
re-executed and modern networks are pretty reliable
:-).

> 
> I'd also point out that the amount of MIB objects we
> would be looking at for the set of constraints
> already under discussion is non-trivial, but this
> might not be such a problem since many of them have
> been demonstrated to be encodable in the MPLS TE
> MIB.
> 

None I can think of! Similar functionality has tended
to not be implemented in SNMP, resulting in skewed NMS
applications :-).

> I presume you are refering to the 'correctness' of
> PCC-PCE connectivity, not to the correctness of the
> computed path. I'm not sure why you think providing
> access to 'ping' through SNMP would help for this
> issue. Since the PCC has connected to something that
> it believes is the correct PCE using an IP-based
> protocol we may assume that it has correctly
> attached to the IP address that it thinks it should
> have attached to. Using ping will confirm this, but
> will not confirm that we are attached to the correct
> PCE. That requires application level authentication.
> 

Good points, though I was referring to the correctness
of the PCE path computation itself. Is this worth
thinking about? I'm kind of harking back to RFC2547,
which had no correctness or verification features,
i.e., you'd set up a VPN but there was no standard way
to check the configuration.

> You're absolutely correct. Any MIB module that is
> written will definitely require IANA to assign a
> place in the MIB tree. Similarly, any protocols
> written for discovery or for PCC-PCE communicaitons
> will need IANA to manage thier codespaces.
> 
> This section, however, describes specific IANA
> actions requested by this document, and there are
> none.
> 
> We need to distinguish standards and implementation
> issues. The version of a protocol supported is a
> standards issue. The version of a software package
> supported is an implementation issue. The former is
> the subject of information that should be carried in
> the protocol and might be made available in a
> standard MIB module. The latter is proprietary and
> cannot be standardised, but might be included in a
> proprietary MIB module or extension.
> 
> But you have raised an interesting point here. PCE
> should support graceful shut-down so that it can be
> upgraded. Such shut-down might involve: