Re: [trill] [rbridge] Query on draft-ietf-trill-esadi-00
hu.fangwei@zte.com.cn Mon, 16 July 2012 02:01 UTC
Return-Path: <hu.fangwei@zte.com.cn>
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59CD521F8548; Sun, 15 Jul 2012 19:01:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -95.035
X-Spam-Level:
X-Spam-Status: No, score=-95.035 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M7QsimBNpD5D; Sun, 15 Jul 2012 19:01:07 -0700 (PDT)
Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 0689921F8552; Sun, 15 Jul 2012 19:01:05 -0700 (PDT)
Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 514961455586978; Mon, 16 Jul 2012 09:58:29 +0800 (CST)
Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 16919.1898756327; Mon, 16 Jul 2012 10:01:47 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q6G21VHJ097515; Mon, 16 Jul 2012 10:01:31 +0800 (GMT-8) (envelope-from hu.fangwei@zte.com.cn)
In-Reply-To: <CAKn+7dLb1LGy8B+cnFQyHCsnsci4WWqxF2XuwUmZ02L83hWfmQ@mail.gmail.com>
To: Abhinav Bhatia <nitks.abhinav@gmail.com>
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0.4 June 01, 2004
Message-ID: <OF13C7775D.8943CD62-ON48257A3D.00069C41-48257A3D.000B206F@zte.com.cn>
From: hu.fangwei@zte.com.cn
Date: Mon, 16 Jul 2012 10:01:31 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-07-16 10:01:32, Serialize complete at 2012-07-16 10:01:32
Content-Type: multipart/alternative; boundary="=_alternative 000B206848257A3D_="
X-MAIL: mse02.zte.com.cn q6G21VHJ097515
Cc: trill-bounces@ietf.org, trill@ietf.org
Subject: Re: [trill] [rbridge] Query on draft-ietf-trill-esadi-00
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Developing a hybrid router/bridge." <trill.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trill>, <mailto:trill-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/trill>
List-Post: <mailto:trill@ietf.org>
List-Help: <mailto:trill-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trill>, <mailto:trill-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Jul 2012 02:01:08 -0000
Hi,Bhatia, Thanks for your comments. Please see my comments in-line >Hi Authors, >I have query regarding “The ESADI (End Station Address Distribution Information) Protocol” as per “draft-ietf-trill-esadi-00” >According to draft in Section 5.2 Forgetting End Station Addresses If RBridge RBn participating in the TRILL ESADI protocol for VLAN-x is no longer appointed forwarder for VLAN-x on any port where it is providing end station service, it ceases to participate in ESADI after sending a final ESADI-LSP nulling out its ESADI-LSP information. >Above will remove/flush the learned L2 entries for that ESADI Rbridge for that vlan and also remove the neighbor ESADI instance entry. Q) What does “nulling out” its ESADI-LSP information mean? Does it means removing the macs and sending an empty MAC Reachability TLV or does it mean that the ESADI LSP wont contain any MAC Reachability TLV at all? [hfw] If RBn participant in the TRILL ESADI protcol, it can use the ESADI protocol to fast update the MAC table of remote RBridges. If some of the end stations attached to RBn remove, RBn use the ESADI-LSP to announce its leaving, the ESADI-LSP doesn't contain the MAC address of the leaving end station. It only removes the macs, and the Topology-id/Nickname,Confidence, and VLAN-ID field will be filled in. The ESADI LSP should contain MAC reachability TLV. Q) In case if ESADI rbridge is AF for a vlan-x and the only End Station which was connected earlier, is removed now, then what will be sent in ESADI-LSP to flush L2 entries for that vlan-x, will it be without MAC Reachability TLV? Please bear in mind that the RBridge has not lost AF for that particular vlan, but has no End Station to send in MAC Reachability TLV. [hfw] Yes, the ESADI-LSP will contain MAC reachability TLV, but the MAC field is empty. Whether there is end station attached to the ESADI RBridge or nor, can not change the status and role of AF for the RBridge in the link, in my mind. So RBrdige should sends its ESADI-LSP contain MAC reachability to its neighbor, even if there is no MAC address in the MAC field. Please let me know for an ESADI RBridge how to distinguish between 1> when to remove learned L2 entries and 2> when to remove ESADI instance neighbor on receiving ESADI-LSP? [hfw] If RBridge receives a new ESADI-LSP from its logical neighbor that it can not contain some of the MAC(L2 entries), it should remove the l2 entries. If RB receives ESADI-LSP from its neighbor, it can not changes or removes the status of its neighbor whether the ESADI-LSP contain MAC address or not, while if its neighbor becomes IS-IS or data unreachable, or the ESADI Participation bit of the neighbor is reset, the ESADI instance will be removed from its local neighbor status list. Thanks Abhinav Bhatia <nitks.abhinav@gmail.com> 发件人: trill-bounces@ietf.org 2012-07-13 17:51 收件人 trill@ietf.org 抄送 主题 [trill] [rbridge] Query on draft-ietf-trill-esadi-00 Hi Authors, I have query regarding “The ESADI (End Station Address Distribution Information) Protocol” as per “draft-ietf-trill-esadi-00” According to draft in Section 5.2 Forgetting End Station Addresses If RBridge RBn participating in the TRILL ESADI protocol for VLAN-x is no longer appointed forwarder for VLAN-x on any port where it is providing end station service, it ceases to participate in ESADI after sending a final ESADI-LSP nulling out its ESADI-LSP information. Above will remove/flush the learned L2 entries for that ESADI Rbridge for that vlan and also remove the neighbor ESADI instance entry. Q) What does “nulling out” its ESADI-LSP information mean? Does it means removing the macs and sending an empty MAC Reachability TLV or does it mean that the ESADI LSP wont contain any MAC Reachability TLV at all? Q) In case if ESADI rbridge is AF for a vlan-x and the only End Station which was connected earlier, is removed now, then what will be sent in ESADI-LSP to flush L2 entries for that vlan-x, will it be without MAC Reachability TLV? Please bear in mind that the RBridge has not lost AF for that particular vlan, but has no End Station to send in MAC Reachability TLV. Please let me know for an ESADI RBridge how to distinguish between 1> when to remove learned L2 entries and 2> when to remove ESADI instance neighbor on receiving ESADI-LSP? Thanks, Abhinav_______________________________________________ trill mailing list trill@ietf.org https://www.ietf.org/mailman/listinfo/trill
- [trill] [rbridge] Query on draft-ietf-trill-esadi… somnath chatterjee
- [trill] [rbridge] Query on draft-ietf-trill-esadi… Abhinav Bhatia
- Re: [trill] [rbridge] Query on draft-ietf-trill-e… hu.fangwei
- Re: [trill] [rbridge] Query on draft-ietf-trill-e… hu.fangwei
- Re: [trill] [rbridge] Query on draft-ietf-trill-e… zhai.hongjun
- Re: [trill] [rbridge] Query on draft-ietf-trill-e… Donald Eastlake
- Re: [trill] [rbridge] Query on draft-ietf-trill-e… Donald Eastlake