AppleTalk MIB question

[[e-mail]]

Jay,

Your interpretation of link level broadcast seems right to me.

You could infer that this is valid error condition from Inside AppleTalk pg. 
4-19, in the pseudocode at the bottom, where it says (for nodes sending packets 
to a net other than the local net):

    call the data link to send the datagram to A-ROUTER

to mean that packets for remote destinations should be datalink unicasts 
towards A-ROUTER, not AppleTalk broadcasts to all devices.  

Using a broadcast data link address to get a packet to a remote net is clearly 
NOT the right thing to do.  A check for this error would have to be implemented 
in the main routing path.  I personally don't think it is worth making the 
check since it is unlikely to occur.

Looking back over old mail, I noticed that Wayne Tackabury wondered whether the 
counter was worth the effort:  

    Date: Fri, 24 Jul 92 20:06:49 -0400
    From: [e-mail]
    Subject: AT MIB+ July '92 Ed. Comments
     ...
    6.  ddpBroadcastErrors: necessary?
        -  I don't see the prevalence of this as a real problem/issue
           that it merits implementing instrumentation to detect it.

But no replies were made to Wayne's comment.  Probably because the object is in 
RFC1243, which was considered kind of a done deal that had to survive as is (at 
least that is how I considered RFC1243 in the past discussions, even though it 
hadn't reached the final standards level).

Clearly, DDP header processing code would have to be aware of the nature of the 
destination datalink address on the received packet, which might not be 
available in some stack implementations with high modularity.

Some general questions regarding backward compatibility with RFC1243:

    If we should decide that an item in 1243 is bogus on closer inspection, 
    what can we do in Appletalk MIB II to correct the situation?  

    Can we at least indicate that the object is present only for backward 
    compatibility?  

    Can we state that an object can be optionally supported, or is it better to 
    just remove it?   

    Or should we just let it go and always just return a value of 0?

Maybe one of the MIB authors (or someone that believes they understand the 
situation) would reiterate their position on this stuff for the current list 
audience.

I don't have a strong opinion on this, but we might as well make it clear in 
case similar situations appear later.

/bob


---------------------- Replied Message Body ----------------------
Date: Wed,  2 Mar 1994 16:12:53 -0800 (PST)
From: Jay Laefer <[e-mail]>
To: [e-mail]
Subject: AppleTalk MIB question
-----------------------------------------------------------------
I'm having trouble understanding what ddpBroadcastErrors is supposed
to count.

According to the text:
    "The total number of input DDP datagrams dropped because
    this entity was not their final destination and they
    were addressed to the link level broadcast."

This text is the same in RFC 1243 and in the mib2-02 draft.  And, if I
remember my OSI layer cake properly, the link level would be Ethernet,
Token Ring, etc.

So, my question is:  Why would I drop a packet because it was
addressed to the link level broadcast?

The text implies that there's a rule that says that link level
broadcasts should not be forwarded by a router.  In particular, this
is very strongly implied by the fact that this counter is in the new
DDP Router Group.

However, I can't find a reference to this rule in my copy of _Inside
Appletalk_, 2nd ed.

Thanks for any help,
    -Jay Laefer
    [e-mail]