[trill] 答复: Re: Comments on draft-ietf-trill-cmt-00

zhai.hongjun@zte.com.cn Thu, 18 October 2012 12:00 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 83D9621F85C2; Thu, 18 Oct 2012 05:00:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -92.154
X-Spam-Level:
X-Spam-Status: No, score=-92.154 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345, 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 UrNbqYJDrks8; Thu, 18 Oct 2012 05:00:57 -0700 (PDT)
Received: from zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id B5CF021F85AC; Thu, 18 Oct 2012 05:00:56 -0700 (PDT)
Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 1492E3188C; Thu, 18 Oct 2012 20:00:53 +0800 (CST)
Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id ED41372741D; Thu, 18 Oct 2012 19:57:52 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q9IC0meo061431; Thu, 18 Oct 2012 20:00:48 +0800 (GMT-8) (envelope-from zhai.hongjun@zte.com.cn)
In-Reply-To: <CAF4+nEEujrCHGA807qBCF25w88Qe94z11Sdd1cwX2YDp+RuB3g@mail.gmail.com>
To: Donald Eastlake <d3e3e3@gmail.com>
MIME-Version: 1.0
X-KeepSent: 3B1A103A:83CDDC34-48257A9B:00401761; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: <OF3B1A103A.83CDDC34-ON48257A9B.00401761-48257A9B.00421A85@zte.com.cn>
From: zhai.hongjun@zte.com.cn
Date: Thu, 18 Oct 2012 20:00:29 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-10-18 20:00:31, Serialize complete at 2012-10-18 20:00:31
Content-Type: multipart/alternative; boundary="=_alternative 00421A8448257A9B_="
X-MAIL: mse02.zte.com.cn q9IC0meo061431
Cc: trill-bounces@ietf.org, trill@ietf.org
Subject: [trill] =?gb2312?b?tPC4tDogUmU6ICBDb21tZW50cyBvbiBkcmFmdC1pZXRm?= =?gb2312?b?LXRyaWxsLWNtdC0wMA==?=
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, 18 Oct 2012 12:00:58 -0000

Hi Donald,

Thanks for your explanation.

> Then you need RPFC entries at every other RBridge
> for ingress RBv and those 6 tree. You don't need entries for RBv and 8
> tree, which wastes RPFC state. 

I agree you on this point.

> And if you only have entries for RBv and less than 6 trees, some TRILL 
> Data packets will be improperly discarded due to the RPFC.

I think you are right. Now my question is whether or not there are 6 
acceptable RPFC entries for RBv at each RBridge port at a given other 
RBridge, each entry for RBv and each of those 6 trees. In my mind, 
no same acceptable RPFC entries for an ingress RBridge (neither a physical 

RBridge nor RBv) are permitted existing at different ports at one given 
RBridge.


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
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""





Donald Eastlake <d3e3e3@gmail.com> 
发件人:  trill-bounces@ietf.org
2012-10-18 11:41

收件人
zhai.hongjun@zte.com.cn
抄送
trill@ietf.org
主题
Re: [trill] Comments on draft-ietf-trill-cmt-00






Hi,

On Sun, Oct 14, 2012 at 11:34 PM, <zhai.hongjun@zte.com.cn> wrote:
>
> Hi Donald,
>
> > - The draft should be clear that when doing the RPFC for a
> > multi-destination TRILL Data packet ingressed with a virtual RBridge
> > nickname, the RPFC must assume that the TRILL Data packet might use
> > any of the trees that any of the RBk might use.
>
> Do you mean that RBn ignores the egress nickname in a received
> multi-destinaion TRILL data packet with a virtual RBridge nickname
> when it does RPFC for that packet in that case? Or if I am wrong,
> please give a clearer explanation on that sentence by using an example.

One way to look at the RPFC is that at each RBridge port there is a
table of pairs of acceptable { ingress nickname, tree } where tree is
the egress nickname in a multi-destination TRILL Data packet. Say RB1
is not going to use all of the distribution trees being computed for a
campus. Then RB1 can optionally list the tress it is going to use.
This will reduce the amount of RPFC state at all the other RBridges in
the campus because instead of having an entry for some port for
ingress RB1 paired with every tree it only needs entries for ingress
RB1 paired with the trees RB1 says it might use.

Say a virtual RBridge RBv is in use as in the CMT draft. Then the edge
group RBridges, when converting a frame off the link to a TRILL Data
packet, will use RBv as the ingress nickname. Say you have 8 trees
being calculated for a campus and three edge group RBridges each using
two different trees. So the edge group RBridges all together only use
6 different trees. Then you need RPFC entries at every other RBridge
for ingress RBv and those 6 tree. You don't need entries for RBv and 8
tree, which wastes RPFC state. And if you only have entries for RBv
and less than 6 trees, some TRILL Data packets will be improperly
discarded due to the RPFC.

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

> 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
> """""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
>
>
>
>
> Donald Eastlake <d3e3e3@gmail.com>
> 发件人:  trill-bounces@ietf.org
>
> 2012-10-13 23:15
>
> 收件人
> trill@ietf.org
> 抄送
> 主题
> [trill] Comments on draft-ietf-trill-cmt-00
>
>
>
>
>
> There are my personal comments on draft-ietf-trill-cmt-00. I suggest
> that after these and the few other comments have been handled, the -01
> version be WG Last Called.
>
> - Some acronyms need to be spelled out on first use.
>
> - I think Figure 1 and Figure 2 are a bit muddled and should be
> clarified to show separate connections from each RBk to each CEn. It
> is also not clear to me why "DRB" occurs in the figures and I think it
> should be dropped.
>
> - The draft should be clear that when doing the RPFC for a
> multi-destination TRILL Data packet ingressed with a virtual RBridge
> nickname, the RPFC must assume that the TRILL Data packet might use
> any of the trees that any of the RBk might use.
>
> - The could be problems if a virtual RBridge nickname was taken away
> by a real RBridge somewhere else in the campus that is higher priority
> to hold a nickname. Perhaps the draft should suggest that virtual
> RBridge nicknames are usually configured  and should be held with
> maximum priority with with configured or unconfigured priority ranges,
> as appropriate...
>
> - I think it should be possible to use the Affinity Sub-TLV to change
> the structure of multi-destination distribution trees in places other
> than at the edge. So they should be valid as long as they do not
> conflict even if the requested child is a real RBridge. But, of
> course, the requested child has to be an adjacent RBridge and the
> draft should say what it would mean if some RBridge lists, as a
> requested child for some tree, its parent in that tree.
>
> Thanks,
> Donald
> =============================
> Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
> 155 Beaver Street, Milford, MA 01757 USA
> d3e3e3@gmail.com
> _______________________________________________
> trill mailing list
> trill@ietf.org
> https://www.ietf.org/mailman/listinfo/trill
>
_______________________________________________
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill