[7401] in North American Network Operators' Group
Re: Alpha test of MAE filtering capability
daemon@ATHENA.MIT.EDU (Erik Sherk)
Tue Feb 4 11:19:44 1997
To: "Jeff Young" <young@mci.net>
cc: Robert Wilson <RWilson@genuity.net>,
"'feldman@mfst.com'" <feldman@mfst.com>,
"'Andrew Partan'" <asp@partan.com>,
"'nanog@merit.edu'" <nanog@merit.edu>, sherk@UU.NET
In-reply-to: Your message of "Tue, 04 Feb 1997 08:27:16 EST."
<199702041327.IAA06958@postoffice.Reston.mci.net>
Date: Tue, 04 Feb 1997 11:11:26 -0500
From: Erik Sherk <sherk@UU.NET>
> i, for one didn't understand the request.
>
> hypothetically, if mci enters into
> an agreement with MAE E/W to allow a list of mac header addresses
> to have access to our port on a gigaswitch, what reason is there
> for MAE E/W to share that list with anyone else? if there is no
> peering arrangement between two networks you could assume that the
> the mac header of one network's interface isn't on the list, right?
>
> Jeff Young
> young@mci.net
Jeff,
Initially, I thought that you were right, but on second thought
I see a problem. If a peer of yours is giving someone third party routes,
this filtering will blackhole traffic. While your peer should not be
giving these routes with your router as the next hop, it will happen
and we need a way to debug it.
Erik
> >
> > I din't see an answer on this one....
> >
> > >----------
> > >From: Andrew Partan[SMTP:asp@partan.com]
> > >Sent: Saturday, February 01, 1997 10:55 PM
> > >To: feldman@mfst.com
> > >Cc: nanog@merit.edu
> > >Subject: Re: Alpha test of MAE filtering capability
> > >
> > >> In response to requests from several customers for a filtering solution
> > >> at MAE EAST and MAE WEST, MFS WorldCom is developing an automated
> > >> system to enable ISPs to control traffic destined for their own routers
> > >> and networks.
> > >
> > >Are you going to post the list of permitted/denied addresses?
> > >
> > >Operationally it would be *very* useful to know what addresses are
> > >blocked.
> > > --asp@partan.com (Andrew Partan)
> > >
>
