Re: [rbridge] Updated charter

James Carlson <carlsonj@workingcode.com> Fri, 16 July 2010 12:29 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 8314A3A683C for <ietfarch-trill-archive-Osh9cae4@core3.amsl.com>; Fri, 16 Jul 2010 05:29:04 -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 odN6Ac0p+hxz for <ietfarch-trill-archive-Osh9cae4@core3.amsl.com>; Fri, 16 Jul 2010 05:29:02 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id CDCFF3A69F3 for <trill-archive-Osh9cae4@lists.ietf.org>; Fri, 16 Jul 2010 05:29:02 -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 o6GBscm2002724; Fri, 16 Jul 2010 04:54:39 -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 o6GBs8bc002642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Fri, 16 Jul 2010 04:54:18 -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 o6GBrYuB015904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Jul 2010 07:53:35 -0400 (EDT)
Message-ID: <4C40483E.6020207@workingcode.com>
Date: Fri, 16 Jul 2010 07:53:34 -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>
In-Reply-To: <01a101cb2471$0541bdd0$3a0c7c0a@china.huawei.com>
X-DCC-x.dcc-servers-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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: rbridge-bounces@postel.org
Errors-To: rbridge-bounces@postel.org

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.

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?

-- 
James Carlson         42.703N 71.076W         <carlsonj@workingcode.com>
_______________________________________________
rbridge mailing list
rbridge@postel.org
http://mailman.postel.org/mailman/listinfo/rbridge