Re: [mpls] seeking consensus on making draft-ietf-mpls-tp-te-mib read-only

[Muly Ilan <[e-mail]>]

Hi Curtis,

I agree with some (most) of the points you listed below.
It's not my intention to start a debate on the pros/cons of SNMP as a provisioning protocol.

Currently, our products do not support NETCONF. I believe this is the case for other vendors as well.

In addition, we already support the MPLS-TE-STD-MIB and MPLS-LSR-STD-MIB for MPLS-TE provisioning. So for us the shortest TTM is to add MIB extensions for MPLS-TP provisioning. I believe this is the case for other vendors as well.

Since we need the functionality of mapping the MPLS-TP identifiers, Global_ID::Node_ID, to the ingress/egress LSR identifier in existing mplsTunnelTable the mpls-tp-te-mib in its present contents, with read-write/read-create objects, is good for us.


Muly

-----Original Message-----
From: Curtis Villamizar [mailto:[e-mail]] 
Sent: Tuesday, February 04, 2014 10:09 PM
To: Muly Ilan
Cc: Loa Andersson; [e-mail]; [e-mail]; [e-mail]
Subject: Re: [mpls] seeking consensus on making draft-ietf-mpls-tp-te-mib read-only


Support these as read-only.

See inline for comments on prior post.

In message <[e-mail]>
Muly Ilan writes:
> 
> Oppose.
>  
> In our implementation we need read-write/read-create access for the TE 
> and LSR extensions.
>  
> Specifically, the new functionality provided by mplsIdGlobalId, 
> mplsIdNodeId and mplsTunnelExtNodeConfigTable can only be realized by 
> read-write/read-create objects.

The reason that people in operations and equipment vendors both generally oppose read/write MIBs is that they are a bad way to configure equipment.  Some reasons are:

  1. MIB sets using UDP are unreliable and need to be confirmed.

  2. MIB sets generally require small configuration change operations.
     Sparse bulk set operations are not supported.

  3. Large configuration changes using MIB requires lots of small
     operations followed by confirmation in most cases after each
     small operation.  Large atomic operations are not possible.

  4. Large configuration changes are common for providers that batch
     changes and apply them during "maintenance windows" during very
     off-peak hours such that should something go wrong or small
     disruptions occur, the impact to most enterprises is minimal.

  5. Configuration changes, both small and large are better
     accomplished through other means such as NETCONF.

Note that some tools based on the Yang language can translate a MIB into an XML dialect suitable for use with NETCONF.  This may be a good transition strategy if you had planned to use read/write MIB.

> Regards,
>  
> Muly Ilan

Curtis

> -----Original Message-----
> From: mpls [mailto:[e-mail]] On Behalf Of Loa Andersson
> Sent: Tuesday, February 04, 2014 8:55 AM
> To: [e-mail]
> Cc: [e-mail]; 
> [e-mail]
> Subject: [mpls] seeking consensus on making draft-ietf-mpls-tp-te-mib 
> read-only
>  
> Working Group,
>  
> We have just recalled draft-ietf-mpls-tp-te-mib from the IESG to the 
> working group for more work. We have a series of comments that are 
> mostly for clarification. However the main reason for recalling the 
> document is that there is one point where we need to confirm working 
> group consensus.
>  
> The IETF, the working group and the MIB Doctors are today very 
> reluctant to produce read-write MIB modules. The current draft is 
> read-write for a few objects, this is based on a consensus call for an 
> earlier discussion, however the consensus call was not clear. It can 
> be taken to mean both that we want to go with read-write objects and 
> that we want to see read-only. Is it clear that it has been 
> interpreted differently by different individuals.
>  
> The authors and chairs have discussed the issue and we have a rough 
> consensus that we want the MIB module(s) to be read-only.
>  
> We therefore are asking the working group if this is OK for the MIB
> module(s) in the current document. Please indicate Support or Oppose 
> for this MIB (draft-ietf-mpls-tp-te-mib) to be read-only.
>  
> Please send your comments to the working group mailing list before 
> February 18, 2014.
>  
> Loa
> for the MPLS wg chairs