Re: [rbridge] Default nickname base approach for multilevel TRILL- draft-tissa-trill-multilevel-00.txt

Hi, Tissa.

I have several comments about the draft.

(1) in section 4.4 (Multicast), "The scope of global traffic may be 
identified either through VLAN or via finegrain 
label that spans across the entire TRILL campus."
Vlan and Fine-grain Label is used for service differentiation and 
isolation. I do not quite understand that how to
use VLAN and fine-grain Lable to identify the traffic scope. The data 
traffic with a given VLAN-x, can 
be forwarded to other end station in the local area, or to the end station 
in remote areas. 

(2) nickname allocation
The nickname management sub-TLV is proposed in the document. I wonder this 
mechanism adds the complication of 
nickname allocation. As the section 1 (introduction) of RFC6325, one of 
the important advantage of TRILL is that 
it avoids the creating subnets of IP address and wasting address. The 
nickname acquisition  method in this draft violates the 
idea of TRILL Basic specification, and reduces the flexibility of nickname 
allocation. As the draft assumed, A1 had 
nickname range of 100-200, A2 has a local nickname range of 201-300. If 
the numbers of A1 area is only 50, so 50 
nicknames in A1 is wasted. As the network growing, the number of some 
areas may exceed the number being allocation 
by Border RBridges. The design and maintaining of nickname ranges for each 
area is a very hard work. Even worst, it 
can not avoid to waste nickname space.

(3) Dynamic ranges 
 The nickname range is divided into two range: local range and dynamical 
range. I wonder the nickname conflict 
resolution can not work if the RBridge get the nickname from the dynamical 
range while the two RBridge belongs to 
different areas. For example, RB1 is in area A1, and RB2 is in area A2. If 
RB1 gets the nickname N1 from dynamic 
range, and it will floods in area A1, and other RBridges in area A1 can 
not get nickname N1 because of nickname 
confliction mechanism, but RB2 in area A2 can not receive the PDU from 
RB1, and it  can also get the nickname N1 from 
dynamical range. So the question is how to avoid the duplication dynamical 
range nickname for different areas.

(4) The risk of running out of nickname maybe a issue for TRILL. The 
number of 2**16 nickname is enough for the current data center,
 but it maybe not enough in the future, especailly if TRILL over IP , 
TRILL over MPLS technology or some other data center technologies
 are deployed, the data center network can be a very lardge network. So i 
think the very important and essential goal of multi-level draft is to 
save nicknames.

Best regards
Fangwei Hu

"Tissa Senevirathne (tsenevir)" <tsenevir@cisco.com> 
发件人:  rbridge-bounces@postel.org
2012-02-23 11:55

收件人
<rbridge@postel.org>
抄送

主题
[rbridge] Default nickname base approach for multilevel TRILL- 
draft-tissa-trill-multilevel-00.txt

Dear All

We have submitted draft-tissa-trill-multilevel, present multilevel TRILL 
based on default nickname approach. Additionally we discuss construction 
of multi-destination trees and related RPF in multilevel TRILL. Please 
could you review and comment 

Detail of the draft and abstract are below.

Filename:                 draft-tissa-trill-multilevel
Revision:                 00
Title:                            Default Nickname Based Approach for 
Multilevel TRILL
Creation date:            2012-02-21
WG ID:                            Individual Submission
Number of pages: 26

Abstract:
   Multilevel TRILL allows the interconnection of multiple TRILL
   networks to form a larger TRILL network without proportionally
   increasing the size of the IS-IS LSP DB. In this document, an
   approach based on default route concept is presented. Also,
   presented in the document is a novel method of constructing multi-
   destination trees using partial nickname space. Methods presented in
   this document are compatible with the RFC6325 specified data plane
   operations.

Thanks
Tissa

_______________________________________________
rbridge mailing list
rbridge@postel.org
http://mailman.postel.org/mailman/listinfo/rbridge