Re: [MIB-DOCTORS] Early MIB Dr. Review of draft-ietf-idr-bgp4-mibv2-06.txt

["Joan Cucchiara" <[e-mail]>]

Hi Jeff,

First want to apologize for the delay in responding.
I have deleted the parts of the email where we have agreed.
See inline below for more discussion.

Thanks,
  Joan


----- Original Message ----- 
From: "Jeffrey Haas" <[e-mail]>
To: "Joan Cucchiara" <[e-mail]>
Cc: "Jeffrey Haas" <[e-mail]>; "Dan Romascanu (E-mail)" 
<[e-mail]>; "David

Ward" <[e-mail]>; <[e-mail]>; "MIB Doctors (E-mail)" 
<[e-mail]>
Sent: Tuesday, June 10, 2008 10:29 PM
Subject: Re: Early MIB Dr. Review of draft-ietf-idr-bgp4-mibv2-06.txt


>>>> E: f(BGP4-MIB), (1228,5) Item "bgpNlriPrefixType" has invalid
>>>> value for MAX-ACCESS
>>
>> This is not listed in the INDEX clause and it has a MAX-ACCESS of
>> "not-accessible".    Is this supposed to be part of the INDEX?  If not,
>> then it should have a different type of MAX-ACCESS.
>
> I've made this read-only and added it to the bgpAfPathAttributesGroup
> OBJECT-GROUP.
>
>>>> W: f(BGP4-MIB), (2689,5) Table "bgpRcvdPathAttrTable" and
>>>> Row "bgpPathAttrEntry" should have same name prefix
>>>
>>> This issue was previously existing for earlier versions of this MIB and
>>> cannot be changed.
>>>
>>
>> I would encourage the working group to fix these sorts of obvious 
>> mistakes
>> rather than carry them forward for a few reasons:
>>
>> 1) A great deal of this MIB is changing already so the working group may
>> want
>> to reconsider fixing this mistake,
>> 2) MIB tools which generate code "might" find errors here and so 
>> developers
>> are left dealing with fixing these sorts of bugs by going in and editing
>> files that are generated (usually not what we want to do).
>> 3)  If the intention is to make this MIB one that is the basis for other
>> BGP
>> MIBs then having a solid foundation to build upon is important IMHO, so
>> again
>> would request that the working group consider this.  Certainly, I will
>> abide
>> by their decision.
>
> This portion of the MIB is widely deployed.  I'm going to recommend
> against changing this.  If you feel strongly otherwise, let's grab Bert
> and/or the relevant ops-nm folk and go offlist for the discussion.

I think it's best to keep these sorts of discussions on
the list since (as you point out) the previous version(s) of
this MIB are widely deployed.  If folks have an opinion
about this issue or other parts of the MIB draft,
this is an opportunity for them to give it.

Speaking more broadly than just this issue for a moment:
I think there is some misunderstandings here with what
typically happens when MIBs
are revised.  Vendors support both (or even several)
versions of a MIB, leaving it to the customer to decide
what they want to deploy.  Sometimes customers have supported
different versions of the same MIB, and when customers
do (eventually) upgrade to the latest and greatest
MIB, this process is done with much testing and usually
involves testing the entirety of the MIB (not just parts that changed).
While there are benefits to keeping parts of the MIB the same,
those benefits are more limited than one might think.

According to http://www.ietf.org/ID-nits.html
  All MIB modules SHOULD have correct SYNTAX, so they should compile cleanly 
using:
     smilint -m -s -l 6 -i namelength-32 <module>

(disregarding only those warnings pertaining to names longer than 32
characters)

Getting back to this specific SMI mistake, you state that the MIB
is widely deployed, but since this is an SMI mistake, and
since many folks probably fix this so that the MIB can
be downloaded and/or compiled by MIB tools, what exactly
is being deployed?  Is it the fixed syntax, or is it this MIB as written?


>
>>>> W: f(BGP4-MIB), (3144,19) Variable "bgpPeerRemoteAddr" in notification
>>>> "bgpEstablishedNotification" is an index for a table
>>>>
>>>> W: f(BGP4-MIB), (3158,19) Variable "bgpPeerRemoteAddr" in notification
>>>> "bgpBackwardTransNotification" is an index for a table
>>>
>>> These issues are the result of the SMIv1 to SMIv2 porting issues that
>>> were largely addressed by RFC 4273.  Consensus at the time was to not
>>> alter the MAX-ACCESS of those objects.
>>>
>>
>> Would again suggest fixing mistakes likes these for the reasons stated
>> above
>> wrt the other error.
>
> Same as above
>
>>> One of the most contentious portions of feedback to prior structure
>>> attempts for this MIB was configuration objects or read-write objects
>>> vs. no-config and read-only.  The working group consensus was that the
>>> complexity of BGP configuration, especially with regards to policy, was
>>> so complicated and vendor-specific that trying to represent it in a MIB
>>> was inappropriate.  The remaining vendor-common functionality, such as
>>> configuring BGP peering sessions, was the MIB would interfere with
>>> required vendor-specific knobs.
>>>
>>
>> Please point me to the relevant emails in the archive.  I would like to
>> understand this because the motivation seems contrary to what the IETF is
>> trying to do
>> with Standards.
>
> Attempting to locate the relevant mails was one of biggest reasons for
> the delay in my latest response.
>
> As best I can tell, most of this discussion took place either in
> hallways discussions with likely implementors or via e-mail that doesn't
> seem to have survived a server transition.  The only idr specific mail I
> can find on this particular topic is:
>
> Date: Wed, 23 Aug 2006 16:30:13 -0400
> From: Jeffrey Haas <[e-mail]>
> [...]
> I've factored the complex functionality out, removed configuration
> objects[...]
>
> Here is my best memory of the concerns from that time:
> 1. Many operators were *very* uncomfortable with the idea that any of
> their BGP configuration could be affected by SNMP, even while protected
> via SNMPv3.  This opinion was based upon feedback garnered from
> inquiries to the NANOG mailing list and hallway conversation during at
> least one NANOG conference.
>

Yes, I agree, but this issue is not just with the BGP MIB.  Many operators
are not comfortable with using SNMP for configuration, and many vendors
provide a way to disable configuring with SNMP.

Additionally, most MIBs being developed by the IETF today have read-only
conformance statements so that the vendors are compliant to the standard
MIB.



> 2. Several likely implementors had issue with the fact that the
> configuration of the BGP peering session given the MIB structure was
> incomplete enough as to represent an obstacle to configuration.  Given
> that the goal of the time to to represent only components of the BGP
> protocol that were going through standardization, the lack of
> configuration for components that were operationally necessary meant
> that the MIB was at best useless and at worst dangerous when being used
> with various extensions.  For example, since the MIB did not support
> configuration of BGP MPLS VPNs, configuration changes via this MIB could
> potentially disrupt the relevant configuration for that kind of network.
>
> This implied that additional vendor-specific enterprise mibs would be
> required to flesh out configuration, even for IETF standard track features
>
> 3. The majority of the configuration represented in this MIB would only
> affect peering session configuration.  Most of BGP is operationally
> based upon "policy".  Policy, while abstractly referred to in the BGP
> base RFC as the Policy Information Base, is highly vendor specific.
> Without policy, it's not very useful to configure BGP via SNMP.  Also,
> given the vendor specific nature of a number of policy elements,
> attempting to standardize policy in SNMP seemed a somewhat futile and
> highly contentious effort.


Granted there are complexities when other MIB modules
are involved, but how does that differ with respect to CLI?  There will
be certain CLI commands issued before others and this has to be carefully
thought out and executed.

The upshot is that I believe this could be done using SNMP and carefully
crafted commands, similar to what is done for the CLI.



>
> If it's still your belief that this MIB should have additional
> configuration objects given the above, let's fork another e-mail thread
> to gather working group consensus.  I would welcome the working group's
> feedback on this topic.


Seeing as this seems to have taken place almost 2 years ago, I think that
writing an email to ask for current opinion would be appropriate.
I would specifically like to hear from any large enterprises that may
be using SNMP for configuring BGP.  So as we discussed, can work on
this email.



>
> [MIB Structure]
>> Yes, but there are other tables, for example timers, which are grouped
>> based on the type of data (i.e. timer) that it is, when some of this is
>> really related to the bgp router information or the bgp peer connection.
>> An analogy might be that some of MIB constructs are approached as
>> object-oriented and some is classic C data structs.   (Modeling a bgpPeer
>> and bgpPeer's connection
>> which is OO, and Timer data which is C.)
>>
>> Sometimes this type of mixing of two styles is not at all a concern, but 
>> I
>> think there is a better organization that could be done with this MIB. 
>> So,
>> for
>> example, a table which contains info on this Bgp's Instance (so some of 
>> the
>> timer objects
>> and other objects  that were  previously configurable would likely be in
>> this table),
>> the current bgpAfPeerTable, and
>> then possibly a third table to contain information regarding the actual
>> session
>> information (i.e. counters which change when the FSM to established).
>
> I've spent some time thinking about this issue and I believe I
> understand your concern at this point.
>
> The bgpPeerAfTable represents the core elements of what define the
> transport end points of a peering session and the session status.  I
> believe this to be inseparable data and wouldn't recommending factoring
> this information into another table.  (Note that I've already
> reorganized the columns in this table to group the indices as you've
> previously suggested.)
>
> With regard to the per-peer timers, I agree that they could be
> potentially better organized.  bgpPeerAfEventTimesTable,
> bgpPeerAfConfiguredTimersTable and bgpPeerAfNegotiatedTimesTable could
> be merged into a single table.  Would this satisfy part of your concern?
> Their layout was somewhat an artifact of previous structure of this MIB,
> some of it unpublished.
>

What I was thinking actually was to not separate Timer objects into
specific "timer" tables, but to group these with their respective categories
(i.e. bgp manager instance, bgp peer, session).

However, I say this assuming that there will be more separation than
currently exists. For example, if the bgpPeerAfTable
is observed, you have comments, Local, Remote, Session Status in one table.
The Local refers to (I think?) what you call the "bgp manager instance",
remote is the "peer" and session status is the "session".
Timers could also be grouped in these categories.

Taking this all a step farther, would suggest to create a
Local (bgp manager instance table) and a remote table (which may or may not
also include session objects).

Does this seem like a reasonable suggestion?  (My 2 cents is that the 
structure
of this MIB has not changed too much since the 1994 MIB.  Yes, objects and
tables have been added, but the original structure was flat and this 
structure
is also flat, one table and having all the other tables AUGMENT from it).


DISCONTINUITY DISCUSSION:


>> I think this is related to the issue of the counters Discontinuity also.
>> Some counters
>> are related to the Peer and some are related to the established session.
>
> Upon further consideration of likely discontinuity events, the only
> major discontinuity event that requires a discontinuity object IMO is
> one that represents when this BGP management instance was last started.
> This would cover all arbitrary abstract indexes that could change
> meaning after a reboot.  Per-peer values that depend on the state of a
> BGP session are already documented as such.  These similarly would reset
> when the BGP management instance restarts.


So is the BGP management instance, refer the "entity" on the router which
starts and maintains the BGP protocol?


>
> Would a single discontinuity object satisfy your concerns?  If so, I
> would propose the following:
>
>    --
>    -- Discontinuity
>    --
>    bgpDiscontinuityTime OBJECT-TYPE
>        SYNTAX TimeStamp
>        MAX-ACCESS read-only
>        STATUS current
>        DESCRIPTION
>            "The value of sysUpTime at the most recent occasion at which
>             this BGP management instance has suffered a discontinuity.
>
>             In particular, tables with abstract indexes such as
>             bgpAfPathAttrIndex, bgpAsPathIndex and
>             bgpAfPathAttrUnknownIndex are not guaranteed to contain the
>             same data across discontinuities."
>         ::= { bgp 13 }
>


If the value of the indices change
and can be different from the objects, then what is the point of
having the objects?


I would like to break this down into a specific discussion
prior to agreeing on one Discontinuity Object (or more than one).

discontinuity scenarios in BGP4 Protocol:

* SNMP agent restarts (sysUpTime is affected) which is default behavior
* bgp entity restarts (what you are calling the BGP Management instance?)
   (assume this is separate from SNMP agent)
* peer restarts/lost connection
* specific session goes from established state to some other state

Are there any other scenarios?


The following (I think?) would be affected by SNMP Agent Restarts, bgp 
Entity
Restarts, peer restarts, and FSM establish state transition.  Is this
correct?


bgpPeerAfInUpdates
bgpPeerAfOutUpdates
bgpPeerAfFsmEstablishedTransitions
bgpPeerAfInTotalMessages
bgpPeerAfOutTotalMessages


[So more of a question for the WG,
Are the bgpPeerAfInTotalMessages and bgpPeerAfOutTotalMessages
counters useful? ]


[As an aside, the bgpPrefixCountersTable should be renamed to
remove the word counter since these are actually Gauge32.]

bgpAfPathAttrCounter - Typically, these values are not
included in MIBs and are calculated by the NMS.  However, if
this needs to be in the MIB, then
think that it probably should be a Gauge32, rather than a
Counter32.  (You could make this a counter, but then would need
to consider this object when a discontinuity occurs and
include that information in the DESCRIPTION).

To quote from RFC2578:

"7.1.6.  Counter32

   The Counter32 type represents a non-negative integer which
   monotonically increases until it reaches a maximum value of 2^32-1
   (4294967295 decimal), when it wraps around and starts increasing
   again from zero.

   Counters have no defined "initial" value, and thus, a single value of
   a Counter has (in general) no information content.  Discontinuities
   in the monotonically increasing value normally occur at re-
   initialization of the management system, and at other times as
   specified in the description of an object-type using this ASN.1 type.
   If such other times can occur, for example, the creation of an object
   instance at times other than re-initialization, then a corresponding
   object should be defined, with an appropriate SYNTAX clause, to
   indicate the last discontinuity.  Examples of appropriate SYNTAX
   clause include:  TimeStamp (a textual convention defined in [3]),
   DateAndTime (another textual convention from [3]) or TimeTicks.

   The value of the MAX-ACCESS clause for objects with a SYNTAX clause
   value of Counter32 is either "read-only" or "accessible-for-notify".

   A DEFVAL clause is not allowed for objects with a SYNTAX clause value
   of Counter32.

7.1.7.  Gauge32

   The Gauge32 type represents a non-negative integer, which may
   increase or decrease, but shall never exceed a maximum value, nor
   fall below a minimum value.  The maximum value can not be greater
   than 2^32-1 (4294967295 decimal), and the minimum value can not be
   smaller than 0.  The value of a Gauge32 has its maximum value
   whenever the information being modeled is greater than or equal to
   its maximum value, and has its minimum value whenever the information
   being modeled is smaller than or equal to its minimum value.  If the
   information being modeled subsequently decreases below (increases
   above) the maximum (minimum) value, the Gauge32 also decreases
   (increases).  (Note that despite of the use of the term "latched" in
   the original definition of this type, it does not become "stuck" at
   its maximum or minimum value.)"



>
>>> I believe operationally that keeping this information in a single table
>>> for walk purposes would be consistent with operator expectations based
>>> on common CLI output.
>>
>> Yes, I agree and would like to hear from operators on this issue also.
>> I am confused when you talk about MIB walks and CLI output.  Although 
>> many
>> vendors do provide a way to dump MIB data to the CLI and page through it,
>> I wouldn't necessarily consider that common CLI output since most of this
>> (at least in my experience) is dictated by the CLI request (i.e. which
>> columns to show).
>
> What I was attempting to say was that operators tend to view this
> operational data via the output of one CLI command.  The MIB structure
> attempts to group data that is commonly available via the CLI together.
>

I don't want to be restricted by how information is displayed on
a GUI or Terminal Screen.  The MIB structure should not be dictated by
this, and since this MIB is very old, what was appropriate years ago,
may not suit the needs today.   Also, CLI commands can be fairly easily
written to display data as wanted across tables or in the same table.



>
>>>> 5.6 Extensions
>>>> -----------------
>>>> How do you plan to enforce using bgpExtensions for
>>>> other MIB Modules?
>>>
>>> Please see draft-jhaas-idr-bgp4-mibv2-community-00 as an example.
>>>
>>
>> Okay, thanks that gives me more information.  I think you should 
>> formalize
>> this via a Standards Action as specified in RFC2434.  Please see the
>> IANA Considerations sections in the MPLS WG (RFC3811-RFC3815) and
>> CCAMP WG (RFC4801-RFC4803) for some examples.
>
> The following text occurred in draft-ietf-idr-bgp4-mibv2-06:
>>
> "9. IANA Considerations
>
>   This document includes an OID, bgpExtensions, which defines a name
>   space for future BGP extensions.  IANA is requested to create a new
>   registry for new OIDs under bgpExtensions that will define the root
>   OID of future MIB modules for bgp extensions.  The assignment OIDs
>   should be done based upon IDR working group consensus."
>
> What further text would you suggest?
>

Since the BGP4-TC-MIB Module needs a branch to go under, I suggest
renaming bgpExtensions to some more generic name like bgpMIB, bgpStdMIB,
bgp4MIB, or bgp4StdMIB).

Specific text (using bgp4MIB and BGP4-TC-MIB as an example):
NB I have also suggested a specific sub-id,  15, since
bgp under transmission is 15 (and the sub-ids under bgp
are at about 12/13).

9.  IANA Considerations

   IANA is requested to make a MIB OID assignment under the bgp
   branch, that is, assign the bgp4MIB under { bgp 15 }.
   This sub-id is requested because 15 is bgp's value under
   the transmission branch and because the next available
   sub-id under bgp is close to 15.

   In the future, BGP4 related standards track MIB modules should be
   rooted under the bgp4MIB subtree.  The IANA is requested to manage
   that namespace.  New assignments can only be made via a Standards
   Action as specified in [RFC2434].

   This document also requests IANA to assign { bgp4MIB 1 } to the
   BGP4-TC-MIB specified in this document.

-Joan




_______________________________________________
MIB-DOCTORS mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mib-doctors