[rbridge] Updated charter
carlsonj at workingcode.com
Fri Jul 16 04:53:34 PDT 2010
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
> 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
> 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
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
Could you fill in some details?
James Carlson 42.703N 71.076W <carlsonj at workingcode.com>
More information about the rbridge