LSR and packet filters

Ran Atkinson rja at
Fri Sep 12 16:54:26 UTC 1997

On Sep 11 21:06, Sean M. Doran wrote:

% Cool, and I now view the 2-hop notion as the first
% reasonable argument for encouraging people to totally
% flatten their network into a full mesh.

Hmm.  I wouldn't go that far :-).

% Security policy should not under any circumstances prevent
% the Internet as a whole from functioning reasonably well,
% scaling decently, or make discovering and diagnosing
% problems any harder than it already is.

A reasonable security policy is focused on maintaining
network availability and uptime.  If one focuses exclusively
on diagnostic tools, one's network will be down much more
often than if one strikes a reasonably balanced overall
perspective on things.  All IMHO.

% Your opinion may vary with mine, but I am solidly in line
% with Randy's suggestion that enabling LSRR on backbone
% routers should be a requirement for peering.  (This is not
% surprising as I used to require it of a couple of peers in
% a previous life, because in practice it is unfortunately
% an irreplaceable diagnostic tool).

You haven't defined terms (e.g. "backbone router"), so your
meaning is not clear.  Assuming that "backbone router" is
only those within 2 hops of an external connection and that
one has a network with nice deep heirarchy (much more than
2 levels), I could agree with you. :-)

I will note that its none of someone else's business what
one's internal topology looks like.  The only _legitimate_
need of a peer is to be able to isolate the problem to
one's network (or someone else's network) so that the peer
can then come after one (or one's NOC) to fix the problem(s).

So I'm not trying to kill off LSR as a diagnostic tool, merely
limit the downside operational risks of LSR to a reasonable
level.  The ultimate goal of my proposal is to _enhance_
network availability.

rja at

Disclaimers from yesterday's note all apply; especially the
one about not enough coffee. :-)

PS: I've revised the subject line to be more clear.

More information about the NANOG mailing list