Re: [trill] FGL "safe" mode in fine labels

Erik Nordmark <nordmark@acm.org> Thu, 04 April 2013 04:01 UTC

Return-Path: <nordmark@acm.org>
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 7822011E80A5 for <trill@ietfa.amsl.com>; Wed, 3 Apr 2013 21:01:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level:
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MhjZYK2Sjgzu for <trill@ietfa.amsl.com>; Wed, 3 Apr 2013 21:01:59 -0700 (PDT)
Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by ietfa.amsl.com (Postfix) with ESMTP id 07C9011E80A2 for <trill@ietf.org>; Wed, 3 Apr 2013 21:01:58 -0700 (PDT)
Received: from [10.21.145.80] (128-107-239-233.cisco.com [128.107.239.233]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id r3441tHZ020993 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Apr 2013 21:01:56 -0700
Message-ID: <515CFB34.2060800@acm.org>
Date: Wed, 03 Apr 2013 21:01:56 -0700
From: Erik Nordmark <nordmark@acm.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: Donald Eastlake <d3e3e3@gmail.com>
References: <201303201859.r2KIxJ32017742@cichlid.raleigh.ibm.com> <CAFOuuo5nwwtEwJSqXZqOQ6tvxkbn+6jMimJVr9OMfwcSSFxfBw@mail.gmail.com> <201303202032.r2KKWOMj030163@cichlid.raleigh.ibm.com> <CAFOuuo5Q1at-pn_JPGP-5-WezsKjF6_psDd22_A5sN+sGGq-rw@mail.gmail.com> <201303202119.r2KLJL8X003890@cichlid.raleigh.ibm.com> <CAF4+nEFoGuxKT5OARjMjF2FmEisEFG1vwNknG9Fzz1BEAGdu4g@mail.gmail.com> <201303210103.r2L13KOi032305@cichlid.raleigh.ibm.com> <CAF4+nEG7L-tZ5M7O3DBS9SQPZvguRF8KRgWjLMTPFb_1Dvzosg@mail.gmail.com>
In-Reply-To: <CAF4+nEG7L-tZ5M7O3DBS9SQPZvguRF8KRgWjLMTPFb_1Dvzosg@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Thomas Narten <narten@us.ibm.com>, trill@ietf.org
Subject: Re: [trill] FGL "safe" mode in fine labels
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, 04 Apr 2013 04:01:59 -0000

On 3/22/13 8:06 AM, Donald Eastlake wrote:
>> >3a) First, if you are using both VL-Edges and FGL-edges, what is the
>> >interoperabilty model intended to be? If RB1 is VL-only and supports
>> >VLAN 1, but RB3 is an FGL-edge and also accepts traffic on VLAN 1,
>> >what is supposed to happen? Is traffic supposed to be relayed between
>> >those two VLANs? Why or why not?
 >
> I don't quite understand your questions and, like almost everything,
> it depends on whether you are doing 0, 1, or 2 and your topology, at
> least whether your FGL-safe TRILL switches are all contiguous, as they
> should be, or your campus is misconfigured to have disjoint FGL
> islands.

I think Thomas question is not so much about the transit behavior, but 
about the semantics of a VLAN vs. a FGL at the edge.

FWIW VLAN 1 is a bad example, because it special from 802.1's 
perspective. I'll use VLAN 100 below aka VLAN 0x64 (in hex).

When RB1 receives a native packet with VLAN 100 (or a co-located bridge 
tags an untagged from a port configured to tag with VLAN 100), then this 
packet will be encapsulated by TRILL with an inner VLAN 100.

If the port on RB3 (recall, FGL is configured per port at the edge) has 
been configured as a VL port, then the same thing happens on RB3 as on RB1.

But if the port on RB3 has been configured as FGL, then RB3 will map 
VLAN 100 to some FGL. That FGL value could be 0x000064 (i.e., a FGL 
label with the value of 100) or it could be 0x123456.
In neither of those cases will that be equivalent to a packet with VL 
0x064. The VL space is disjoint from the FGL space.

All of the above is orthogonal to how the transit works - whether or not 
there are some VL RBridges or only FGL-safe RBridges in the network.

    Erik