Apologies for reposting this -- it apparently hit the archives, but
nobody else --including the WG chair -- seems to have it.
Larry Blunk wrote:
My initial assumption was implementation would move to the
BGP4MP_ENTRY subtype for table dumps as it does not encode the peer
AS (and any 32 bit AS numbers would be in the attribute information
which is transparent in MRT). However, given that peer AS
info is likely quite useful, I'll go ahead and add these subtypes
to the TABLE_DUMP type.
Hi Larry,
apologies for jumping in so late, I was on a long trip.
The approach Henk suggests has the disadvantage that the Subtype field
values no longer map one-to-one to the BGP multiprotocol AFI field, so
other AFIs can't directly represented.
If this is an issue, we could define a new type, TABLE_DUMP_32BIT_AS.
However, this might be overkill. There's also the fact that even if the
AFI values correspond to BGP AFI values, the TABLE_DUMP format has no
place to store the BGP SAFI anyway.
I am thinking of implementing Henk's suggestion, but I just wanted to
make sure that this is not an issue.
Another thing: if we do go with Henk's approach, perhaps we could call
the values 1 and 2 something different from AFI_IPV4 and AFI_IPV6 simply
to avoid confusion with the BGP values?
Cheers,
Lorenzo
--
Lorenzo Colitti [EMAIL PROTECTED]
Network Engineer +31-20-5354471
RIPE NCC www.ripe.net
_________________________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/grow.html
web archive: http://darkwing.uoregon.edu/~llynch/grow/
