[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

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
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
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
Precedence: list

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. 

Linda 

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

Abstract:
   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

[trill] non-TRILL node perform TRILL encapsulatio… Linda Dunbar