[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: email@example.com [mailto:firstname.lastname@example.org] On
> Behalf Of Pekka Savola
> Sent: Tuesday, March 08, 2005 9:47 AM
> To: email@example.com
> Cc: firstname.lastname@example.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