Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!decwrl!oli-stl!asylum!romkey
From: romkey@asylum.SF.CA.US (John Romkey)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Using the 4.2 broadcast addr with 4.3 systems
Message-ID: <3761@asylum.SF.CA.US>
Date: 2 Sep 89 19:49:01 GMT
References: <[A.ISI.EDU].1-Sep-89.05:34:13.CERF> <8909011945.AA00826@cincsac.arc.nasa.gov>
Reply-To: romkey@asylum.UUCP (Super user)
Organization: The Asylum; Belmont, CA
Lines: 14

In article <8909011945.AA00826@cincsac.arc.nasa.gov> medin@NSIPO.NASA.GOV ("Milo S. Medin", NASA ARC NSI Project Office) writes:
>The reason 
>we have so many problems with broadcasts in that in most implementations,
>you end up throwing away info you hear at layer 2, and then trying
>to make up for it by using some incomplete hueristic at layer 3.  This
>is a case where violating layering by passing info from layer 2 to layer
>3 wins big.

I agree. I like being able to keep around control information about
received packets. In my recent designs for IP implementations, I've
always made sure there was a way for layer 2 to mark a packet as
broadcast so layer 3 could then decide what not to do with it. I do
outgoing broadcast the same way (with a different bit). Keeping
around timestamps can also be useful.