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

From: "Tissa Senevirathne (tsenevir)" <[email-masked]>
Date: Wed, 22 Feb 2012 19:55:45 -0800

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
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: [email-masked]
Date: Fri, 24 Feb 2012 14:03:10 +0800

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

收件人
<[email-masked]>
抄送

主题
[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 

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:

Thanks
Tissa

---

From: Radia Perlman <[email-masked]>
Date: Fri, 24 Feb 2012 06:15:21 -0800

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 <[email-masked]>

> think the very important and essential goal of multi-level draft is to save
> nicknames.
>
> Best regards
> Fangwei Hu
>
>
>
>   *"Tissa Senevirathne (tsenevir)" <[email-masked]>*
> 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
>

---

From: "Tissa Senevirathne (tsenevir)" <[email-masked]>
Date: Fri, 24 Feb 2012 08:23:17 -0800

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:[email-masked]] 
Sent: Friday, February 24, 2012 6:15 AM
To: [email-masked]
Cc: Tissa Senevirathne (tsenevir); [email-masked]; [email-masked]
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

Hi, Tissa. 

(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

2012-02-23 11:55 

收件人

<[email-masked]> 

抄送

主题

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

Dear All

Abstract:

Thanks
Tissa

---

From: Radia Perlman <[email-masked]>
Date: Fri, 24 Feb 2012 09:05:09 -0800

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) <[email-masked]>

>  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:[email-masked]]
> *Sent:* Friday, February 24, 2012 6:15 AM
> *To:* [email-masked]
> *Cc:* Tissa Senevirathne (tsenevir); [email-masked];
> [email-masked]
> *Subject:* Re: [rbridge] Default nickname base approach for multilevel
> TRILL- draft-tissa-trill-multilevel-00.txt****
>
> ** **
>
> assignment much simpler and makes TRILL a lot more scalable.****
>
>  ****
>
> RBridges.****
>  ****
> transiting between level 1 and level 2.****
>
>  ****
>
> Radia****
>
> 2012/2/23 <[email-masked]>****
>
>
> Hi, Tissa.
>
> ****
> 发件人:  [email-masked] ****
>
> 2012-02-23 11:55 ****
>
> 收件人****
>
> <[email-masked]> ****
>
> 抄送****
>
> 主题****
>
>  draft-tissa-trill-multilevel-00.txt****
>
> ** **
>
>
>
>
> Dear All
>
> ****
> http://mailman.postel.org/mailman/listinfo/rbridge****
>
> ** **
>

---

From: Radia Perlman <[email-masked]>
Date: Fri, 24 Feb 2012 09:23:06 -0800

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

>  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. ****
>
> ** **
>
> *Sent:* Friday, February 24, 2012 9:05 AM
> *To:* Tissa Senevirathne (tsenevir)
> *Cc:* [email-masked]; [email-masked];
> (which you'd want anyway, for multitopology).****
>
>  ****
>
>  ****
>
> Radia****
>
> 2012/2/24 Tissa Senevirathne (tsenevir) <[email-masked]>****
>

---

From: "Tissa Senevirathne (tsenevir)" <[email-masked]>
Date: Fri, 24 Feb 2012 09:14:15 -0800

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:[email-masked]] 
Sent: Friday, February 24, 2012 9:05 AM
To: Tissa Senevirathne (tsenevir)
Cc: [email-masked]; [email-masked]; [email-masked]
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

 

Radia

Hi, Tissa. 

(2) nickname allocation 

(3) Dynamic ranges 

Best regards 
Fangwei Hu

2012-02-23 11:55 

收件人

<[email-masked]> 

抄送

主题

		

Dear All

Abstract:

Thanks
Tissa

---

From: "Tissa Senevirathne (tsenevir)" <[email-masked]>
Date: Fri, 24 Feb 2012 09:59:45 -0800

RBridges do not have to be in all topologies. Why would they should be?

What is Fulrcrum chip ? 

 

Sent: Friday, February 24, 2012 9:23 AM

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

 

Radia

 

Radia

Hi, Tissa. 

(2) nickname allocation 

(3) Dynamic ranges 

Best regards 
Fangwei Hu

2012-02-23 11:55 

收件人

<[email-masked]> 

抄送

主题

		

Dear All

Abstract:

Thanks
Tissa

---

From: "Tissa Senevirathne (tsenevir)" <[email-masked]>
Date: Fri, 24 Feb 2012 10:07:19 -0800

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.

Radia

 

Radia

 

Radia

Hi, Tissa. 

(2) nickname allocation 

(3) Dynamic ranges 

Best regards 
Fangwei Hu

2012-02-23 11:55 

收件人

<[email-masked]> 

抄送

主题

		

Dear All

Abstract:

Thanks
Tissa

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 24 Feb 2012 18:29:59 +0000

Changing the value in the existing nickname TRILL Header slots at border RBridges can be done in a NAT-like way or, with swap-nicknames, in a way which is not at all like NAT.

Thanks,
Donald
==========================================
Donald E. Eastlake, 3rd     [email-masked]
155 Beaver Street              +1-508-333-2270
 Milford, MA 01757 USA

From: [email-masked] [mailto:[email-masked]] On Behalf Of Tissa Senevirathne (tsenevir)
Sent: Friday, February 24, 2012 11:23 AM
To: Radia Perlman; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [rbridge] Default nickname base approach for multilevel TRILL- draft-tissa-trill-multilevel-00.txt

Radia
2012/2/23 <[email-masked]<mailto:[email-masked]>>

Hi, Tissa.

(2) nickname allocation

(3) Dynamic ranges

Best regards
Fangwei Hu

"Tissa Senevirathne (tsenevir)" <[email-masked]<mailto:[email-masked]>>
发件人:  [email-masked]<mailto:[email-masked]>

2012-02-23 11:55

收件人

<[email-masked]<mailto:[email-masked]>>

抄送

主题

Dear All

Abstract:

Thanks
Tissa

_______________________________________________
rbridge mailing list
[email-masked]<mailto:[email-masked]>
http://mailman.postel.org/mailman/listinfo/rbridge

_______________________________________________
rbridge mailing list
[email-masked]<mailto:[email-masked]>
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 24 Feb 2012 18:44:07 +0000

See below at <dee3>.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Tissa Senevirathne (tsenevir)
Sent: Friday, February 24, 2012 1:00 PM
To: Radia Perlman
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [rbridge] Default nickname base approach for multilevel TRILL- draft-tissa-trill-multilevel-00.txt

<dee3> I would agree that an RBridge does not have to be in all topologies although I think it will be common for some RBridges to be in many topologies.

<dee3> I view a nickname as an abbreviation of the 48-bit IS-IS System ID. The differences being that it is shorter, is auto allocated by default, and there can be more than one of them that map to the same System ID so that an RBridge can be the root of more than one distribution tree and so that there could be an egress nickname that uses traffic engineered routing rather than the default least cost routing. Intermediate Systems do not have different System  IDs in different topologies, as far as I know. I don’t see how/why they would have different nicknames in different topologies.

What is Fulcrum chip ?

<dee3> The four merchant silicon manufacturers that I know of that have announced support for TRILL are, in alphabetic order, Broadcom, Fulcrum, Marvel, and Mellanox. (Fulcrum has been acquired by Intel.)

Thanks,
Donald

Radia
2012/2/24 Tissa Senevirathne (tsenevir) <[email-masked]<mailto:[email-masked]>>
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.

From: Radia Perlman [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Friday, February 24, 2012 9:05 AM
To: Tissa Senevirathne (tsenevir)
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Radia
2012/2/24 Tissa Senevirathne (tsenevir) <[email-masked]<mailto:[email-masked]>>
Mutli-topology is the answer to increase the nickname space.

From: Radia Perlman [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Friday, February 24, 2012 6:15 AM
To: [email-masked]<mailto:[email-masked]>
Cc: Tissa Senevirathne (tsenevir); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [rbridge] Default nickname base approach for multilevel TRILL- draft-tissa-trill-multilevel-00.txt

Radia

Hi, Tissa.

(2) nickname allocation

(3) Dynamic ranges

Best regards
Fangwei Hu

2012-02-23 11:55

收件人

抄送

主题

Dear All

Abstract:

Thanks
Tissa

---

From: Vishwas Manral <[email-masked]>
Date: Fri, 24 Feb 2012 14:58:18 -0800

Hi Radia,

I would agree with Tissa here.

Any translation is bad for running any end-to-end applications. Examples
would be OAM/ security etc. With this we will restrict applications that
carry a nickname we would require ALG's on translation.

With that said I find that for IP generally IS-IS is deployed as a single
level.

Tissa, Fulcrum is an ASIC company bought by Intel recently. They specialize
in Low Latency DC equipment.

Thanks,
Vishwas

2012/2/24 Radia Perlman <[email-masked]>

>> 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.****
>>
>> ** **
>>
>> 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
>> idea of TRILL Basic specification, and reduces the flexibility of
>> nickname allocation. As the draft assumed, A1 had
>> by Border RBridges. The design and maintaining of nickname ranges for
>> each area is a very hard work. Even worst, it
>> resolution can not work if the RBridge get the nickname from the
>> dynamical range while the two RBridge belongs to
>> dynamical range. So the question is how to avoid the duplication
>> dynamical range nickname for different areas.
>>

---

From: "Tissa Senevirathne (tsenevir)" <[email-masked]>
Date: Fri, 24 Feb 2012 19:01:00 -0800

Hi Donald

Thanks for the reply and as always very thoughtful answers. Please see in-line, below.

From: Donald Eastlake [mailto:[email-masked]] 
Sent: Friday, February 24, 2012 10:44 AM
To: Tissa Senevirathne (tsenevir); Radia Perlman
Cc: [email-masked]; [email-masked]
Subject: RE: [rbridge] Default nickname base approach for multilevel TRILL-draft-tissa-trill-multilevel-00.txt

See below at <dee3>.

 

[Tissa] According to Section 5 of, RFC5120 (IS-IS Multi Topology), each topology maintain it’s own address space. The addresses in each address space can be same or different with each other. Section 3 of RFC 5120 explains how LSP needed to be exchanged between different IS when MT is implemented. Section 6 explain how SPF needed to be run, in summary SPF is per topology basis. Only difference between 5120 and TRILL is 16 bit nickname vs. IP address. In short RB1 with systemID-1 can have nickname 1 in topology 1, topology 2 and so on or nickname 1, in topo 1, nickname 2 in topo 2 and so on.

What is Fulcrum chip ? 

[Tissa], I know you did not started discussion of these commercial names, I was told IETF mailing lists should not be used for discussing vendor capabilities. So I will refrain from further commenting on this.

Thanks,

Donald

 Milford, MA 01757 USA

Radia

 

Radia

 

Radia

Hi, Tissa. 

(2) nickname allocation 

(3) Dynamic ranges 

Best regards 
Fangwei Hu

2012-02-23 11:55 

收件人

<[email-masked]> 

抄送

主题

		

Dear All

Abstract:

Thanks
Tissa

---

From: [email-masked]
Date: Mon, 27 Feb 2012 10:33:16 +0800

I agree with Radia, and do not think that Multi-topology can slove the 
nickname space issue.

There are two cases for MT (RFC5120):

(1) RBridge with Non-overlap nickname address. The nickname routes can be 
installed into a shared nickname RIB table. And there is no need for 
marking the data with different Topology. This situation can not help to 
nickname exhaustion issue.

(2) RBridge with overlap nickname address. The RBridge can be assigned the 
same nickname for different topology. But we should consider to mark the 
data with different toplology. Besides the stealing bits methods, we have 
no good ideas to do that. The stealing bits methods can not reudce the 
nickname exhausting issue actually, because it reudce the valid lengh of 
nickname. 

Radia Perlman <[email-masked]> 
2012-02-25 01:23

收件人
"Tissa Senevirathne (tsenevir)" <[email-masked]>
抄送
[email-masked], [email-masked], [email-masked]
主题
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) <[email-masked]>
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. 

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
 
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.
 
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:[email-masked]] 
Sent: Friday, February 24, 2012 6:15 AM
To: [email-masked]
Cc: Tissa Senevirathne (tsenevir); [email-masked]; 
[email-masked]
Subject: Re: [rbridge] Default nickname base approach for multilevel 
TRILL- draft-tissa-trill-multilevel-00.txt

 
 
Radia

Hi, Tissa. 

(2) nickname allocation 

(3) Dynamic ranges 

Best regards 
Fangwei Hu

收件人
<[email-masked]> 
抄送

主题

Dear All

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:

Thanks
Tissa

---

From: [email-masked]
Date: Mon, 27 Feb 2012 10:50:04 +0800

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. 

2012-02-25 02:07

收件人
"Radia Perlman" <[email-masked]>
抄送
[email-masked], [email-masked], [email-masked]
主题
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.

 

Radia

 

Radia

 

 

 

Radia

Hi, Tissa. 

(2) nickname allocation 

(3) Dynamic ranges 

Best regards 
Fangwei Hu

收件人
<[email-masked]> 
抄送

主题

Dear All

Abstract:

Thanks
Tissa

---

From: "Tissa Senevirathne (tsenevir)" <[email-masked]>
Date: Sun, 26 Feb 2012 18:48:17 -0800

Lets leave multi topology a side for a moment. There are two broad questions here:

1.       Multi-level TRILL

2.        Increase nickname space for TRILL.

If #2 is an issue then that needed to be properly looked it in to. #1 has nothing do with #2. Contention is advocating nickname translation as the solution for #2. Like it was highlighted earlier, nickname translation has issues related OAM, inability to apply specific security policies and so on.

Multi-level solution presented in draft-tissa-trill-multilevel does not assume existence of any of the special feature, rather it provide data center interconnect based on generic methods.

If #2 is an issue I suggest working group to prioritize the action and work on it.

From: [email-masked] [mailto:[email-masked]] 
Sent: Sunday, February 26, 2012 6:33 PM
To: Radia Perlman
Cc: [email-masked]; [email-masked]; Tissa Senevirathne (tsenevir)
Subject: Re: Re: [rbridge] Default nickname base approach for multilevel TRILL- draft-tissa-trill-multilevel-00.txt

I agree with Radia, and do not think that Multi-topology can slove the nickname space issue. 

(1) RBridge with Non-overlap nickname address. The nickname routes can be installed into a shared nickname RIB table. And there is no need for marking the data with different Topology. This situation can not help to nickname exhaustion issue. 

(2) RBridge with overlap nickname address. The RBridge can be assigned the same nickname for different topology. But we should consider to mark the data with different toplology. Besides the stealing bits methods, we have no good ideas to do that. The stealing bits methods can not reudce the nickname exhausting issue actually, because it reudce the valid lengh of nickname. 

2012-02-25 01:23 

收件人

抄送

主题

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

  

Radia

2012/2/24 Tissa Senevirathne (tsenevir) <[email-masked] <mailto:[email-masked]> > 
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. 

From: Radia Perlman [mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Friday, February 24, 2012 9:05 AM
To: Tissa Senevirathne (tsenevir)
Cc: [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]>  

  

Radia 

2012/2/24 Tissa Senevirathne (tsenevir) <[email-masked] <mailto:[email-masked]> > 

  

From: Radia Perlman [mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Friday, February 24, 2012 6:15 AM
To: [email-masked] <mailto:[email-masked]> 
Cc: Tissa Senevirathne (tsenevir); [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> 
Subject: Re: [rbridge] Default nickname base approach for multilevel TRILL- draft-tissa-trill-multilevel-00.txt 

Radia 

2012/2/23 <[email-masked] <mailto:[email-masked]> > 

Hi, Tissa. 

(2) nickname allocation 

(3) Dynamic ranges 

Best regards 
Fangwei Hu

"Tissa Senevirathne (tsenevir)" <[email-masked] <mailto:[email-masked]> > 
发件人:  [email-masked] <mailto:[email-masked]>  

2012-02-23 11:55 

收件人

<[email-masked] <mailto:[email-masked]> > 

抄送

主题

 

Dear All

Abstract:

Thanks
Tissa

_______________________________________________
rbridge mailing list
[email-masked] <mailto:[email-masked]> 
http://mailman.postel.org/mailman/listinfo/rbridge <http://mailman.postel.org/mailman/listinfo/rbridge>  

_______________________________________________
rbridge mailing list
[email-masked] <mailto:[email-masked]> 
http://mailman.postel.org/mailman/listinfo/rbridge <http://mailman.postel.org/mailman/listinfo/rbridge>

---

From: Sam Aldrin <[email-masked]>
Date: Sun, 26 Feb 2012 19:40:34 -0800

On Feb 26, 2012, at 6:50 PM, [email-masked] wrote:

> 
> 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. 
And your point is?
> 
> If we can not slove the nickname space issue now, do we need another NICKNAMEv6 or something else? 
That could be a topic, which could be taken up to resolve nickname exhaustion issue and not necessarily at multilevel draft.
> So i thing the nickname space issue is the key issue we should slove now. 
That topic should be considered outside of this draft.
> 
> Multi-level draft is a good platform to slove it, though there is some technology we should considered futher. 
If multilevel draft is only to address 'nickname exhaustion' issue, then it should be renamed accordingly and not 'multilevel'. The purpose of multilevel draft is different, which is stated in the draft and the by product of it is nickname exhaustion could be alleviated and not just the primary problem/solution. Here is the snip from abstract "..novel method of constructing multi-destination trees using partial nickname space"

cheers
-sam

---

From: "Tissa Senevirathne (tsenevir)" <[email-masked]>
Date: Sun, 26 Feb 2012 19:21:37 -0800

Think about this way we have nickname translation method implemented and in a data center, and you have taken TRILL to the hypervisors. I am sitting on Data center A, I cannot reach to a specific MAC B. Only think my forwarding table would say is MAC-B is sitting in Data center B. Now trying to figure out where is MAC B exactly located requires lot more screening. Additionally, I want to apply rate limiting features to devices coming from public access area of Data Center B, if everything is now translated to B there is no way one could apply the required security policies, those are some examples.

I think we need to think progressively and novel, if we do that we have a very good chance of making TRILL very very successful and even rival out other competing technologies. If we try to utilize easier short cuts results may not be that attractive.

I think you are saying we need work on nickname space increase, but I do not think you are saying nickname translation as the solution correct ? If so I am fully on board with you.

I respectfully disagree with you on your interpretation of reason of doing IPv6.

I also suggest you to read the  IPv6 deployment presentation that was done during 82nd IETF on reasons for migrating to IPv6. It was said NAT is like life support keeping a brain dead person alive. If you still believe only reason of doing IPv6 is to increase the address space and NAT solve other issues, then we can extend this thread to include ipv6 and int-area mailing list to see what wider audience think about the topic.

From: [email-masked] [mailto:[email-masked]] 
Sent: Sunday, February 26, 2012 6:50 PM
To: Tissa Senevirathne (tsenevir)
Cc: Radia Perlman; [email-masked]; [email-masked]
Subject: Re: Re: [rbridge] Default nickname base approach for multilevel TRILL- draft-tissa-trill-multilevel-00.txt

2012-02-25 02:07 

收件人

抄送

主题

		

  

  
  
Radia 

  

Radia 

  

  

  

Radia 

Hi, Tissa. 

(2) nickname allocation 

(3) Dynamic ranges 

Best regards 
Fangwei Hu 

2012-02-23 11:55 

收件人

抄送

主题

  

Dear All

Abstract:

Thanks
Tissa

---

From: Sam Aldrin <[email-masked]>
Date: Sun, 26 Feb 2012 19:48:28 -0800

> I agree with Radia, and do not think that Multi-topology can slove the nickname space issue. 
As replied in other email, the draft is not to solve nickname exhaustion but rather have multilevel topologies constructed without having the need to change the identity of the original frame.
> (2) RBridge with overlap nickname address. The RBridge can be assigned the same nickname for different topology. But we should consider to mark the data with different toplology. Besides the steali…
Stealing bits is not a good idea, IMHO.

-sam

---

From: Sam Aldrin <[email-masked]>
Date: Sun, 26 Feb 2012 19:58:09 -0800

On Feb 26, 2012, at 7:47 PM, [email-masked] wrote:

> Pls see the following: 
> [hfw] My point is that the multi-level draft should solve the nickname space issue. 
Then why is the draft not named accordingly?
> 
> There is a multi-level draft is proposed by Radia, we can optimize it and make it better. There is no need to provide a new Multi-lelve draft which can not solve the key issue of nickname space. 
You mentioned that NAT couldn't solve the name exhaustion issue in IP world, why do you say that similar model solves nickname exhaustion issue in TRILL?
If you truly want to solve nickname issue, attempted should be outside of multilevel draft. As you said, we should rather have TrillIPv6 or whatever.

-sam
> 
> 
> 
> 
> Sam Aldrin <[email-masked]>
> 2012-02-27 11:40
> 
> 收件人
> [email-masked]
> 抄送
> "Tissa Senevirathne (tsenevir)" <[email-masked]>, [email-masked], [email-masked], Radia Perlman <[email-masked]>
> 主题

---

From: [email-masked]
Date: Mon, 27 Feb 2012 11:47:33 +0800

Pls see the following:

[hfw] My point is that the multi-level draft should solve the nickname 
space issue.

There is a multi-level draft is proposed by Radia, we can optimize it and 
make it better. There is no need to provide a new Multi-lelve draft which 
can not solve the key issue of nickname space.

收件人
[email-masked]
抄送
"Tissa Senevirathne (tsenevir)" <[email-masked]>, [email-masked], 
[email-masked], Radia Perlman <[email-masked]>
主题
Re: [rbridge] Default nickname base approach for multilevel TRILL- 
draft-tissa-trill-multilevel-00.txt

If we can not slove the nickname space issue now, do we need another 
NICKNAMEv6 or something else? 
That could be a topic, which could be taken up to resolve nickname 
exhaustion issue and not necessarily at multilevel draft.

Multi-level draft is a good platform to slove it, though there is some 
technology we should considered futher. 
If multilevel draft is only to address 'nickname exhaustion' issue, then 
it should be renamed accordingly and not 'multilevel'. The purpose of 
multilevel draft is different, which is stated in the draft and the by 
product of it is nickname exhaustion could be alleviated and not just the 
primary problem/solution. Here is the snip from abstract "..novel method 
of constructing multi-destination trees using partial nickname space"

cheers
-sam

收件人

  

 
 
Radia 

  

Radia 

  

  

 

Radia 

Hi, Tissa. 

(2) nickname allocation 

(3) Dynamic ranges 

(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

收件人
<[email-masked]> 
抄送

主题

Dear All

Abstract:

Thanks
Tissa

---

From: "Tissa Senevirathne (tsenevir)" <[email-masked]>
Date: Sun, 26 Feb 2012 19:55:57 -0800

Like stated in other emails, nickname space expansion require proper thoughts.

Radia’s multi-level draft require new data plane changes to implement nickname translation or nickname swap. What we are saying is mult-level TRILL can  be implemented with a simpler approach.

Nickname expansion needed to be solved with forward and progressive looking approaches for that some careful thinking is required.

From: [email-masked] [mailto:[email-masked]] 
Sent: Sunday, February 26, 2012 7:48 PM
To: Sam Aldrin
Cc: Radia Perlman; [email-masked]; [email-masked]; Tissa Senevirathne (tsenevir)
Subject: Re: Re: [rbridge] Default nickname base approach for multilevel TRILL- draft-tissa-trill-multilevel-00.txt

Pls see the following: 

2012-02-27 11:40 

收件人

[email-masked] 

抄送

主题

		

On Feb 26, 2012, at 6:50 PM, [email-masked] <mailto:[email-masked]>  wrote: 

cheers 
-sam 

2012-02-25 02:07 

收件人

"Radia Perlman" <[email-masked] <mailto:[email-masked]> > 

抄送

[email-masked] <mailto:[email-masked]> , [email-masked] <mailto:[email-masked]> , [email-masked] <mailto:[email-masked]>  

主题

		

 

 
 
Radia 

 

Radia 

 

 

 

Radia 

Hi, Tissa. 

(2) nickname allocation 

(3) Dynamic ranges 

Best regards 
Fangwei Hu 

2012-02-23 11:55 

收件人

抄送

主题

  

Dear All

Abstract:

Thanks
Tissa