Re: [trill] ESADI draft change suggestion

Hi Sujay，

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

Thanks,
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
 Email: zhai.hongjun@zte.com.cn
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""

Sujay Gupta <sujay.ietf@gmail.com> 
发件人:  trill-bounces@ietf.org
2012-07-23 09:34

收件人
trill@ietf.org
抄送

主题
[trill] ESADI draft change suggestion

Hi,

1)

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

   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.

2)
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 
inaccessible).”
<<
 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,
-Sujay

_______________________________________________
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill