[rbridge] future work
xuxh at huawei.com
Mon Nov 8 21:26:16 PST 2010
----- ÔÓÊ¼þ -----
·¢¼þÈË: 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...
> >> 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
> rbridge mailing list
> rbridge at postel.org
More information about the rbridge