Subject: questions about the index of the bgpM2PeerTable

From: "Bruno Rijsman" <[email-masked]>
Date: Thu, 20 Mar 2003 10:34:07 -0500

I have some questions about the index of the bgpM2PeerTable in
draft-ietf-idr-bgp4-mibv2-03.txt:

>bgpM2PeerEntry OBJECT-TYPE
>     ...
>     INDEX {
>         bgpM2PeerLocalAddrType,
>         bgpM2PeerLocalAddr,
>         bgpM2PeerRemoteAddrType,
>         bgpM2PeerRemoteAddr
>     }

The local address of a BGP session may not be known until the
session comes up (and as a side-effect, if the session bounces
it may end up with a different local address the second the the
session comes up). This might happen, for example, if the session
is an IBGP session or a multihop EBGP session without a configured
update-source address.

Also, as far as I know, existing implementations do not allow you
to configure two BGP sessions to the same remote address with
different local addresses.

Given that, would it make sense to remove the local address
from the index?

In RFC 2547 style VPNs, there may be several peers with the
same remote (and local) address because each VRF has its own address
space. Should we say that this table does not contain entries for
PE-CE sessions? Or, alternatively, should we add some identification
of the VRF in the index?

>bgpM2PeerIndex OBJECT-TYPE
>...
>Values in the
>bgpM2PeerTable and other tables utilizing bgpM2PeerIndex
>are expected to remain in existence for an arbitrary
>time after the unconfigured peer has been deleted
>in order to allow management applications to extract
>useful management information for those peers.

Does this mean that if we create 1,000 peers and then remove
those 1,000 peers, the bgpM2PeerTable has to continue to contain
rows for those 1,000 removed peers for ever? Even across reloads?
That seems a very harsh requirement on the BGP implementation to
keep all this information around about peers that used to exist
in some distant past... Would it be possible to remove that
requirement?

_________________________________________________________________
Help STOP SPAM with the new MSN 8 and get 2 months FREE*  
http://join.msn.com/?page=features/junkmail

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 20 Mar 2003 18:33:54 -0500

Bruno,

> >bgpM2PeerEntry OBJECT-TYPE
[out of order]
> different local addresses.

Where the lack of existing implementations that do this is true,
I don't believe the specification precludes this.  Please note the
connection collsion text in 6.8, first paragraph.  This paragraph
doesn't explicitly declare this as a feature, but the comparison
implies that it could happen.

A potentially valid example is maintaining two peering sessions
across different interfaces to the same host.

[...]

> is an IBGP session or a multihop EBGP session without a configured

This is a good example of where this might be an issue.  Do you have
any suggested workarounds?

My own thought is that in the case where the source address is not
known ahead of time that a value of 0.0.0.0 (or all zeros for a given
addrtype) would mean that its an unspecified address on configuration.
It may be ok to leave this in the established state as well to
make the tables queryable.  The implementations I have worked with
tend to require you to specify the local end of the connection
via configuration in some cases and when this is done, the value can
be placed here.

> PE-CE sessions? Or, alternatively, should we add some identification

This is a valid concern and worthy of some thought.

Consider bgpM2NlriIndex which does something similar for the 
path attributes table.

> rows for those 1,000 removed peers for ever?

This is up to the implementation.

> Even across reloads?

This is also up to the implmentation. :-)

> in some distant past... Would it be possible to remove that

Since the bgpM2PeerIndex is referred to by other tables, the idea
is that you want to be able to get data that may otherwise
disapear out from under it.  Requiring it forever is unreasonable.

-- 
Jeff Haas 
NextHop Technologies