Re: [trill] A tweak to option 2, if it's hard to upgrade VL guys to FGL-safe

zhai.hongjun@zte.com.cn Fri, 01 February 2013 08:30 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 DDB2921F8479; Fri, 1 Feb 2013 00:30:51 -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 mBl9Pd6Kt7tV; Fri, 1 Feb 2013 00:30:51 -0800 (PST)
Received: from zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 9450421F84B2; Fri, 1 Feb 2013 00:30:50 -0800 (PST)
Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 4B0BA116E137; Fri, 1 Feb 2013 16:30:22 +0800 (CST)
Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 13398183B183; Fri, 1 Feb 2013 16:32:12 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id r118UJaB008779; Fri, 1 Feb 2013 16:30:19 +0800 (GMT-8) (envelope-from zhai.hongjun@zte.com.cn)
In-Reply-To: <CAFOuuo5rHyAuQ1C6AWoYnkbG3T-if9cm8kS4MzWHdxS06Z6A1A@mail.gmail.com>
To: Radia Perlman <radiaperlman@gmail.com>
MIME-Version: 1.0
X-KeepSent: 10A7CD42:BA5BB6D9-48257B05:002CFA0F; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: <OF10A7CD42.BA5BB6D9-ON48257B05.002CFA0F-48257B05.002F1199@zte.com.cn>
From: zhai.hongjun@zte.com.cn
Date: Fri, 1 Feb 2013 16:30:24 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2013-02-01 16:30:11, Serialize complete at 2013-02-01 16:30:11
Content-Type: multipart/alternative; boundary="=_alternative 002F119548257B05_="
X-MAIL: mse01.zte.com.cn r118UJaB008779
Cc: trill-bounces@ietf.org, Anoop Ghanwani <anoop@alumni.duke.edu>, Ayan Banerjee <ayabaner@gmail.com>, Sam Aldrin <aldrin.ietf@gmail.com>, "Tissa Senevirathne \(tsenevir\)" <tsenevir@cisco.com>, "trill@ietf.org" <trill@ietf.org>, Donald Eastlake <d3e3e3@gmail.com>, Jon Hudson <jon.hudson@gmail.com>
Subject: Re: [trill] A tweak to option 2, if it's hard to upgrade VL guys to FGL-safe
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: Fri, 01 Feb 2013 08:30:52 -0000

As FGL frames and VL frames have different Ethertype, it is easy for 
FGL-safe RBridges to differentiate the two types of frames in data plane. 
And the tweaked Option 2 allows VL-RBridges exiting at the edge of a 
nework with FGL links if their FGL-safe neighbors can differentiate the 
two type frames, I am happy with it.

So, I support this tweaked option.


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
2013-02-01 05:47

收件人
"Tissa Senevirathne (tsenevir)" <tsenevir@cisco.com>
抄送
Anoop Ghanwani <anoop@alumni.duke.edu>du>, Ayan Banerjee 
<ayabaner@gmail.com>om>, Sam Aldrin <aldrin.ietf@gmail.com>om>, "trill@ietf.org" 
<trill@ietf.org>rg>, Donald Eastlake <d3e3e3@gmail.com>om>, Jon Hudson 
<jon.hudson@gmail.com>
主题
[trill] A tweak to option 2,    if it's hard to upgrade VL guys to 
FGL-safe






The other thread was getting a bit long, so I'm changing the subject line, 
since here I'm proposing a tweak to option 2 that will make it less 
restrictive.  To review, option 2 as originally proposed had this 
property:
 
>>With option 2, a VL guy cannot even be at the edge of a network with FGL 
links unless it is upgraded to 
>>FGL-safe AND advertises that it is FGL-safe.  Option 2 says a VL guy is 
completely ostrasized once 
>>FGL-labeled links are introduced.  There is NO coexistence of VL guys 
and FGL-guys once FGL-links are
 >>advertised. 
 
Here is the proposed tweak:
 
An FGL-safe guy has two choices of what to do with a VL neighbor (once FGL 
links are advertised)
 
a) ostrasize the VL neighbor completely (as was in option 2)
b) advertise a very high cost to the VL neighbor AND ALSO discard any FGL 
frames that would be forwarded to that VL neighbor.
 
If an FGL-safe guy is capable of differentiating between FGL and VL 
frames...forwarding VL but discarding FGL to a VL neighbor, then this 
would allow VL guys to be at the edge and successfully talk across an FGL 
core.
 
If an FGL-safe guy is not capable of differentiating between FGL and VL 
frames, then the VL guy will be ostrasized.
 
As for transit...if a VL guy is in the core, its FGL neighbors will report 
such high costs to it that if there is any FGL path, that will be the one 
that is chosen, and if there isn't, then you're no worse off than if the 
VL guy were completely ostrasized....it will look like there is a path, 
but FGL packets will be lost on the path.
 
And of course, you shouldn't have the VL guy be the root of a multicast 
tree, since link costs to it won't avoid it being on the path between FGL 
guys.
 
Radia
 
 _______________________________________________
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill