Arien Vijn wrote: Sorry for the late reply.
No need to apologize.
Layer 2/switch software issues kept my attention all week.
You mean you had to _work_ ? That's terrible.
All right. But what about these VLANs then? Do you mean that VLANs have to be defined on both sites of this router/firewall?
That's the way I would do it.
Why do you think we need VLANs anyway? Why not just configure n addresses in the same VLAN?
For security issues. Having 90 different prefixes on the same VLAN does not sound good to me anyway.
- VLANs must be defined an must not conflict with those of other members. Many members do have switches them selves in-between the IX infrastructure and their border routers.
This is not mandatory. In the study case, RIPE-NCC needs to connect to each AMS-IX participant. Let's say that RIPE-NCC has a router in front of the DNS server, that router connects to AMS-IX fabric via a trunk (Cisco's term would be routing on a stick). That router, on the RIPE side, connects to RIPE's switch fabric. - Vlan 277 on one side of the RIPE router can be vlan 377 on the other side. In that kind of setup, you have strict policy routing between the router subinterfaces anyway, so there can be a conversion matrix. - The connection between AMS-IX' fabric and a participant does not need to be a trunk. If the port is an ordinary one that belongs to only one vlan, there is nothing wrong in having two different VLAN numbers.
- VLANs must be configured correctly in multiple places by multiple parties.
You do use something like VTP domains, don't you?
- Administer all these subnets and then hoping peers will route it correctly.
The peers' issue, not AMS-IX.
Suppose we can deal with this. Then it *might* work for UDP but what about TCP sessions? Failover is a MH requirement too.
Failover is a requirement of _real_ multihoming, which is available next year not today.
Is this worth the manpower? In other words it is too much of a hassle for a solution which, might be working (but not all the time).
Your decision, not mine.
Advertising /48 is unsatisfactory from an aggregation point of view. But it is the only working MH "solution" at the moment.
I actually have less of a problem with the new policy that basically gives an allocation to anyone that wants one. It is a collective hypocrisy that is nothing less than recreating the pre-CIDR swamp. Nevertheless from a design standpoint it is preferable than punching holes in PA.
Our neutrality at least makes us reluctant to use provider space anyway.
Find a reason to allocate 200x /48s to foreign entities and get a /32 by the new policy. The only problem with that is that you would appear as the fireman that puts gas on the fire.
I would very much like to see a working and scalable solution. It would solve one of the main IPv6 issues for neutral, in-depended entities, which just do not fit the customer-ISP-upstream model.
You are encouraged to comment on what we have in the pipe. Michel.