Date: Wed, 30 Apr 2008 12:44:25 -0700 From: "Kevin Oberman" <oberman@es.net> To: Julian Elischer <julian@elischer.org> Cc: FreeBSD Net <freebsd-net@freebsd.org>, Bruce M Simpson <bms@incunabulum.net> Subject: Re: multiple routing tables review patch ready for simple testing. Message-ID: <20080430194425.3225A45010@ptavv.es.net> In-Reply-To: Your message of "Wed, 30 Apr 2008 10:25:51 PDT." <4818AB9F.7000607@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--==_Exmh_1209584665_28987P Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > Date: Wed, 30 Apr 2008 10:25:51 -0700 > From: Julian Elischer <julian@elischer.org> > > Bruce M Simpson wrote: > > Julian Elischer wrote: > >> An interface may however be present in entries from multiple FIBs > >> in which case the INCOMING packets on that interface need to > >> be disambiguated with respect to which FIB they belong to. > > > > Yes, there is no way the forwarding code alone can do this. > > > > It should not be expected to, and it's important to maintain a clean > > functional separation there, otherwise one ends up in the same quagmire > > which has been plaguing a lot of QoS research projects over the years > > (Where do I put this bit of the system?) > > > >> > >> This is a job for an outside entity (from the fibs). > >> In this case a packet classifier such as pf or ipfw is ideal > >> for the job. providing an outside mechanism for implementing > >> whatever policy the admin wants to set up. > > > > Absolutely. This has been the intent from the beginning. > > > > There is no "one size fits all" approach here. We could put a packet > > classifier into the kernel which works just fine for DOCSIS consumer > > distribution networks, but has absolutely no relevance to an ATM > > backbone (these are the two main flavours of access for folk in the UK). > > > >[...] > > >> It > >> IS possible that an interface in the future might have a default > >> plane, but I haven't implemented this. > > > > > This limitation seems fine for now. > [...] > > > > > > For SSM, the key (S,G) > > what's SSM? Source Specific Multicast. It is a scheme for finding the source of a multicast stream without the need for MSDP. It is intended for broadcasting (in the radio/TV sense) streams from a single source. It is not suitable for conferencing as it can't work with multiple sources. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 --==_Exmh_1209584665_28987P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFIGMwZkn3rs5h7N1ERAoFQAJ0bKR34GDW4c7b9rZnoh8mBzxJppwCfcpVa d0dvYqJDKqZ3zuJsBBYwvyc= =jWLj -----END PGP SIGNATURE----- --==_Exmh_1209584665_28987P--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080430194425.3225A45010>