27 Dec
2010
27 Dec
'10
3:23 p.m.
Alexander Shikoff wrote, 25.12.2010 15:50: > 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. Developers of this draft invite to comment this document (at Euro-IX community mailing list this summer). You may send some suggestions. >>> - 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. We not expect very large number of direct connected members with ASN > 65535 in few next years. Most new members still have ASN16 numbers. Some have ASN32 and then migrated to ASN16 (due various difficulties: ddos protection, direct peerings etc.) So we can wait for new RFC with Extended Communities or for some other solution. > >>> 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. Our customers wanted to be able to announce some routes with 'no-export' transparently to other MSK-IX participants. That was before the BIRD became our main platform and before we implemented full-featured communities to our customers. At present, you can to propagate 'no-export' with the special community: http://www.msk-ix.ru/eng/routeserver.html#bgpcommunity Btw, as I remember, among other UNIX BGP daemons also there are some transparency with 'no-export'. Any transparent Route Server at every IXP by its nature doesn't meet RFC4271 (transparent RS doesn't update as-path attribute). All current inconsistency, including RFC1997 breaks, better to consider in the RFC about Route Servers. > >>> ------------------- 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. >