Re: [trill] Thoughts on active-active edge

zhai.hongjun@zte.com.cn Thu, 13 December 2012 12:03 UTC

Return-Path: <zhai.hongjun@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 64BE021F89A7; Thu, 13 Dec 2012 04:03:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -96.999
X-Spam-Level:
X-Spam-Status: No, score=-96.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100, WEIRD_QUOTING=1.396]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CyapiBBmmiio; Thu, 13 Dec 2012 04:03:40 -0800 (PST)
Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id E293721F8990; Thu, 13 Dec 2012 04:03:39 -0800 (PST)
Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 14C2B1266C8E; Thu, 13 Dec 2012 20:05:30 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id qBDC34Yc049667; Thu, 13 Dec 2012 20:03:04 +0800 (GMT-8) (envelope-from zhai.hongjun@zte.com.cn)
In-Reply-To: <CAFOuuo4wfJDfbshPa14ruK-SPrxU4W-Pu9uRY2to0KBaKjt5JA@mail.gmail.com>
To: Radia Perlman <radiaperlman@gmail.com>
MIME-Version: 1.0
X-KeepSent: 91CA02ED:06B3BB81-48257AD3:00405487; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: <OF91CA02ED.06B3BB81-ON48257AD3.00405487-48257AD3.0042706D@zte.com.cn>
From: zhai.hongjun@zte.com.cn
Date: Thu, 13 Dec 2012 20:03:01 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-12-13 20:02:58, Serialize complete at 2012-12-13 20:02:58
Content-Type: multipart/alternative; boundary="=_alternative 0042706A48257AD3_="
X-MAIL: mse01.zte.com.cn qBDC34Yc049667
Cc: Thomas Narten <narten@us.ibm.com>, trill-bounces@ietf.org, Sam Aldrin <aldrin.ietf@gmail.com>, Mingui Zhang <zhangmingui@huawei.com>, "trill@ietf.org" <trill@ietf.org>, "Tissa Senevirathne (tsenevir)" <tsenevir@cisco.com>
Subject: Re: [trill] Thoughts on active-active edge
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: Thu, 13 Dec 2012 12:03:41 -0000

Hi Radia

> This case is scary because the RBridges on the uplink cannot see Hellos 
from each other, 
> so if misconfigured, at the very least I could imagine multiple RBridges 
decapsulating 
> multicast from the campus to the hypervisor.

> Anyway...how many uplinks do we need to support?  Do we care about 
problems due to misconfiguration?

I don't know what the misconfiguration refers to. Is it the set of VLANs 
for which an Rbridge acts as AF?


> Are there cases where there are lots of hypervisors, where they attach 
to different subsets of edge RBs?  
> In that case, we might eat up a lot of nicknames, since if one 
hypervisor is attached to {R1, R2}, 
> and another is attached to {R1, R2, R3}, they cannot use the same 
pseudonode nickname.

I don't know why the two sets of RBridges can not use the same 
pseudo-nickname. If the learned MAC addresses 
can be shared among member Rbridges of an RBv and TRILL data frames can be 
tunneled to another member Rbridge
that can egress the frame, I think they can use the same pseudo-nickname.

If I am wrong, please correct me.

Best Regards,
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
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""





Radia Perlman <radiaperlman@gmail.com> 
发件人:  trill-bounces@ietf.org
2012-12-13 15:13

收件人
Mingui Zhang <zhangmingui@huawei.com>
抄送
Thomas Narten <narten@us.ibm.com>, Sam Aldrin <aldrin.ietf@gmail.com>, 
"Tissa Senevirathne \(tsenevir\)" <tsenevir@cisco.com>, "trill@ietf.org" 
<trill@ietf.org>
主题
Re: [trill] Thoughts on active-active edge






I think it would be good to have a document that explains the problem...I 
certainly don't believe I know all the cases that need to be solved.  I 
think I understand the hypervisor case...where the hypervisor decides 
which uplink to send things to, and never forwards between the up-links.

This case is scary because the RBridges on the uplink cannot see Hellos 
from each other, so if misconfigured, at the very least I could imagine 
multiple RBridges decapsulating multicast from the campus to the 
hypervisor.

Anyway...how many uplinks do we need to support?  Do we care about 
problems due to misconfiguration?

In cases like this, is it common to also have pt-to-pt links between all 
the RBs attaching to the hypervisor?  If so, then it seems like it would 
be possible for them to coordinate to at least detect misconfiguration, 
and possibly play games with forwarding messages to each other (e.g., if 
one of them is not attached to a tree and needs to encapsulate a 
multidestination frame).

How many trees does the campus need?

Are there cases where there are lots of hypervisors, where they attach to 
different subsets of edge RBs?  In that case, we might eat up a lot of 
nicknames, since if one hypervisor is attached to {R1, R2}, and another is 
attached to {R1, R2, R3}, they cannot use the same pseudonode nickname.

Are there cases other than hypervisors?  I think there are cases of 
bridges that have this behavior (a port with a bunch of endnodes, and 
several up-links, where the bridge does not forward between the up-links. 
 

If this has been written down anywhere, can anyone point me to it?  If 
not, it seems really prudent to answer these (and I'm sure other) 
questions before arguing about specific solutions.

Radia

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