Subject: [Pce] Concerns with PCE MIB Drafts

From: Simon Wingrove <[email-masked]>
Date: Tue, 6 Jul 2010 17:44:56 +0100

Hi all,

I've been examining the MIB drafts currently in the PCE WG and have a few concerns on some specific parts (see below).  I'm hoping to get some feedback from the WG on these.

Best wishes,

Simon Wingrove
Network Technologies Division
Metaswitch Networks
[email-masked]<mailto:[email-masked]>
www.metaswitch.com<http://www.metaswitch.com>

Concerns:

(C1)  PcePcepIdentifier is an LDP identifier
The PcePcepIdentifier object is used as the index for a PCE peer, and is described with the text "The LDP identifier is a six octet quantity which is used to identify a PCE client."  I think an IP address should be used instead.
-  The PCEP Peer MIB table uses this object as the index for peers, but where would the ID have been learnt from?
-  The PCE discovery protocol identifies a PCE purely by IP address: this seems to be an easier way to identify a PCC/PCE throughout the MIBs.

(C2)  There is no PCEP MIB for a PCE, only a PCC
The PCEP MIB seems to concern a PCEP implementation for a PCC.  We need a MIB table for a PCEP implementation for a PCE.  I believe that the original intention of the pcePcepClientTable was to serve both roles (see http://www.ietf.org/proceedings/73/slides/pce-9/pce-9.htm).  Is this the case?
-  If so, I think that we should clarify this in the table's description.
-  Indeed if this is the case, I'm not sure why the table is so named.  Perhaps pcePcepEntityTable or pcePcepSpeakerTable would be more suitable; do people agree?

(C3)  Use of IP Addresses on the MIB
The PCE Discovery MIB table provides two objects to describe the IP addresses of a PCE, pceDiscoveryIPv4Address and pceDiscoveryIPv6Address.  I suggest that this should be represented by two MIB objects pceDiscoveryIPAddressType and pceDiscoveryIPAddress instead.
-  Since the PCE discovery RFC (4674<http://tools.ietf.org/html/rfc4674>) identifies a PCE purely by IP address, a discovered PCE will only ever have exactly one address, either IPv4 or IPv6, never both.
-  There are examples of this way of representing IP addresses in the MGMD MIB, RFC 5519<http://tools.ietf.org/html/rfc5519>.

(C4)  Stats in the PCEP Session MIB Table do not persist
The PCEP MIB contains session information in pcePcepSessionTable.  I think this information should belong on the peer table instead.
-  My understanding is that an entry in this table exists when a session to a peer exists.
-  However, this table contains stats objects such as pcePcepSesssionCorruptedMsgs, the number of corrupted messages received during session.
-  I think that this information would be helpful to a MIB user after the session has ended, and the table entry gone away.

(C5)  Gauges and Counters
The stats fields pceDiscoveryKnownPCEs and pceDiscoveryActivePCEs are of type Counter32, but should be of type Gauge32.  Counters should increase, never decrease, and are allowed to wrap (see RFC 2578<http://tools.ietf.org/html/rfc2578>, sections 7.1.6-7).  A Gauge is more appropriate for a statistic that can increase or decrease.

---

From: "Agrahara S Kiran Koushik" <[email-masked]>
Date: Mon, 26 Jul 2010 18:48:30 +0200

Hi Simon,
Thanks for the review and comments. We will try to address
most of these in our next revision.

Thanks
Kiran. 
  ----- Original Message ----- 
  From: Simon Wingrove 
  To: [email-masked] 
  Sent: Tuesday, July 06, 2010 6:44 PM
  Subject: [Pce] Concerns with PCE MIB Drafts

  Hi all,

  Best wishes,
  Simon Wingrove
  Network Technologies Division
  Metaswitch Networks 
  [email-masked]
  www.metaswitch.com

  Concerns:

  (C3)  Use of IP Addresses on the MIB
  The PCE Discovery MIB table provides two objects to describe the IP addresses of a PCE, pceDiscoveryIPv4Address and pceDiscoveryIPv6Address.  I suggest that this should be represented by two MIB objects pceDiscoveryIPAddressType and pceDiscoveryIPAddress instead.
  -  Since the PCE discovery RFC (4674) identifies a PCE purely by IP address, a discovered PCE will only ever have exactly one address, either IPv4 or IPv6, never both.
  -  There are examples of this way of representing IP addresses in the MGMD MIB, RFC 5519.

  (C5) Gauges and Counters
  The stats fields pceDiscoveryKnownPCEs and pceDiscoveryActivePCEs are of type Counter32, but should be of type Gauge32.  Counters should increase, never decrease, and are allowed to wrap (see RFC 2578, sections 7.1.6-7).  A Gauge is more appropriate for a statistic that can increase or decrease.

------------------------------------------------------------------------------

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