[rbridge] Several open comments for TRILL's future work

[Vishwas Manral]

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.

> 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