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

There may also be reasons to communicate other TRILL Data packet
information with the smart end node, besides the ingress nickname
needed for learning. For example, a smart end node might want to be
able to send and receive TRILL Data packets with fine grained labels.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3@gmail.com

On Thu, Jan 10, 2013 at 1:24 PM, Radia Perlman <radiaperlman@gmail.com> wrote:
> Yes, it's simpler, but it doesn't work, unless we want to say that smart
> endnodes can never learn from data traffic...they can only work if they are
> configured with (MAC, egress nickname) of all destinations they might want
> to talk to, or must have a directory and request from the directory.
>
> I think we need to allow smart endnodes to learn from data traffic, in
> which, unfortunately (because as you point out, it's more complicated) the
> RB has to consciously know whether it's forwarding to a smart endnode or
> not, and then leave it encapsulated in that case.
>
> Radia
>
> On Thu, Jan 10, 2013 at 10:03 AM, Linda Dunbar <linda.dunbar@huawei.com>
> wrote:
>>
>> 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: d3e3e3@gmail.com; Kesava_Vijaya_Krupak@Dell.com;
>> hu.fangwei@zte.com.cn; trill@ietf.org
>> 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
>>
>>
>>
>>
>> _______________________________________________
>> trill mailing list
>> trill@ietf.org
>> https://www.ietf.org/mailman/listinfo/trill
>>
>