BGP Metrics

My apologies, my question was apparently unclear.

In the common situation where a downstream is allocated a sub-net from
an upstream's super-block, and that downstream wishes to announce that
sub-net to its neighbors, be those neighbors upstream, peer, or
downstream of itself, or of the allocating upstream, the BGP algorithm
does not appear to be equipped to handle the routing decision in an
optimal manner.

Thus far, I've encounter three methods of dealing with this situation.

1. Ignore routing aggregation - Everybody announces the sub-net.
  This works, but runs counter to a long standing goal of the
  community - reducing the size of the routing table.

2. Ignore the route announcement (netmask length)
  may work in some situations, but proves the point.

3. Local announcement only
  May be the result of 2 above, but again - proves the point.

My question is, would the creation of a "multi-homed" flag in the BGP
protocol be worth while discussing?

I see this flag causing the algorithm to drop through the netmask
test, and pick up at the metrics decision.

Before persuing the question with the protocol folks, I thought I'd
try to determine if there is enough interest in the capability to make
it worth while.

>
> Hi all,
> I've occasionally noticed a requirement to disregard mask when
> determining preferred route in the BGP algorithm. Specifically, when
> a multi-homed customer wishes to announce both his delegated networks
> through both connections. The goal is to achieve true multi-homing,
> with out requiring the customer to get independent address space. Thus
> far, I've used various "miserable hacks". Has anyone else perceived a
> similar requirement? if so, has anything being done to get such a flag
> added?
>
> Or am I just missing the obvious?
>

- --
Rusty Zickefoose | The most exciting phrase to hear in science,
rusty@cw.net | the one that heralds new discoveries, is not

:1. Ignore routing aggregation - Everybody announces the sub-net.
: This works, but runs counter to a long standing goal of the
: community - reducing the size of the routing table.

My understanding of this setup is that they do not have portable
space and have been allocated a block from you, and one from
their other provider. If this is the case:

Wouldn't this depend on what they were using multihoming for?

If the customer site were able to send communities to their
other provider that would tag the routes that you had assigned
them as no-export, you wouldn't be crowding the global table.
If you also recieved their other peers route, you would not
export that route into the global table.

You would continue announcing your supernet, as would the
other provider theirs, and there is no pollution in the tables.

:3. Local announcement only
: May be the result of 2 above, but again - proves the point.

Is this what I just described?

:
:My question is, would the creation of a "multi-homed" flag in the BGP
:protocol be worth while discussing?

How is this different than the multi_exit descriptor?
(CCO is down as I write this so I can't look it up.)