nanog mailing list archives
Re: LSR and packet filters
From: rja () corp home net (Ran Atkinson)
Date: Fri, 12 Sep 1997 09:54:26 -0700
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. Ran rja () home net 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.
Current thread:
- Re: not rewriting next-hop, pointing default, ..., (continued)
- Re: not rewriting next-hop, pointing default, ... Scott Huddle (Sep 11)
- Re: not rewriting next-hop, pointing default, ... Randy Bush (Sep 11)
- Re: not rewriting next-hop, pointing default, ... Avi Freedman (Sep 11)
- Re: not rewriting next-hop, pointing default, ... Naiming Shen (Sep 11)
- Re: not rewriting next-hop, pointing default, ... Randy Bush (Sep 11)
- Message not available
- Re: not rewriting next-hop, pointing default, ... Ran Atkinson (Sep 11)
- Re: not rewriting next-hop, pointing default, ... Randy Bush (Sep 11)
- Re: not rewriting next-hop, pointing default, ... Karl Denninger (Sep 11)
- Re: not rewriting next-hop, pointing default, ... Ran Atkinson (Sep 11)
- Re: not rewriting next-hop, pointing default, ... Sean M. Doran (Sep 11)
- Message not available
- Re: LSR and packet filters Ran Atkinson (Sep 12)
- Re: LSR and packet filters Sean M. Doran (Sep 13)
- Re: LSR and packet filters Alex "Mr. Worf" Yuriev (Sep 13)
- Re: LSR and packet filters Sean M. Doran (Sep 14)
- Re: not rewriting next-hop, pointing default, ... Randy Bush (Sep 11)
- Re: not rewriting next-hop, pointing default, ... Scott Huddle (Sep 11)
- Re: not rewriting next-hop, pointing default, ... Alex.Bligh (Sep 12)
- Re: not rewriting next-hop, pointing default, ... Sean M. Doran (Sep 13)
- Message not available
- Re: protecting operational networks Ran Atkinson (Sep 15)
- Re: protecting operational networks Vadim Antonov (Sep 15)
- Re: not rewriting next-hop, pointing default, ... Karl Denninger (Sep 11)
- Re: not rewriting next-hop, pointing default, ... Avi Freedman (Sep 11)
- set ip next-hop Bradley Dunn (Sep 11)