Subject: grow: Re: On draft-ietf-grow-mrt-03.txt

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 11 Oct 2006 12:52:58 +0200

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-masked]
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/

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 11 Oct 2006 13:47:45 +0200

Henk Uijterwaal (RIPE NCC) wrote:
> Paragraph 4.7 currently does not take 32 bit ASN into account.  However,
> as of 1/1/2007, these will start to show up in the routing table.  To make
> this work, I suggest to add 2 new subtypes to the TABLE_DUMP type:
> [...]

A couple more points:

1. I think we also need to provide a format to log BGP state changes
    with 32-bit AS numbers. Since the AFI field in the state change
    message comes after the AS field, we need a new subtype.

2. The BGP4MP_ENTRY subtype has a similar problem. Here, both the AFI
    and SAFI fields are present so it seems that the intention is to
    store the BGP AFI and SAFI values in the header. If that's the case,
    the AFI field cannot be overloaded to indicate whether the entry uses
    32-bit AS numbers or not, so we need a new subtype here as well.

So we could do the following:

        0    BGP4MP_STATE_CHANGE
        1    BGP4MP_MESSAGE
        2    BGP4MP_ENTRY
        3    BGP4MP_SNAPSHOT
        4    BGP4MP_STATE_CHANGE_32BIT_AS
        5    BGP4MP_ENTRY_32BIT_AS
        6    BGP4MP_MESSAGE_32BIT_AS

Or we could just define a new type, BGP4MP_32BIT_AS, which would have 
the same subtypes as BGP4MP. This would probably be simpler and more 
elegant to implement, but requires more extensive changes to the draft 
(I can help with those though).

Cheers,
Lorenzo

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 20 Oct 2006 12:47:19 +0200

Apologies for reposting this -- it apparently hit the archives, but 
nobody else --including the WG chair -- seems to have it.

Hi Larry,

Cheers,
Lorenzo

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 20 Oct 2006 12:55:40 +0200

[Resending this post to the list as well]

A couple more points:

        0    BGP4MP_STATE_CHANGE
        1    BGP4MP_MESSAGE
        2    BGP4MP_ENTRY
        3    BGP4MP_SNAPSHOT

Cheers,
Lorenzo