[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: draft-morrow-filter-caps-00 comments



The "whether to or not to Layer 2" strikes me as out of touch with network
realities in the world. ETTx broadband is all over Asia - with Asia being
the one area of the world really sustaining Internet growth. These are
factors that must be considered. Otherwise we'll have a requirements
document that fits a few US providers and no one else. That would not be in
the best interest of the community.


> -----Original Message-----
> From: owner-opsec@psg.com [mailto:owner-opsec@psg.com] On 
> Behalf Of Pekka Savola
> Sent: Tuesday, March 08, 2005 9:47 AM
> To: gmj@pobox.com
> Cc: opsec@ops.ietf.org
> Subject: Re: draft-morrow-filter-caps-00 comments
> 
> 
> On Tue, 8 Mar 2005, George Jones wrote:
> >                                                     * Current 
> > implementations/how [e.g. uRPF]
> 
> Note that if this is the case, we need more text to the required 
> filtering capabilities to more closely reflect the fact what we're 
> actually looking for.
> 
> For example:
>   - [uRPF-like] automatic filtering on customer interfaces
>   - ... which works with multihomed and asymmetric traffic as 
> well, as 
> long as the prefixes are consistent.
> 
> >>   - if this doc should also apply to non-routers (like ethernet 
> >> switches), more filtering capabilities would likely be 
> needed -- like 
> >> MAC address based filters and sane port security (you can put an 
> >> interface to learning mode, then turn it to "lock", and those MAC 
> >> addresses are the only ones allowed -- indefinitely, without 
> >> timeouts.  Just to reduce the typing.)
> >
> > I think, per discussion in other thread we've concluded that layer 2
> > filtering not done in practice in large network cores for several 
> > possible reasons.
> 
> Not in the core, yes -- but I guess enterprise networks was also in 
> scope?  If so, we for example specifically want to use MAC-address 
> based security in our machine rooms (because otherwise the bozos from 
> the IT support staff can go an plug in their windows servers without 
> telling us), and we want to manage what gets plugged to the network 
> and what not.
> 
> >> ==> 32 bit counters are soooo last millenium.  I doubt we'd be 
> >> getting any equipment which doesn't do 64 bit counters.
> >
> > I'm convinced.
> >
> >>  I'd make it a must.
> >
> > In this context, we're listing capabilities, not requirements 
> > (musts...)
> 
> Well, the text says 32-bit as a must and 64-bit as a should.  This 
> seems to conflict with what you're saying.
> 
> But if you want it that way, maybe you could list _two_ capabilities. 
> One for regular toy counters, and ones for real use.  Then 
> folks could 
> poit without any possibility of confusion that "yes, we _do_ want 
> 64bit counters.  Don't talk talk to us if you don't have them".
> 
> Currently, it isn't clear enough.
> 
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>