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

[Vishwas Manral <[e-mail]>]

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

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