[Idr] Factoring the bgpPeerAfTable in BGP MIBv2

Joan,

Forking this from the main thread for tracking:

On Fri, Jul 04, 2008 at 08:52:24PM -0400, Joan Cucchiara wrote:
> 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).

I think you may be having a small amount of confusion regarding the
objects that constitute the indices of the peer table.

A BGP peer session is defined by a TCP connection between two BGP
speakers.  It is possible for a BGP speaker to have multiple parallel
BGP peering sessions with the same remote BGP speaker so long as the TCP
tuple is different.  See RFC 4271, Section 6.8 for the definition of a
session collision which occurs when two parallel sessions occur with the
same TCP IP address endpoints.

bgpPeerAfInstance serves a somewhat similar purpose as the ENTITY-MIB to
permit multiple BGP sessions.  Since it possible, especially in certain
VPN scenarios, for a given router to permit multiple peering sessions
via differing IP instances, this object was necessary to permit a single
MIB the capability to mange those instances where an end-point might be
the same.

Thus the bgpPeerAfTable's indices are somewhat similar to TcpConnEntry
and should be kept together.  The bgpPeerAfInstance should similarly be
kept with them.

The objects under "Session status" could be factored into an AUGMENTS
table if this will address your concerns.  However, this is the most
factoring I would suggest here.

Overall, I'm not sure what the structural win for this would be.  While
it gains some "purity" of table contents, the similarity to the previous
bgpPeerTable was intentional as an aid to implementors who have to
implement bgpPeerTable.

-- Jeff
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr