[rbridge] Updated charter

[James Carlson]

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         <carlsonj at workingcode.com>