[rbridge] about the future work 1: Trill over IP

[xuxiaohu 41208]

----- Ô­Óʼþ -----
·¢¼þÈË: Erik Nordmark <erik.nordmark at oracle.com>
ÈÕÆÚ: ÐÇÆÚÒ», ʮһÔ 8ÈÕ, 2010 ÏÂÎç5:46
Ö÷Ìâ: Re: »Ø¸´:Re: [rbridge] Question about the future work 1: Trill over IP
ÊÕ¼þÈË: xuxiaohu 41208 <xuxh at huawei.com>
³­ËÍ: rbridge at postel.org

> On 11/ 8/10 01:32 AM, xuxiaohu 41208 wrote:
> > 
> > 
> > ----- Ô­Óʼþ -----
> > ·¢¼þÈË: Erik Nordmark<erik.nordmark at oracle.com>
> > ÈÕÆÚ: ÐÇÆÚÒ», ʮһÔ 8ÈÕ, 2010 ÏÂÎç3:53
> > Ö÷Ìâ: Re: [rbridge] Question about the future work 1: Trill over IP
> > ÊÕ¼þÈË: xuxiaohu 41208<xuxh at huawei.com>
> > ³­ËÍ: rbridge at postel.org
> > 
> >> On 11/ 7/10 10:54 PM, xuxiaohu 41208 wrote:
> >>> Hi all,
> >>>
> >>> My question about this future work is why not go step further to
> >>> encapsulate Ethernet over IP directly, rather than encapsulate
> >>> Ethernet over Trill and then encapsulate Trill over IP?
> >>
> >> Can you explain where you would carry the ingress nickname, egress
> >> nickname, the multi-destination bit, etc in that case?
> > 
> > Can't we use the source IP address and destination IP address to 
> fill the role of the ingress nickname and egress nickname? Is there 
> any neccessary and vital features that the trill header 
> encapsulation can support while the IP header encapsulation can not?
> 
> TRILL is based on the nicknames being assigned randomly and then 
> checkedfor duplicates using IS-IS. That doesn't match how IP 
> addresses are
> normally assigned.
> 
> Even if you somehow modify how the IP addresses would be assigned to
> match TRILL's expectations, you'd still need a way to carry other
> information that is in the TRILL header. For example, the
> multi-destination bit is a key part which affects how RBridges forward
> frames.

Can't the class D IP addresses and the PIM protocol fill the multicast function that trill does?

Anything else which is important to trill?

Best regards,
Xiaohu

> 
>   Erik
> 
>