Subject: [mpls] Plan to make draft-ietf-mpls-tp-te-mib-00.txt

From: "Nattrass, William W" <[email-masked]>
Date: Thu, 22 Sep 2011 13:41:15 -0400

Re:  "There is a plan to make draft-ietf-mpls-tp-te-mib-00.txt be a read-only MIB (it currently contains relatively few writeable objects). This is compatible with my understanding of how MIBs are often used. However, this also varies from normal IETF convention where MIBs contain both read and write objects.

We therefore are asking for comments from the WG regarding whether people are okay with updating draft-ietf-mpls-tp-te-mib-00.txt to be read only."

Question:  Would making the MIB read-only,  preclude the ability for network operators to declare standardized names within the MIB for their tunnels?  I ask,  because I believe network operators will want to assign "network level" names that will fit/(and be used) by their existing operations support systems.

Bill Nattrass

Telcordia

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 22 Sep 2011 13:46:00 -0400

On Sep 22, 2011, at 1:41 PM, Nattrass, William W wrote:

> Re:  “There is a plan to make draft-ietf-mpls-tp-te-mib-00.txt be a read-only MIB (it currently contains relatively few writeable objects). This is compatible with my understanding of how MIBs are often used. However, this also varies from normal IETF convention where MIBs contain both read and write objects.
>  
> We therefore are asking for comments from the WG regarding whether people are okay with updating draft-ietf-mpls-tp-te-mib-00.txt to be read only.”
>  
>  
>  

	No, not at all assuming that you configured the TE functions using a different means such as Netconf/XML/web services/CLI/etc...  The MIB being read-only is only from the external observer's point of view. The internal device has the freedom to change anything it likes.

	--Tom

>  
> Bill Nattrass
> Telcordia
>  
>  
>  
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: Kannan KV Sampath <[email-masked]>
Date: Fri, 23 Sep 2011 02:40:22 +0530

Hi Tom,

Thanks for your reply to this email, and to my other email.
Is it possible to elaborate on what you mean by "The internal device has the freedom to change anything it likes"?

When we have the standard IETF MIB with read-write, it gives an uniformity and standardization in configuration and it gives additional support to the protocol RFCs to make it clear on what are configurable parameters to tune, and what are not tune-able. This kind of uniformity (if different vendor equipments support the same standard read-write MIB) will help (service providers) in even thinking of having a common NMS system to configure equipments from different vendors by having simple adapters.
If we make them as read-only, will it not result in different vendors interpreting it differently?

Thanks and Regards,
Kannan

From: Thomas Nadeau [mailto:[email-masked]]
Sent: Thursday, September 22, 2011 11:16 PM
To: Nattrass, William W <[email-masked]>
Cc: [email-masked]' <[email-masked]>
Subject: Re: [mpls] Plan to make draft-ietf-mpls-tp-te-mib-00.txt

--Tom

Bill Nattrass
Telcordia

_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls

===============================================================================
Please refer to http://www.aricent.com/legal/email_disclaimer.html
for important disclosures regarding this electronic communication.
===============================================================================

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 22 Sep 2011 18:01:03 -0400

On Sep 22, 2011, at 5:10 PM, Kannan KV Sampath wrote:

> When we have the standard IETF MIB with read-write, it gives an uniformity and standardization in configuration

	That is a myth because SNMP is a poor model for configuration management. This is precisely why most real production networks do not use it, and is precisely why Netconf was invented.

> and it gives additional support to the protocol RFCs to make it clear on what are configurable parameters to tune, and what are not tune-able.

	That is also a myth because in %100 of the cases, vendors produce proprietary extensions and features related to the objects you find in that MIB. This means that you are then back to square one with regard to the "uniformity" claim because you have to do special things for different devices - even from the same vendor!

> This kind of uniformity (if different vendor equipments support the same standard read-write MIB) will help (service providers) in even thinking of having a common NMS system to configure equipments from different vendors by having simple adapters.

	That is only true in terms of monitoring.  SNMP is well suited for high volume, high rate polling.  It fails miserably in terms of provisioning, and this is why both vendors have really not implemented it in a writable way, nor have SPs or enterprises really used SNMP for provisioning capabilities. I welcome comments from folks at operators on this, but it was my experience when I worked at an operator that SNMP provided no benefit in terms of provisioning in general; that is why we used each vendors' CLI or Netconf/XML interface for provisioning.

	--Tom