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

["Gunter Van de Velde \(gvandeve\)" <gvandeve@cisco.com>]

1)
<start snip>
 > 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?
<end snip>

Because changing defaults create inconsistency on networks and confuses
people. 

2)

<start snip>
but since communities don't do any harm,
<end snip>

I suppose that if one person adds <mhome> community to all prefixes that
it will do harm?

3)
<start snip>
> 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.
<end snip>

In any way. Providing information on source of prefix is what is the
intend of this origin attribut not? Maybe a x-check with the rfc1771
guys would be good to understand the possibilities and incompatibilities
here.

G/

-----Original Message-----
From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] 
Sent: Wednesday, November 08, 2006 11:30 AM
To: Gunter Van de Velde (gvandeve)
Cc: v6ops@ops.ietf.org
Subject: 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.