Re: [lir-wg] AS Number Policy

Lets see the following example:
+-----------+ +-------+ | AS-UPLINK | | AS-IX | +---------o-+ +o------+ | | +o-----------o+ | AS-CUSTOMER | +-------------+
[ ... ]
Should AS-CUSTOMER be considered as multihomed?
Definitely, as they'd probably have more then one eBPG session, and probably a different routing policy. I don't see any reason to treat "customer" status (i.e. packets shipped for money) different from "peering" status (i.e. packets shipped for "free").
-- Regards, Vladimir.
Wilfried.

On Tue, Jul 09, 2002 at 06:11:04PM +0200, Wilfried Woeber, UniVie/ACOnet wrote:
Lets see the following example:
+-----------+ +-------+ | AS-UPLINK | | AS-IX | +---------o-+ +o------+ | | +o-----------o+ | AS-CUSTOMER | +-------------+
[ ... ]
Should AS-CUSTOMER be considered as multihomed?
Definitely, as they'd probably have more then one eBPG session, and probably a different routing policy.
Ok, so the word 'multihomed' can be replaced or described as "in the case of two or more eBGP sessions with public ASes", right?
I don't see any reason to treat "customer" status (i.e. packets shipped for money) different from "peering" status (i.e. packets shipped for "free").
In other words, if customer B would like to resell service from uplink A to two other customers (C and D) it should be allowed to get AS number for that: +------+ | AS-A | +---o--+ | +---o--+ | AS-B | +-o--o-+ | | +-----+ +-----+ | | +---o--+ +--o---+ | AS-C | | AS-D | +------+ +------+ right (lets omit details how AS-C and AS-D achieve they multihoming)? -- Regards, Vladimir.

On Tue, 9 Jul 2002, Wilfried Woeber, UniVie/ACOnet wrote:
Lets see the following example:
+-----------+ +-------+ | AS-UPLINK | | AS-IX | +---------o-+ +o------+ | | +o-----------o+ | AS-CUSTOMER | +-------------+
[ ... ]
Should AS-CUSTOMER be considered as multihomed?
Definitely, as they'd probably have more then one eBPG session, and probably a different routing policy.
I don't see any reason to treat "customer" status (i.e. packets shipped for money) different from "peering" status (i.e. packets shipped for "free").
In this case, RIPE would have to have presence at every IX to not to get false positives. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords

On Wed, Jul 10, 2002 at 10:03:38AM +0300, Pekka Savola wrote:
On Tue, 9 Jul 2002, Wilfried Woeber, UniVie/ACOnet wrote:
Lets see the following example:
+-----------+ +-------+ | AS-UPLINK | | AS-IX | +---------o-+ +o------+ | | +o-----------o+ | AS-CUSTOMER | +-------------+
[ ... ]
Should AS-CUSTOMER be considered as multihomed?
Definitely, as they'd probably have more then one eBPG session, and probably a different routing policy.
I don't see any reason to treat "customer" status (i.e. packets shipped for money) different from "peering" status (i.e. packets shipped for "free").
In this case, RIPE would have to have presence at every IX to not to get false positives.
Or in other words RIPE should modify existing policy in such way, that you may request an AS-number for IX only if you will put RIS box in this IX, right? Moreover, all existing IX-es not covered by RIS should also use RIS boxes, right? :-) -- Regards, Vladimir.
participants (3)
-
Pekka Savola
-
Vladimir A. Jakovenko
-
Wilfried Woeber, UniVie/ACOnet