[rbridge] Updated charter

[James Carlson]

Linda Dunbar wrote:
> I have some concern of the bullet (2) (Addition of optional support for ARP
> / Neighbor Discovery optimization) to be added to TRILL re-charter work
> list. 
> 
> ARP is for resolving MAC address from host's IP address. It is not specific
> to TRILL. Straight Ethernet needs ARP.  
> Donald's new draft on ARP optimization
> (http://pothole.com./~dee3/drafts/draft-eastlake-trill-rbridge-arp-xx.txt)
> describes a generic ARP proxy procedure, i.e. changing an ARP broadcast msg
> to a unicast msg if the target IP is cached in its local cache. Otherwise do
> nothing. 

No, it doesn't say to change the broadcast to a unicast.  In 6b on page
9, it says to forward it "as if it was [sic]" unicast.

The distinction is important.  It's not mangling data.  It's merely
choosing not to forward to ports on which the system knows that there
are no interested listeners.

(By "changing," I assume you're not referring to 6a, which essentially
describes the possibility of creating an actual reply to an ARP message
if the correct response information is known locally.)

> ARP proxy function should be allowed on any device. As a matter of fact, ARP
> proxy has been deployed in many places. When ARP proxy is enabled on any
> devices, RBridge should treat the ARP Broadcast or unicast messages same way
> as all other IEEE802.1Q data frames. No special processing should be needed
> by RBridge for ARP messages. If an Rbridge needs to add ARP proxy function
> on some ports, it is exactly same as RBridge having standard IEEE802.1Q
> functions on some ports. But TRILL doesn't need to re-define IEEE802.1Q,
> does it? 

I don't see how anything in that draft is tantamount to redefining
802.1Q.  Or, really, how anything in the document has anything to do
with 802.1Q.

Could you fill in some details?

-- 
James Carlson         42.703N 71.076W         <carlsonj at workingcode.com>