[ppml] "Recommended Practices" procedure

[william(at)elan.net]

On Thu, 27 Apr 2006, Jason Schiller (schiller at uu.net) wrote:

> Marla,
>
> Currently we filter on the /32 boundry except for legacy /35s and critical
> infrastructure.
>
> I don't disagree with you about providers filtering on the /48 boundry for
> PI either.
>
> But I don't see how anyone can defend allowing PI multihomers 1 slot
> (/48) in the routing table, but not allowing PA multi-homers one slot
> (/48) in the routing table.

You can't defend that. You have to allow anybody who can multihome (i.e. have
ASN) a slot in the routing table - after all why else do they have an ASN?

[Note: I'm being slightly cynical, of course I know that ASNs are used for
        certain other routing setups too, but those are small in number]

Of course the question for IETF now is not about that but they want to 
redefine what it means to multihome in the first place.

> Either de-aggregation is an acceptible solution to multi-homing, or it
> isn't.  Whether the end-site uses a PI address or a PA address should make
> no difference.

My view is that right design would make 0 difference what local addresses are
used by the site/network at all and not expose that to the world. But we seem 
to have missed that train .. or maybe not?

> Secondly, when customers start to whine about wanting to slice up their
> announcement to the global routing table the boundry may slip a bit.

They have an announcement and its not in global routing table?
No wonder they "whine"! :)

-- 
William Leibzon
Elan Networks
william at elan.net