[rbridge] future work

[xuxiaohu 41208]

----- Ô­Óʼþ -----
·¢¼þÈË: Donald Eastlake <d3e3e3 at gmail.com>
ÈÕÆÚ: ÐÇÆÚ¶þ, ʮһÔ 9ÈÕ, 2010 ÏÂÎç1:04
Ö÷Ìâ: 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

> Adding a little bit to Vishwas's good comments:
> 
> On Mon, Nov 8, 2010 at 10:50 PM, Vishwas Manral 
> <vishwas.ietf at gmail.com> wrote:
> > 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.
> 
> There is some work going on related to possible solutions to the
> 16-bit nickname space limit. Possibly something will be posted in
> several weeks...

I heard before that one of the advantages of 16-bit nickname over the 32-bit IP address is that the former has less overhead. However...

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.
> 
> IETF RFC 5310 is "IS-IS Generic Cryptographic Authentication".
> 
> >> 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.
> 
> I'm also not clear on what you are asking. You could also use MPLS as
> the link protocol between two or more RBridge ports...
> 
> >> 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
> 
> Thanks,
> Donald
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>