[rbridge] future work

[xuxiaohu 41208]

----- Ô­Óʼþ -----
·¢¼þÈË: Vishwas Manral <vishwas.ietf at gmail.com>
ÈÕÆÚ: ÐÇÆÚ¶þ, ʮһÔ 9ÈÕ, 2010 ÏÂÎç12:01
Ö÷Ìâ: Re: [rbridge] Several open comments for TRILL's future work
ÊÕ¼þÈË: zhangmingui 00171239 <mingui at huawei.com>
³­ËÍ: rbridge at postel.org, Radia at alum.mit.edu

> Hi Mingui,
> 
> > For the future work of TRILL. I have the following open comments 
> for your consideration. (Some of them may already have been 
> discussed during the face to face talk with radia.)
> >
> > 1. The potential issue of running out of nicknames. We have not 
> seen customer networks with bridges that exceed the magnititude of 
> thousands. However, data center networks and cloud computing are 
> developing so rapidly. It is possible that the 16-bit nickname 
> will be not enough one day. Even it is enough, TRILL has to use 
> algorithms for nickname collisions. When the collisions become 
> frequently, the network may not be used anymore.
> VM> By then all the Nicknames will be manually configured, which is
> the way I see the implementations going.

I heard before that one of the obvious benefits of nickname over IP address is zero-configuration. But the reality is...

BR,
Xiaohu


> > 2. Will the nickname collisions disturb the ongoing traffic. 
> Will this become an security problem. Malicious attackers can well 
> use this to disturb the services.
> VM> Yes it can become a security issue, however with IS-IS RFC 5310
> support the issue will not happen.
> 
> > 3. Can we deploy MPLS based on the TRILL's forwarding layer. 
> Maybe the answer is simply yes. Then how about MPLS-TE, including 
> the RSVP-TE and so on. Will these techniques be popular in the 
> future on TRILL networks?
> VM> I do not understand what you mean. If you mean connecting 2 TRILL
> campus using MPLS, that is certainly possible. I saw a draft of having
> TRILL PW emulation, which can be an alternative to the OTV draft.
> 
> > 4. ECMP is good for traffic engineering. Can RBridge support 
> different traffic splitting ratios for the multi-path?
> VM> Yes.
> 
> > 5. Does the multi-cast traffic occupy a large proportion of the 
> whole traffic demand. I found that TRILL put much attention on the 
> distribution tree construction mechanism. 802.1AQ is used to solve 
> similar problems as TRILL. I call these two techniques as Layer-2-
> Multi-pathing. In 802.1AQ, each ingress point simply forward the 
> multi-cast traffic as the root of SPT (Shortest Path Tree). Why 
> TRILL does not do this?
> VM> It provides a superset of the functionality, which in the worst
> case can be used to get a similar behavior as you mention.
> 
> Thanks,
> Vishwas
> > --
> > Mingui Zhang
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>