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

[Radia Perlman <[e-mail]>]

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