[trill] non-TRILL node perform TRILL encapsulation - draft-dunbar-trill-directory-assisted-encap-08.txt

Linda Dunbar <linda.dunbar@huawei.com> Tue, 07 October 2014 22:51 UTC

Return-Path: <linda.dunbar@huawei.com>
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 00A631A8A0C for <trill@ietfa.amsl.com>; Tue, 7 Oct 2014 15:51:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.987
X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id rTdZZ79p9U75 for <trill@ietfa.amsl.com>; Tue, 7 Oct 2014 15:51:37 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 409AE1A8983 for <trill@ietf.org>; Tue, 7 Oct 2014 15:51:37 -0700 (PDT)
Received: from (EHLO lhreml403-hub.china.huawei.com) ([]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNK17011; Tue, 07 Oct 2014 22:51:34 +0000 (GMT)
Received: from DFWEML705-CHM.china.huawei.com ( by lhreml403-hub.china.huawei.com ( with Microsoft SMTP Server (TLS) id; Tue, 7 Oct 2014 23:51:33 +0100
Received: from DFWEML701-CHM.china.huawei.com ([]) by dfweml705-chm ([]) with mapi id 14.03.0158.001; Tue, 7 Oct 2014 15:51:29 -0700
From: Linda Dunbar <linda.dunbar@huawei.com>
To: "trill@ietf.org" <trill@ietf.org>
Thread-Topic: non-TRILL node perform TRILL encapsulation - draft-dunbar-trill-directory-assisted-encap-08.txt
Thread-Index: AQHP4oE7bIPpo8iP0Ea75jUCyrQX2A==
Date: Tue, 07 Oct 2014 22:51:28 +0000
Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645E155EF@dfweml701-chm>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/trill/4HKe5R8Rr_oCyWsoYX3LZ55x-_g
Subject: [trill] non-TRILL node perform TRILL encapsulation - draft-dunbar-trill-directory-assisted-encap-08.txt
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 07 Oct 2014 22:51:40 -0000

If directory information is available, any node, even a non-RBridge node, can perform the TRILL encapsulation. This draft describes the benefits and a scheme for non-RBridge nodes to perform TRILL encapsulation.

When a TRILL encapsulated data packet reaches the ingress RBridge, the ingress RBridge simply forwards the pre-encapsulated packet to the RBridge that is specified by the egress nickname field of the TRILL header of the data frame. When the ingress RBridge receives a native Ethernet frame, it handles it as usual and may drop it if it has complete directory information indicating that the target is not attached to the TRILL campus.  

In this environment with complete directory information, the ingress RBridge doesn’t flood or forward the received data frames when the DA in the Ethernet data frames is unknown. 

When all attached nodes to ingress RBridge can pre-encapsulate TRILL header for traffic across the TRILL domain, the ingress RBridge don’t need to encapsulate any native Ethernet frames to the TRILL domain. The attached nodes can be connected to multiple edge RBridges by having multiple ports or by an bridged LAN.  Under this environment, there is no need to designate AF ports and all RBridge edge ports connected to one bridged LAN can receive and forward pre-encapsulated traffic, which can greatly improve the overall network utilization.

In addition, it avoid Nickname Exhaustion Issue and can Reduce MAC Tables for switches on Bridged LANs. 

Comments and suggestions are appreciated. 


-----Original Message-----
From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] 
Sent: Tuesday, October 07, 2014 3:48 PM
To: Radia Perlman; Linda Dunbar; Igor Gashinsky; Linda Dunbar; Radia Perlman; Igor Gashinsky; Donald Eastlake; Donald E. Eastlake 3rd
Subject: New Version Notification for draft-dunbar-trill-directory-assisted-encap-08.txt

A new version of I-D, draft-dunbar-trill-directory-assisted-encap-08.txt
has been successfully submitted by Linda Dunbar and posted to the IETF repository.

Name:		draft-dunbar-trill-directory-assisted-encap
Revision:	08
Title:		Directory Assisted TRILL Encapsulation
Document date:	2014-10-07
Group:		Individual Submission
Pages:		11
URL:            http://www.ietf.org/internet-drafts/draft-dunbar-trill-directory-assisted-encap-08.txt
Status:         https://datatracker.ietf.org/doc/draft-dunbar-trill-directory-assisted-encap/
Htmlized:       http://tools.ietf.org/html/draft-dunbar-trill-directory-assisted-encap-08
Diff:           http://www.ietf.org/rfcdiff?url2=draft-dunbar-trill-directory-assisted-encap-08

   This draft describes how data center network can benefit from
   non-RBridge nodes performing TRILL encapsulation with
   assistance from directory service.


Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat