If full filtering (i.e. everything disallowed) we in place as the default, and each member had to provide a list of allowed points, and the members of the allowed points had to agree before the filters were installed, the model would be very similar to the ATM based NAPs. So far, the ATM based NAP's seem to work fairly well. *JMO*
This varies a lot depending on who is operating the interconnection point. In practice, it often depends on the dedicated work of one or two individuals. If they do a good job, it will work well. If they leave or change jobs, things can get really, really bad. I think Paul Vixie's reaction has a lot to do with the problems dealing with PacBell's SMDS group getting address screening tables configured correctly. It usually takes two or twenty attempts, and you have to check every month, because they have a nasty habit of changing things behind your back. And even then, you may not get the full story, because often the address screen listed on the paperwork in the Pacbell business often doesn't match the address screen configured in the Pacbell SMDS switch. But PacBell won't send you a copy of the actual switch configuration for your port. I do have a question though. How will this effect the efforts to use the native multicast features to carry MBONE traffic. Are we going to end up with multiple tunnels traversing the exchange points carrying identical MBONE packets. Are we going to end up with odd MBONE black holes because multicast packet routing doesn't like NBMA networks. I haven't looked to closely at multicast on the ATM NAPs. Are they using ATM's native multicast capability, or are they using multiple tunnels? -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation