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

Radia Perlman <radiaperlman@gmail.com> Thu, 31 January 2013 21:47 UTC

Return-Path: <radiaperlman@gmail.com>
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 EBAC721F86AB for <trill@ietfa.amsl.com>; Thu, 31 Jan 2013 13:47:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.686
X-Spam-Level:
X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[AWL=0.912, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 BoQitcItF2Mv for <trill@ietfa.amsl.com>; Thu, 31 Jan 2013 13:47:45 -0800 (PST)
Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) by ietfa.amsl.com (Postfix) with ESMTP id E8C5F21F867A for <trill@ietf.org>; Thu, 31 Jan 2013 13:47:44 -0800 (PST)
Received: by mail-lb0-f177.google.com with SMTP id go11so3814676lbb.8 for <trill@ietf.org>; Thu, 31 Jan 2013 13:47:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=hKyqi/P9kS/ZBwOY9uOlZEPlUguapMk7DxCj57hcIxg=; b=fQHJPWWprm1c/xVOMW2FEFYRCvlmiTBEnpJYSlOQD3GIkKbc4rL5+eC8ZuKVMIEi5W kvOBQGiFlZCchpqZK31knQQOyI8DfVqUflyg1Pqai61UDT5tYEkQXq0GiOhPtsrODwzJ ZDHVKvYKqEVU7/8l1lMSNoH+Xu+vYCJYbfjjnq9DmSRfY/7c/eUH1brCrFSiJZwkUWNw n2VZQEjeQsvZBRne5Oy0CrqY6Ei7Gm+PRsqDxaezl7C10XyUUC5CCB8o5vJ8hxkQm8bf 2E/AX4rYLZ58wOq1NnuZ3xtO0W5r7FXLPljFQFo2+uIOm6iffkM8uVdAY/KV66L7Yh+x Zxfg==
MIME-Version: 1.0
X-Received: by 10.112.37.129 with SMTP id y1mr3924719lbj.17.1359668863843; Thu, 31 Jan 2013 13:47:43 -0800 (PST)
Received: by 10.112.64.17 with HTTP; Thu, 31 Jan 2013 13:47:43 -0800 (PST)
Date: Thu, 31 Jan 2013 13:47:43 -0800
Message-ID: <CAFOuuo5rHyAuQ1C6AWoYnkbG3T-if9cm8kS4MzWHdxS06Z6A1A@mail.gmail.com>
From: Radia Perlman <radiaperlman@gmail.com>
To: "Tissa Senevirathne (tsenevir)" <tsenevir@cisco.com>
Content-Type: multipart/alternative; boundary=e0cb4efe3306a43f5204d49c93bc
Cc: Anoop Ghanwani <anoop@alumni.duke.edu>, Ayan Banerjee <ayabaner@gmail.com>, Sam Aldrin <aldrin.ietf@gmail.com>, "trill@ietf.org" <trill@ietf.org>, Donald Eastlake <d3e3e3@gmail.com>, Jon Hudson <jon.hudson@gmail.com>
Subject: [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: Thu, 31 Jan 2013 21:47:46 -0000

 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