[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Comments on <draft-van-beijnum-v6ops-pa-mhome-community-01.txt>

On 7-nov-2006, at 2:32, Gunter Van de Velde ((gvandeve)) wrote:
Its a pitty that this document didn't got airtime anymore today at the v6ops meeting. 

This is a tough business.  :-)
I had a quick hack read trough this document and have some thoughts to ventilate:
1) The suggestion to use community in the way proposed is quite controversial in the way communities are currently used on the internet. They are typically not sent from ISP to ISP to ISP etc... In most cases community simply stays within AS itself (there are some exeptions, but that is typically just between peers)
Controversial isn't the word I'd use. It's true that some vendors choose not to propagate communities by default (neither inter- or intra-AS) and obviously some ASes make good use of them internally, but it's certainly not uncommon to see communities on routes received from other ASes. Just log in to route-views.oregon-ix.net and look up a random prefix. Also, note that the Cisco default behavior is to not _send_ communities, but if the neighbor sends them, they are accepted. Also, arguably, the existing well-known communities are inteded for inter-AS use.
2) I do not like that statement that default behaviour should change in order to sent this 'multihoming' community by default even if the community exchange is not explicitly enabled. 

Why not?
This changes basic default BGP routing behaviour and implicitly assumes that everybody wants to do this?
The person sending the communities doesn't know whether the person at the other end wants them, but since communities don't do any harm, why not send them and let people who don't want them filter them out?
This is a larger issue, though: I can invent new BGP path attributes and send them to my neighbors. I can even flag them to be transitive, so my neighbors will propagate them by default. As far as I know, no BGP implementations allow the user to filter out unknown/unwanted path attributes.
3) If the goal is to have information with the BGP NLRI about its origin, would it not be better in that case to create a new value for the origin attribute in addition to the IGP, EGP and unknown values? (This would at least give back some degree of usage of this attribute)
But can existing BGP implementations filter on the origin attribute? Unfortunately although such an approach makes sense I don't think it's deployable because in RFC 1771 only three values for the origin are specified, with no provisions for additional values. This makes it likley that some BGP implementations will react badly when a new value shows up.
However, there is another issue I'm slightly worried about with this proposal. If you look at my slides about this draft at the RIPE meeting last month: 

http://www.bgpexpert.com/presentations/multihoming_paspace.pdf
and then look at the actual filter needed to implement this, it's pretty scary. It would be good if vendors could make this simpler, but I'm not sure that's doable.