Re: [trill] New version : TRILL Smart Endnodes draft

[Linda Dunbar <[e-mail]>]

It is definitely simpler for Egress RBridge to decapsulate all received data frames:

*        So it doesn't need determine if the target end node is smart  or not

*        It doesn't have to attached different Ethernet Destination based on the inner header

*        It is consistent for all data frames and all end nodes.

*        Smart End node can receive native Ethernet frames anyway. It doesn't cause any extra processing on the Smart End node either.

Linda

From: Linda Dunbar
Sent: Thursday, January 10, 2013 11:43 AM
To: 'Radia Perlman'; Phanidhar Koganti
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: RE: [trill] New version : TRILL Smart Endnodes draft

Radia,

Questions inserted below:


a) When the packet reaches the egress RB I am presuming there will be a inner-MAC lookup to deliver the packet to the egress end-node.

correct...when egress RB R has to look up the inner MAC address E, which it has to do anyway without smart endnodes, in order to choose which port to forward it on.  With smart endnodes, when R looks up MAC address E, it not only discovers which port to send it on, but that E is "smart", in which case R must leave the TRILL encapsulation

[Linda] Why can't the egress RB R simply decapsulates the TRILL header and forward the data frame towards the attached end nodes? Regardless if the DA is smart node or not?
So RB processing is much simpler. It doesn't have to attach different Ethernet header based on the inner DA. The smart node can receive Ethernet frames anyway (for communication within the directly attached LAN).

Thanks, Linda