[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Idr] Early MIB Dr. Review of draft-ietf-idr-bgp4-mibv2-06.txt
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" <jhaas at pfrc.org>
To: "Joan Cucchiara" <jcucchiara at mindspring.com>
Cc: "Jeffrey Haas" <jhaas at pfrc.org>; "Dan Romascanu (E-mail)"
<dromasca at avaya.com>; "David
Ward" <dward at cisco.com>; <idr at ietf.org>; "MIB Doctors (E-mail)"
<mib-doctors at ietf.org>
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 <jhaas at pfrc.org>
[...]
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
_______________________________________________
Idr mailing list
Idr at ietf.org
https://www.ietf.org/mailman/listinfo/idr