|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Alpha test of MAE filtering capability
maybe i'm dense when it comes to things operational, you'd have to ask our noc as they probably have an opinion :-), but i can't imagine why our noc would want to troubleshoot someone elses connectivity problem. i would think that whatever the problem being diagnosed, the noc involved would be the noc of the network which is black-holing traffic or being black-holed and would therefore know about any filtering present. i think that it's our duty to keep a good list of mac addr's on our filter if we choose to filter and to inform those networks with whom we have peering arrangements of the existence of that filter. that way, if the one of our peers changes hardware and does not keep the same mac layer address, we can change the filter to include them. i haven't heard a case against filtering yet (third party routing, etc.) that didn't fall into the category of things that filtering is supposed to prevent. if filtering goes into place and you're doing something non-standard at one of the interconnects, either come clean with the parties involved or... Jeff Young [email protected] > Subject: Re: Alpha test of MAE filtering capability > To: [email protected] (Jeff Young) > Date: Tue, 4 Feb 1997 09:13:45 -0500 (EST) > Cc: [email protected], [email protected] > > > 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? > > Hypothetically, if MCI enters into an agreement with MFS to purchase a connection > to a particular port of a GIGAswitch, what reason is there for MFS to share that > port assignment with anyone else? > > See http://www.mfsdatanet.com/MAE/west.map.html with > data like: > > Ames-Giga/2 198.32.136.12 mae-west.SanFrancisco.mci.net > > Certainly this data gives away *some* private information, but having > that knowledge is often very useful when one discovers bizarre > layer two problems. For instance, being able to ascertain that there is no > packet loss from you to all devices on the same switch, and n% packet loss > to all devices on another switch, without having to requests that MFS > diagnose the apparent L3 problem, is very useful. > > > 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? > > You could make that assumption, or perhaps that those two networks > choose not to appear at that locality. You could also determine that > information by sending a loose source-routed packet with a low ttl and > watching where the time exceeded message comes from. > > Are there good operational reasons to make this data publically available? > Do they outweigh the perceived privacy issues? > > It seems to me that there is no change in the "information leak" than > is present in the status quo, and application of interconnect filtering > is likely to cause a particular set of problems, some of which are obvious > now ("A is on B's list and B is not on A's"), and some of which are perhaps > a little more complicated (interactions with broadcast or multicast > traffic, subtle distinctions in the way the GIGAswitch forwards frames to > ports with filtering enabled, etc., etc.) wherein having this information > would be valuable. > > --jhawk - - - - - - - - - - - - - - - - -
|