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