Subject: MIB V2: PathAttrIndex

From: Pedro Roque Marques <[email-masked]>
Date: Thu, 3 Apr 2003 18:52:55 -0800 (PST)

Jeff,
You define...

    bgpM2PathAttrIndex OBJECT-TYPE
        SYNTAX     Unsigned32
        MAX-ACCESS read-only
        STATUS     current
        DESCRIPTION
            "This value is a unique index for the per-NLRI entry
             in the bgpM2PeerAttrTable.  It is assigned by the
             agent at the point of creation of the bgpM2PeerAttrTable
             row entry.  While its value is guaranteed to be unique
             at any time, it is otherwise opaque to the management
             application with respect to its value or the contiguity
             of bgpM2PeerAttrIndex row instance values across rows
             of the bgpM2PeerAttrTable.  It is used to provide an
             index structure for other tables whose data is logically
             per-peer, per-NLRI."
        ::= { bgpM2NlriEntry 8 }

  I'm assuming that in the context above:
  s/bgpM2PeerAttrTable/bgpM2NlriTable/

If i understand correctly, the intent here is to create an index that
can replace the full "key" on an NLRI.  However managing and assigning
this index is imho a very large overhead.

Perhaps i'm being dense, but it seems to me that the overhead is
non-trivial. Each path on any table needs to have an index, and that
index cannot be reused when the route is deleted... meaning that one
needs to have a mechanism to reverse lookup this index to path
mapping.

I would seem to me that the tradeof is to make
<instance, prefix, lenght, peer-index> key for all the other tables
that use this index. correct ?

I believe i'd rather go for this second option.

  Pedro.

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 4 Apr 2003 11:45:37 -0500

Pedro,

>   s/bgpM2PeerAttrTable/bgpM2NlriTable/

My typo.  Thanks for pointing it out.

> can replace the full "key" on an NLRI.

In the original bgp mib, we have the following:
        bgp4PathAttrEntry OBJECT-TYPE
            SYNTAX     Bgp4PathAttrEntry
            MAX-ACCESS not-accessible
            STATUS     current
            DESCRIPTION
                    "Information about a path to a network."
            INDEX { bgp4PathAttrIpAddrPrefix,
                    bgp4PathAttrIpAddrPrefixLen,
                    bgp4PathAttrPeer            }
            ::= { bgp4PathAttrTable 1 }

The sequence that then follows contains all bgp-4 (rfc 1771) defined
path attributes.

When you do a table walk, this is an amazing amount of repeated
information in some cases, especially if you just want the prefixes.

In the v2MIB, we simply take path attributes out and refer to their
existance in a separate table.

> However managing and assigning

I had hoped not.

> Perhaps i'm being dense,

Or just as likely, the wording isn't clear.

> but it seems to me that the overhead is

The general idea is this.
Please take note of the following tables:
    bgpM2PathAttrTable,
    bgpM2AsPathTable,
    bgpM2PathAttrUnknownTable,
    bgpM2PathAttrOriginatorIdTable,
    bgpM2PathAttrClusterTable,
    bgpM2PathAttrCommTable,
    bgpM2PathAttrExtCommTable,
    bgpM2LinkLocalNextHopTable,

All use the bgpM2PathAttrIndex.

The general thought is that any path attributes set that is received
by a BGP speaker generally must be stored as a complete entity by the
application in some internal form - essentially a path attributes database.
The individual components may be stored in different fashions to
allow for sharing of common sets of items for space-saving purposes, but
you still need to have the original path attribute set available.

Thus, this index is simply a unique value for a given path attribute
set within your implementation.  

I had *hoped* that this method was common enough in various implementations
to make this something that greatly eases implementation of the
table by utilizing a pre-existing internal data structure index.  If
this isn't the case, then these tables need serious re-working.

If the idea happens to match your internal implementation and the above
wording needs tweaking, I would welcome suggestions with open arms.

As for the re-usability, you should be able to re-use it, but you ideally
will need to wait "long enough" to satisfy outstanding queries.  Something
about this timeliness should probably be mentioned in the mib.

> that use this index. correct ?

As the PathAttrIndex is used simply for grouping path attributes
(essentially to point into a grouping of path attributes in your path
attributes database), hopefully this isn't true.  However, as I've stated
above, there is the base assumption that most implementations have some
mechanism to pre-group sets of path attributes together in the database
as they have been received.  If this is true, then indexing may add
some overhead, but hopefully not a horrible amount.

-- 
Jeff Haas 
NextHop Technologies

---

From: Pedro Roque Marques <[email-masked]>
Date: Mon, 7 Apr 2003 16:22:18 -0700 (PDT)

Jeff,

> >     bgpM2PathAttrIndex OBJECT-TYPE

[...]

> Or just as likely, the wording isn't clear.

It isn't clear...

Specially because some of the tables refer to "received" attributes
and "advertised" attributes.

When policy is in use a given route (the tuple <routing-table-id, prefix,
prefixlen, source router-id>) can point to:

 - a received set of attributes.
 - a current set of attributes
 - a set of attributes per advertised peer.

So in order for your idea to work, i believe you need to do have the
following mapping:

 - route 4-tuple -> Loc-Rib attribute set index.
 - route 4-tuple -> Rib-in attribute set index.
 - <routing-table-id, prefix, prefixlen, peer> -> Rib-out attribute
set index.

> set within your implementation.  

OK.

> this isn't the case, then these tables need serious re-working.

While the implementations i know of do keep information internally in
an attribute database it is not always easy to make that index
externally availiable.

i.e. afaik it will be required to create a mapping of external index
-> internal db entry.

> about this timeliness should probably be mentioned in the mib.

One must make sure that this element is not reused immediatly... the
internal index is often reused immediatly

> some overhead, but hopefully not a horrible amount.

The idea is valid... however there is some overhead involved and i
believe you don't have the mappings necessary to support it.

  Pedro.

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 8 Apr 2003 09:45:30 -0400

Pedro,

> It isn't clear...

I'll work with you offline to clean this up a bit.
However, suggestions on-list are always welcome.

>  - <routing-table-id, prefix, prefixlen, peer> -> Rib-out attribute

I believe that particular table can already accomodate these mappings.  
Essentially, this is just a path attributes database.  You can place
entries for the received, used and advertised path attributes in
here.  The wording in the DESCRIPTIONs is clearly incorrect though.

For example, I'm sure you're noting:
    bgpM2PathAttrTable OBJECT-TYPE
        DESCRIPTION
            "Provides per advertised network-prefix attribute data,
             as advertised over a peering session."

> i.e. afaik it will be required to create a mapping of external index

Right.  Some sort of index will need to be maintained to map from
an advertised ID to the internal data structure.  Do we consider this
overhead to be excessive?

> internal index is often reused immediatly

Exactly.

> believe you don't have the mappings necessary to support it.

I think the tables have the appropriate information, however the 
DESCRIPTIONs need work.  If I'm missing something, could you point
out a specific example?

-- 
Jeff Haas 
NextHop Technologies