Re: [rbridge] Updated charter
James Carlson <carlsonj@workingcode.com> Fri, 16 July 2010 15:57 UTC
Return-Path: <rbridge-bounces@postel.org>
X-Original-To: ietfarch-trill-archive-Osh9cae4@core3.amsl.com
Delivered-To: ietfarch-trill-archive-Osh9cae4@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DAAA3A69BE for <ietfarch-trill-archive-Osh9cae4@core3.amsl.com>; Fri, 16 Jul 2010 08:57:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zotsETUJ-HTf for <ietfarch-trill-archive-Osh9cae4@core3.amsl.com>; Fri, 16 Jul 2010 08:57:39 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 571073A697F for <trill-archive-Osh9cae4@lists.ietf.org>; Fri, 16 Jul 2010 08:57:39 -0700 (PDT)
Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id o6GFNvhc017803; Fri, 16 Jul 2010 08:23:58 -0700 (PDT)
Received: from carlson.workingcode.com (carlson.workingcode.com [75.150.68.97]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id o6GFNIQl017626 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Fri, 16 Jul 2010 08:23:28 -0700 (PDT)
Received: from [10.50.23.149] (gate.abinitio.com [65.170.40.132]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.4) with ESMTP id o6GFMpZZ019758 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Jul 2010 11:22:51 -0400 (EDT)
Message-ID: <4C40794B.10304@workingcode.com>
Date: Fri, 16 Jul 2010 11:22:51 -0400
From: James Carlson <carlsonj@workingcode.com>
User-Agent: Thunderbird 2.0.0.22 (X11/20090605)
MIME-Version: 1.0
To: Linda Dunbar <ldunbar@huawei.com>
References: <4BE7A984.8050607@oracle.com> <01a101cb2471$0541bdd0$3a0c7c0a@china.huawei.com> <4C40483E.6020207@workingcode.com> <003201cb24f7$8036d3f0$3a0c7c0a@china.huawei.com>
In-Reply-To: <003201cb24f7$8036d3f0$3a0c7c0a@china.huawei.com>
X-DCC-URT-Metrics: carlson; whitelist
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: carlsonj@workingcode.com
Cc: "'Developing a hybrid router/bridge.'" <rbridge@postel.org>, 'Peter Ashwood-Smith' <Peter.AshwoodSmith@huawei.com>, 'Hares Susan' <shares@huawei.com>, 'Jari Arkko' <jari.arkko@piuha.net>, 'Adrian Farrel' <Adrian.Farrel@huawei.com>, 'David Harrington' <dharrington@huawei.com>
Subject: Re: [rbridge] Updated charter
X-BeenThere: rbridge@postel.org
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:rbridge@postel.org>
List-Help: <mailto:rbridge-request@postel.org?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: rbridge-bounces@postel.org
Errors-To: rbridge-bounces@postel.org
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@workingcode.com> _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge
- [rbridge] Updated charter Erik Nordmark
- [rbridge] Updated charter Pekka Savola
- [rbridge] Updated charter Bill Sommerfeld
- [rbridge] Updated charter Erik Nordmark
- [rbridge] Updated charter Bill Sommerfeld
- [rbridge] Updated charter Bill Sommerfeld
- [rbridge] Updated charter Michael Smith
- [rbridge] Updated charter Michael Smith
- [rbridge] Updated charter Joe Touch
- [rbridge] Updated charter Fred L. Templin
- [rbridge] Updated charter Joe Touch
- [rbridge] Updated charter Joe Touch
- [rbridge] Updated charter Joe Touch
- [rbridge] Updated charter Erik Nordmark
- [rbridge] Updated charter Joe Touch
- [rbridge] updated BOF website Joe Touch
- [rbridge] Updated charter Erik Nordmark
- Re: [rbridge] Updated charter Ralph Droms
- Re: [rbridge] Updated charter Joe Touch
- Re: [rbridge] Updated charter Linda Dunbar
- Re: [rbridge] Updated charter James Carlson
- Re: [rbridge] Updated charter Linda Dunbar
- Re: [rbridge] Updated charter James Carlson
- Re: [rbridge] Updated charter Linda Dunbar
- Re: [rbridge] Updated charter James Carlson
- Re: [rbridge] Updated charter Eric Gray