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

The reason RB has to leave it encapsulated when forwarding to a smart
endnode is for the case where the smart endnode will be learning
(destination MAC, egress nickname) from received traffic.

Radia

On Thu, Jan 10, 2013 at 9:42 AM, Linda Dunbar <linda.dunbar@huawei.com>wrote:

>  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****
>
> ** **
>
> _______________________________________________
> trill mailing list
> trill@ietf.org
> https://www.ietf.org/mailman/listinfo/trill
>
>