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

[Jeffrey Haas <[e-mail]>]

Joan,

On Tue, May 13, 2008 at 05:42:00PM -0400, Joan Cucchiara wrote:
>>> E: f(BGP4-MIB), (1826,13) Index item "bgpAfPathAttrUnknownCode"
[et alia]
>>> defined with syntax that includes a range

> Based on your response, could the range start at 1?
> In other words, since this index is an opaque handle and since the
> range is large, RFC2578, Section 7.7 requests that an index like
> this should start at 1, since zero should be avoided.
> The specific quote is:
>   "Instances identified by use of integer-valued objects should be
>   numbered starting from one (i.e., not from zero).  The use of zero as
>   a value for an integer-valued index object should be avoided, except
>   in special cases."

I have added OBJECT clauses that restrict these values from
1..4294967295.

>>> 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.

>>> 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.

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.

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.

[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.

> 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.

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 }


>> 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.

>> Updating each deprecated table column's DESCRIPTION with the new columns
>> in the new table, especially where there is an obvious match, seemed
>> excessive.  Was this what you wanted done?
>>
>
> Yes, because there is not a one-to-one correspondence between DEPRECATED 
> Tables
> and New Tables.

I have added text to the DESCRIPTIONs of the deprecated objects pointing
to the replacement objects.

>>> 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?

>>> BgpIdentifierTC
> Should the DISPLAY-HINT be "1d.1d.1d.1d"?

I believe a specification of DISPLAY-HINT "1d." is correct based on the
analogous MacAddress from SNMPv2-TC.

>   Joan
_______________________________________________
Idr mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/idr