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

From: zhangmingui 00171239 <[email-masked]>
Date: Tue, 09 Nov 2010 11:08:55 +0800

Hi,

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. 

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.

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?

4. ECMP is good for traffic engineering. Can RBridge support different traffic splitting ratios for the multi-path?

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?

--
Mingui Zhang
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Vishwas Manral <[email-masked]>
Date: Mon, 8 Nov 2010 19:50:30 -0800

Hi Mingui,

> 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 d…
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…
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…
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

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 8 Nov 2010 23:41:39 -0500

Adding a little bit to Vishwas's good comments:

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

> support the issue will not happen.

IETF RFC 5310 is "IS-IS Generic Cryptographic Authentication".

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

> Vishwas

Thanks,
Donald

---

From: xuxiaohu 41208 <[email-masked]>
Date: Tue, 09 Nov 2010 13:20:37 +0800

----- 原邮件 -----
发件人: Vishwas Manral <[email-masked]>
日期: 星期二, 十一月 9日, 2010 下午12:01
主题: Re: [rbridge] Several open comments for TRILL's future work
收件人: zhangmingui 00171239 <[email-masked]>
抄送: [email-masked], [email-masked]

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

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.
> > 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?
> > 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?

---

From: xuxiaohu 41208 <[email-masked]>
Date: Tue, 09 Nov 2010 13:26:16 +0800

----- 原邮件 -----
发件人: Donald Eastlake <[email-masked]>
日期: 星期二, 十一月 9日, 2010 下午1:04
主题: Re: [rbridge] Several open comments for TRILL's future work
收件人: zhangmingui 00171239 <[email-masked]>
抄送: [email-masked], [email-masked]

> >> 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.)
> >>

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

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

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 9 Nov 2010 01:00:14 -0500

Hi,

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

The reality is that
- there was very extensive discussion of this issue on the mailing list,
- some people like zero-configuration and some like to configure
everything that they can,
- the final result as specified in the TRILL base protocol standard
works for zero configuration, works for pre-configured nicknames,
works for a mix of non-configured and configured, and even works when
the RBridges are mis-configured (i.e., two or more are initially
configured to have the same nickname).

Thanks,
Donald