Re: [trill] ESADI draft change suggestion Wed, 25 July 2012 06:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C4C9321F855B; Tue, 24 Jul 2012 23:55:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -96.239
X-Spam-Status: No, score=-96.239 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100, WEIRD_QUOTING=1.396]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Qg7RCcQPm92n; Tue, 24 Jul 2012 23:55:32 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 25CFC21F8552; Tue, 24 Jul 2012 23:55:30 -0700 (PDT)
Received: from [] by with surfront esmtp id 107231455586978; Wed, 25 Jul 2012 14:45:49 +0800 (CST)
Received: from [] by [] with StormMail ESMTP id 46806.1643529935; Wed, 25 Jul 2012 14:55:17 +0800 (CST)
Received: from ([]) by with ESMTP id q6P6tKLC002782; Wed, 25 Jul 2012 14:55:20 +0800 (GMT-8) (envelope-from
In-Reply-To: <>
To: Sujay Gupta <>
MIME-Version: 1.0
X-KeepSent: C6602D69:6F6D8C4D-48257A46:0025E6D5; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: <>
Date: Wed, 25 Jul 2012 14:55:15 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-07-25 14:55:17, Serialize complete at 2012-07-25 14:55:17
Content-Type: multipart/alternative; boundary="=_alternative 00263B7B48257A46_="
X-MAIL: q6P6tKLC002782
Subject: Re: [trill] ESADI draft change suggestion
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Developing a hybrid router/bridge." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 25 Jul 2012 06:55:32 -0000

Hi Sujay,

Sorry for delaying reponse. Thanks for the suggestion, please see in-line.

Zhai Hongjun
 Protocol Development Dept.VI, Central R&D Institute, ZTE Corporation
 No. 68, Zijinghua Road, Yuhuatai District, Nanjing, P.R.China, 210012
 Zhai Hongjun
 Tel: +86-25-52877345

Sujay Gupta <> 
2012-07-23 09:34


[trill] ESADI draft change suggestion



The ESADI protocol objectives as stated in the draft-04, IMO needs added 
Section 1: "Introduction"
   protocol's potential advantages over data plane learning include the

   1. Security advantages:..
   2. Fast update advantages:..

w.r.t to Security advantages, albeit ESADI can make a authenticated 
entries an insecure ESADI increases
the security vulnerability then without it. My recommendation is to 
recommend a SHOULD clause to implement
security features. A secured deployment of TRILL may choose to live with a 
unsecured ESADI ( & therefore
possibly a more efficient/lighter ESADI); whilst a TRILL plane bridging 
3rd party aggregation and application
layers may choose for trusted/secured model.

[Hongjun] Although security is one of ESADI's potential advantanges, but 
it is not a focal point in that draft. ESADI draft focuses on the general 
mechanism of ESADI protocol, then an ESADI instance can find its 
neighbors, exchange end station addresses and keep link state database 
synchronization with its neighbors. How an ESADI obtains its security 
features is out of the scope of that spec. Since there will be much work 
to do if we consider the security features, I think it is more suitable to 
discuss those features in a new draft than that spec. Therefore, I do not 
think such a "SHOULD clause" is suitable in that spec.

This is w.r.t to learning of ESADI entries and timing them out. As per RFC 
6325, the entries are expected
to be removed only by the originating RBridge.
Section 4.8.3
“The situation is different for end-station address information acquired 
via the TRILL ESADI protocol. 
It is up to the originating RBridge to decide when to remove such 
information from its ESADI LSPs 
(or up to ESADI protocol timeouts if the originating RBridge becomes 
 For robust behavior it would be better to timeout the entries without 
depending on ESADI, the reason 
is a (wrong)ESADI directed forwarding can cause persistent traffic loss, 
unlike a best effort flood everywhere 
situation. Therefore my recommendation is the specs should not 'mandate' 
the timing out behavior.

[Hongjun] The spec gives two most common conditions under which an ESADI 
to time out some MAC addresses learned via ESADI (i.e., being told to do 
so by the originating RBridge or finding the originating RBridge 
inaccessible). But it does not mandate or imply that an ESADI can forget 
the learned MACs via ESADI only under the two conditions. Besides the two 
conditions, an ESADI can also decide to forget some learned MACs via ESADI 
based on local configured polices, for example, configured by 
administrator not to learn MACs from a specific ESADI RBridge.

Best Regards,

trill mailing list