Customer AS

>> I would make them renumber with a new class c that was not in your CIDR
>> block.
>> Maybe they could get a class C from the swamp?
>
>Are you suggesting that all dual homed networks should be renumbered
>such that they can't be aggregated and can't be reached from a good
>part of the Internet. I don't think that is a good idea.
>
>Are suggesting punishing a customer for picking up a second provider
>by giving them an unroutable prefix? I hope not.
>

Curtis,

Not sure what you mean here concerning 'unroutable' prefixes, but the
issue with obtaining an allocation for one of the upstream provider's
CIDR block when multihomed *does* have its drawbacks, at least from
the end-user perspective. If said prefix (let's say a /24) is announced
in the 'allocating' provider's aggregate, and the more specific is
announced via the 'other' provider, the more specific will always be
preferred.

A /24 in the so called "provider independent" space will be blocked by
Sprint. That is what I mean be "unroutable".

You announce both the aggregate and the more specific. At some point
in the topology the more specific can be dropped. For example, if
connected to 2 European previders the more specific need not be
announced to North America and the other way around. This level of
aggregation has yet to be acheived, but nuimbering in preparation for
it can't hurt.

Of course, you can play a few tricks (AS_PATH prepend, etc.), but this
situation introduces unique problems.

As-path length never overrides more specific but it isn't needed.

In fact, the <draft-hubbard-registry-guidelines-05.txt> draft indicates
that this is one of the few acceptable instances when allocation can be
done by one of the various registries and not by (one of) the upstream
service provider(s). I think this is a contributing factor to the overall
growth of the global routing table(s), but this is an issue we need to
deal with. From an operational perspective, I'd opt for using a prefix
which was not allocated from either/any upstream provider. From a global
perspective, this contributes to route bloat. :-/

draft-hubbard-registry-guidelines-05.txt is wrong on this one.

If the route comes from one of the providers CIDR blocks, the other
more specific route can be ignored farther away in the topology. If
it is a provider independent address it can't be dropped without
losing connectivity to it.

From a purely pragmatic standpoint, what good is having a dual homed

prefix if Sprint and other major providers drops your prefix and you
can't get to places? Better to number into one of the provider's
aggregates. The more specific will go to everyone willing to take it
and anyone not willing to take the more specific can still get there.

- paul

Curtis

Curtis Villamizar <curtis@ans.net> writes:

A /24 in the so called "provider independent" space will be blocked by
Sprint. That is what I mean be "unroutable".

Um, forgive me for being obtuse, but what's the
so-called "provider independent" space, and where
is the document that outlines its boundaries?

Also, as noted before, the bulk of the long prefixes
blocked by inbound filtering have been obvious mistakes,
such as subnets in the presence of an aggregate, people
forgetting to aggregate at all, and so forth. In each
case the addresses were from what appears to be PA space,
in that the blocks in question were allocated to
providers, rather than end users, and were non-portable.

The addresses may well have been "backbone-independent",
however, as far as I understand things, that is not the
same thing as "provider-independent".

Other than that, I completely agree with you.

  Sean.

Curtis Villamizar <curtis@ans.net> writes:

  >
  >
  > > In fact, the <draft-hubbard-registry-guidelines-05.txt> draft indicates
  > > that this is one of the few acceptable instances when allocation can be
  > > done by one of the various registries and not by (one of) the upstream
  > > service provider(s). ...
  >
  > draft-hubbard-registry-guidelines-05.txt is wrong on this one.

Just for the record: I is one of the few acceptable instances and certainly
does not represent common practise, to the contrary! All regional IRs
recommend using address space from one of the providers.

  > If the route comes from one of the providers CIDR blocks, the other
  > more specific route can be ignored farther away in the topology. If
  > it is a provider independent address it can't be dropped without
  > losing connectivity to it.

Correct.

Daniel