Re: [rbridge] Updated charter

[Linda Dunbar <[e-mail]>]

James, 

Section 3 of the draft (ARP Optimization Details) listed 5 steps. The first
step is "observing native ARP request and reply frame" to learn the frame's
IP, VLAN. 

This snooping at line rate is not trivial, requiring the switch port to
filtering all the ARP messages at line rate and store the learned IP
addresses and VLANs. But most ARP requests/replies may not traverse through
TRILL ports on a switch, which really defeats the purpose of this extra
work. 

Let's assume that a switch has 12 ports, with 2 ports facing TRILL
interface, 10 ports facing servers via standard Ethernet interface. 

Target hosts of ARP requests from servers can be one of the servers connect
to the switch. When servers are virtualized, target hosts can even be on the
same physical server, you could even have ARP messages being hairpinned back
(IEEE802.1Qbc & 802.1Qbg). 

If you want to add a function to snoop all the ARP requests and replies (ARP
Proxy) to cache target IP-MAC/VLAN to reduce broadcast messages, it is much
more effective to add this function on the ports facing servers, or in a
centralized CPU, so that the switch's local cache (IP<->MAC/VLAN) can have
all the IP <->MAC/VLAN mapping for all hosts traversing through this switch.
When a target IP is found in the switch's local cache, the unicast MAC/VLAN
is used as DA, so that this frame will only exit one port of the switch,
instead of broadcasting to all ports. If the frame is to exit the TRILL
port, the RBridge function on the port will encapsulate the frame with
appropriate egress RBridge address. Most likely the frame will exit ports
facing other servers connected to the switch. 

Therefore, mixing ARP proxy function with TRILL just creates a more
complicated specification, which doesn't help anyone (system vendors,
component vendors or software stack vendors). Most importantly, ARP proxy
and RBridge are two distinct functions.  This is especially bad when APR
proxy has been deployed in many places. 

For a switch with TRILL ports, ports facing to (virtual) servers, and ports
facing other switches via Ethernet interfaces, mixing ARP proxy with TRILL
makes even less sense. Most traffic will be switched between
Ethernet<->Ethernet and Ethernet <-> TRILL. 
 
If it is still not clear, we can discuss more in Maastricht. 

Linda Dunbar
  



-----Original Message-----
From: James Carlson [mailto:[e-mail]] 
Sent: Friday, July 16, 2010 10:23 AM
To: Linda Dunbar
Cc: 'Erik Nordmark'; 'Developing a hybrid router/bridge.'; 
Subject: Re: [rbridge] Updated charter

Linda Dunbar wrote:
> 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.

It would help me (at least) to have references to the specific parts of
the document that you're commenting on.  It's unclear to me exactly what
step concerns you, or why it matters whether a given step is commonly
called something else.  (For what it's worth, I'd dispute that usage.
"Proxy ARP" has a distinct meaning in the places where RFC 826 is
commonly used, and it doesn't seem to match exactly what you're describing.)

In any event, there's no section here that talks about changing the
original frame's destination to unicast.  The tunneling mechanism does
indeed carry frames inside the TRILL cloud using unicast between peer
RBridges, but I don't see how that's relevant.

> ARP Proxy and RBridge are two separate functions. Merging them together
> just makes the specification unnecessarily more complicated.

This is a separate draft from TRILL.  It's an optimization that some
vendors may choose to employ and that others might not.

I agree that if it were in the base protocol document, then that'd be a
problem.

But as a separate document, how does it make things 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.

I'm not sure what you're referring to here.  Can you provide clear
pointers?  If the "ARP proxy stack" (whatever that may be) is a separate
module, doesn't that mean that it has to mangle the sender's frames?

The mechanism here is a way to glean IP/MAC pairings such that when you
see a broadcasted request, you know where the "true" destination lies,
and don't need to bother with an actual network-wide broadcast.

This "true" destination relies on knowing exactly what's in the RBridge
forwarding database.  That's something that a distinct "module" can't
possibly know, because it's an internal detail.

(And, for what it's worth, "modules" are completely out of scope in most
IETF discussions.  The documents describe [or are _supposed_ to
describe] the on-the-wire behavior, not the internal system architecture
that may or may not lead to that behavior.)

> Mixing them together just makes it more difficult for equipment and chip
> vendors.

How?

I don't follow.  If you don't like what the draft describes, then nobody
is saying that you need to implement it.  Ignore the draft, and you're done.

It doesn't really matter whether any or all or no RBridges implement
this specification.  They should still interoperate using the base document.

If you see an interoperability issue, though, then that would be good to
document, because that'd be an important problem.

> 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.

Can you point to a specific document that should be referenced as "Proxy
ARP" rather than implementing what's described in this draft?

-- 
James Carlson         42.703N 71.076W         <[e-mail]>

_______________________________________________
rbridge mailing list
[e-mail]
http://mailman.postel.org/mailman/listinfo/rbridge