Re: [rbridge] Updated charter

James, 

Please see my comments inserted below:

-----Original Message-----
From: James Carlson [mailto:carlsonj@workingcode.com] 
Sent: Friday, July 16, 2010 6:54 AM
To: Linda Dunbar
Cc: 'Erik Nordmark'; 'Developing a hybrid router/bridge.'; 'Peter
Ashwood-Smith'; 'Jari Arkko'; 'Adrian Farrel'; 'David Harrington'; 'Hares
Susan'
Subject: Re: [rbridge] Updated charter

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.

[Linda] It does the exactly same thing! There are the three steps if target
IP is found in its cache:
*	first finds the unicast destination MAC address from its Cache by
the target IP address, 
*	second, uses the regular RBridge function to find the egress RBridge
address based on the unicast MAC address, and then 
*	third, encapsulates the data frame with the egress Rbridge address
as the DA. 

The first step above is commonly called ARP Proxy, i.e. find the unicast MAC
if the target IP is found in its local cache.  The second and third steps
above are regular RBridge functions. 

ARP Proxy and RBridge are two separate functions. Merging them together just
makes the specification unnecessarily more complicated. 
Today, I can buy off-the-shelf RBridge chip set and I can also buy the ARP
proxy stack. They are two separate modules. They can be from two different
vendors. 
Mixing them together just makes it more difficult for equipment and chip
vendors. 

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?

[Linda] I am trying to say that when a switch port supports two distinct
functions, like BGP and IS/IS, you don't need to create one specification to
merge BGP with IS/IS. 

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