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

[Iljitsch van Beijnum <iljitsch@muada.com>]

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.