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

[[e-mail]]

The reason why folks in IP word are pushing to go to IPv6 is that the 
exhausting of IPv4 address, not that the NAT can not work. 

The NAT technology is widely deployed in China, and it does work well. 
There is very little IPv4 address can be assigned to the BNAS(Most of the 
address assigned to the user are private IPv4 address, and only the NNAS 
and above equitment are assigned public address ), so it is an emergent 
thing to transit from IPv4 to IPv6.

If we can not slove the nickname space issue now, do we need another 
NICKNAMEv6 or something else? 

So i thing the nickname space issue is the key issue we should slove now. 

Multi-level draft is a good platform to slove it, though there is some 
technology we should considered futher. 




"Tissa Senevirathne (tsenevir)" <[e-mail]> 
发件人:  [e-mail]
2012-02-25 02:07

收件人
"Radia Perlman" <[e-mail]>
抄送
[e-mail], [e-mail], [e-mail]
主题
Re: [rbridge] Default nickname base approach for multilevel TRILL- 
draft-tissa-trill-multilevel-00.txt






Also, there are so many well known issues with NAT like approaches. #1 is 
you would lose identity of originator, and it becomes an OAM nightmare. It 
limit ability apply certain ACL, rate-limiting etc.
 
There is a whole series of issues associated with NATs. That is one of the 
reasons folks in IP world are pushing hard to go to IPv6. I was assuming 
people are aware of those.
 
From: Radia Perlman [mailto:[e-mail]] 
Sent: Friday, February 24, 2012 9:23 AM
To: Tissa Senevirathne (tsenevir)
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Re: [rbridge] Default nickname base approach for multilevel 
TRILL- draft-tissa-trill-multilevel-00.txt
 
I assume that all RBridges will need to be in all topologies, so 
multitopology will not help with nickname exhaustion.  Plus you haven't 
explained how a TRILL packet would be marked as to which topology the 
packet should be routed according to (other than what I mentioned, which 
actually eats up nicknames by a factor of the number of topologies 
supported).
 
Plus, rather than just lumping potential issues into a phrase such as 
"NAT-like", be explicit about what issues there actually are.  I believe 
the Fulcrum chip would have no problem with translating the nickname 
fields.
 
And rather than assuming that nickname exhaustion can be solved "some 
other way", there should be a palatable solution before rejecting a chance 
to solve it with multilevel.
 
Radia
2012/2/24 Tissa Senevirathne (tsenevir) <[e-mail]>
Because you can have same nickname for different topology. It is not a 
nickname that will identify an RBRidge, it is topology,nickname 
combination that will identify an RBRidge. So RB1 can have nickname 1 in 
topo-1 and RB2 can have nickname 1 in topo2. Now total nicknames in the 
campus is 2**16 x topologies.
 
Stealing bits to represent topo id is only a workaround there can be (are 
) more elegant ways of doing it that.
 
Bottom line is we need to look for more creative methods of solving 
nickname space issue than doing NAT like behavior. 
 
From: Radia Perlman [mailto:[e-mail]] 
Sent: Friday, February 24, 2012 9:05 AM
To: Tissa Senevirathne (tsenevir)
Cc: [e-mail]; [e-mail]; [e-mail] 

Subject: Re: [rbridge] Default nickname base approach for multilevel 
TRILL- draft-tissa-trill-multilevel-00.txt
 
I don't understand how multi-topology helps with the nickname exhaustion 
issue.  As a matter of fact, the only plausible way of marking a packet 
for which topology that has been suggested on the mailing list (I asked a 
efw times if there were any other possibilities), was to steal 2 or 3 bits 
of the nickname to encode which topology, in effect, making a destination 
appear as multiple destinations and multiple forwarding table entries 
(which you'd want anyway, for multitopology).
 
 
Radia
2012/2/24 Tissa Senevirathne (tsenevir) <[e-mail]>
Mutli-topology is the answer to increase the nickname space.
 
Nickname translation is very similar to NAT, which has it’s own down 
side, not to mention special hardware etc. to do the translations, 
additionally. We also know from our experience, in IP world NATing is not 
the most desired behavior and we live with it. So we should not be going 
down that path instead need to look forward from that experience.
 
Multi-topology not only address nickname space issue but also enables 
various other applications such as overlay topologies, traffic 
engineering.
 
The draft-tiss-trill-multilevel present approaches that are generic, which 
mean it can be applied for multi-topology, or base topology. It utilizes 
the fundamentals of IS-IS , such as Area hierarchy for reduction of the 
LSP-DB. It utilize affinity TLV concepts to effectively solve 
multi-destination issues. 
 
We should not mix-up between Data center interconnects with data center 
node scaling. They are two different and orthogonal issues.
 
Objective of multi-level trill is to interconnect different datacenters, 
and maintain LSP-DB small as possible to avoid scaling and volatility.
 
Increasing nickname space a different requirement and has nothing to do 
with data-center interconnects.
 
 
From: Radia Perlman [mailto:[e-mail]] 
Sent: Friday, February 24, 2012 6:15 AM
To: [e-mail]
Cc: Tissa Senevirathne (tsenevir); [e-mail]; 
[e-mail]
Subject: Re: [rbridge] Default nickname base approach for multilevel 
TRILL- draft-tissa-trill-multilevel-00.txt
 
People have mentioned to me that they are nervous about running out of 
nicknames, especially since there are reasonson why they might want to 
assign nicknames to hypervisors.  With the alternate approach of allowing 
nicknames to be reused in different areas, it makes automatic nickname 
assignment much simpler and makes TRILL a lot more scalable.
 
It does have the downside of requiring mapping of nicknames at the border 
RBridges.
 
And by the way, the affinity TLV can be used for multidestination frames 
transiting between level 1 and level 2.
 
Radia
2012/2/23 <[e-mail]>

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)" <[e-mail]> 
发件人:  [e-mail] 
2012-02-23 11:55 


收件人
<[e-mail]> 
抄送

主题
[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
[e-mail]
http://mailman.postel.org/mailman/listinfo/rbridge

_______________________________________________
rbridge mailing list
[e-mail]
http://mailman.postel.org/mailman/listinfo/rbridge
 
 
 _______________________________________________
rbridge mailing list
[e-mail]
http://mailman.postel.org/mailman/listinfo/rbridge

_______________________________________________
rbridge mailing list
[e-mail]
http://mailman.postel.org/mailman/listinfo/rbridge