Any IX willing to share their config?

[Alexander Shikoff]

On Sat, Dec 25, 2010 at 11:57:04AM +0100, Ondrej Zajicek wrote:
> On Sat, Dec 25, 2010 at 05:03:46AM +0200, Alexander Shikoff wrote:
> > > One possible way to do that is not to try handle full 32bit ASNs, but
> > > perhaps just ~ 24bit ASNs and use communities (65000..65255,*) for
> > > "(65000+X,Y) - Do not announce to peer X*65536+Y" and similarly
> > > communities (65256..65511,*) for: "(65256+X,Y) - Announce to peer
> > > X*65536+Y only".
> > You're right.
> > If I remember correctly IANA currently allocates 1024 numbers for each
> > RIR, so your variant covers them entirely for some future years.
> > Some additional thoughts:
> > - this way breaks RFC1997 a little
> > - current draft "Internet Exchange Route Server" (http://tools.ietf.org/html/draft-jasinska-ix-bgp-route-server-01)
> >   does not propose in details how to implement handling of 32bit ASNs
> >   via communities. 
> > - there is RFC5668 (4-Octet AS Specific BGP Extended Community, 
> >   http://tools.ietf.org/search/rfc5668) but it defines only 2 octets
> >   for Local Administrator field. So BGP Ext. community support
> >   will not also allow easy implementation of 32bit ASN handling.
> > 
> > I've googled around this problem and have not find yet another 
> > ideas/discussions etc. So your way seems to be most easy and effective
> > at present moment. 
> 
> Another, even simpler, way is to assign each connected client with
> 32bit ASN some pseudo-ASN from private range. This pseudo-ASN
> would be used with standard communities (0:X, MyASN:X).
MSK-IX uses this way.
 
> > RFC1997 community 'no-export' is also supported. Other communities
> > including RFC1997 well-known ones are not supported and stripped.
> 
> That seems a bit strange to me. Not sure what the other IXPs do but
> i think that communities are supposed to be propagated and RS
> should alter only communities destined for it.
RFC1997 allows modification of community attribute according to a local 
policy. But "Internet Exchange Route Server" draft _recommends_ transparate
propagation. But this recommendation requires consideration of possible 
security or routing issues (asymmetry etc). Just because of security/routing 
issues almost all of our members delete all communities received from IXP or 
those are not listed in IXP routing policy.

If other IXP engineers are reading this maillist it would be great to hear
their opinions.

What's about well-known communities: for example, MSK-IX propagates 
'no-export' transparately to peers. I think this approach does not meet 
RFC1997. MSK-IX does not support 'no-advertise' (0:MyASN is used instead). 
We're using 'no-export' only in an approach described by RFC1997.

> > ------------------- Communities sent to peers ----------------------
> > MyASN:X - Route is received from 16-bit ASN X
> > 6550X:Y - Route is received from 32-bit ASN 65535*X+Y
> > --------------------------------------------------------------------
> 
> What purpose have these communities? That can be easily read from AS_PATH.
If certain peer makes filters based not on AS_PATH but on community 
then these ones can help it.

-- 
MINO-RIPE