NAP filters and multicast

Wed Feb 5 03:56:52 UTC 1997

>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