Re: [trill] Charter Revision Active-Active Item

> > 1. Simplified AF mechanism with the approach specified by RFC6325
> > appendix A.3. draft-yizhou-trill-tc-awareness described STP topology
> > change problem within this scenario too.

> I think the TRILL WG can produce a document updating Appendix A.3 of
> RFC 6325 without having that included in a special numbered work item.

Support. I think the update of appendix A of RFC6325 can achieve another 
way of load balancing which is different from MC-LAG(or active/active) 
load balancing scenario, so it should not be included in the work item.
But I support to put it into an individual document.

Best Regards,
Hongjun Zhai
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
 Protocol Development Dept.VI, Central R&D Institute, ZTE Corporation
 No. 68, Zijinghua Road, Yuhuatai District, Nanjing, P.R.China, 210012

 Hongjun Zhai

 Tel: +86-25-52877345
 Email: zhai.hongjun@zte.com.cn
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""

Donald Eastlake <d3e3e3@gmail.com> 
发件人:  trill-bounces@ietf.org
2013-06-15 02:47

收件人
trill@ietf.org
抄送

主题
Re: [trill] Charter Revision Active-Active Item

Hi Yizhou,

On Thu, May 2, 2013 at 11:14 PM, Yizhou Li <liyizhou@huawei.com>
wrote:

> Currently we have appointed forwarder (AF) mechanism for
> multi-access link connecting to edge RBridges. As AF only allows one
> RBridge forwarding frames for a single VLAN, it is normally
> considered as VLAN scoped active-standby though traffic can be load
> balanced among VLANs.
>
> The word "active-active" used in item 2 excludes the problems
> identified for current AF mechanism and non active-active
> scenarios. I think something like "multi-access connections at the
> edge" is a better description. Problems in multi-access connections
> but not typical active-active scenarios include the following in my
> opinion,
>
> 1. Simplified AF mechanism with the approach specified by RFC6325
> appendix A.3. draft-yizhou-trill-tc-awareness described STP topology
> change problem within this scenario too.

I think the TRILL WG can produce a document updating Appendix A.3 of
RFC 6325 without having that included in a special numbered work item.

> 2. Optimization of AF mechanism, e.g - Better convergence time for
> failure recovery. Currently (3*) Hello timer is used to detect the
> neighbor RB failure and then DRB should re-assign the VLANs
> previously delegated to the failed RB to others. It takes too long
> time in practice. I believe at least for access link (not equipment)
> failure some optimization can be done for traditional AF mechanism
> to improve the detection timer and AF re-assignment.

Connectivity failure to a neighbor RB can also be detected by BFD or
in other ways. But in any case, updating RFC 6439 concerning Appointed
Forwarders is also something I think we can do without it being included
in a special numbered work item.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3@gmail.com

> 3. Common problems for both active-active and active-standby (AF like
> mechanism) cases. E.g. rapid MAC address purge at the remote RBridge 
when
> existing nickname-MAC correspondence becomes invalid at local.
>
> I propose one of the following to be present in the charter.
> 1) Specify a larger scope for item 2. E.g. replace active-active with
> multi-access
> Or
> 2) Add another item. Something like, Enhancement of current multi-access
> connection mechanism at the edge of a TRILL campus.
>
>
> Thanks,
> Yizhou
>
> -----Original Message-----
> From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf 
Of
> Donald Eastlake
> Sent: Friday, May 03, 2013 10:06 AM
> To: trill@ietf.org
> Subject: [trill] Charter Revision Active-Active Item
>
> Hi,
>
> Item "(2) Active-Active connection at the edge of a TRILL campus.
> (draft-ietf-trill-cmt, draft-hu-trill-pseudonode-nickname)"
>
> There appeared to be agreement that work should be done in this space
> but a better problem statement / scope was requested.
>
> Comments?
>
> Thanks,
> Donald
_______________________________________________
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill