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

[Donald Eastlake <[e-mail]>]

Linda,

On Thu, Jan 10, 2013 at 3:56 PM, Linda Dunbar <[e-mail]> wrote:
> Donald,
>
> Can those "other TRILL data packet information" to be communicated to Smart node being carried by the special "Hello" message between RBridge and Smart nodes?

No. By "TRILL data packet information" I mean information tied to the
payload in the packet and which might vary from data packet to data
packet. Stuff in any "special Hello" or whatever other sort of control
packets there are seems appropriate for information related to the
state of the RBridge to Smart End node but not for information tied to
a data payload.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]

> Linda
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf
>> Of Donald Eastlake
>> Sent: Thursday, January 10, 2013 2:16 PM
>> To: Linda Dunbar
>> Cc: Radia Perlman; [e-mail]; [e-mail];
>> [e-mail]
>> Subject: 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   [phone] (cell)
>>  155 Beaver Street, Milford, MA 01757 USA
>>  [e-mail]
>>
>>
>> On Thu, Jan 10, 2013 at 1:24 PM, Radia Perlman <[e-mail]>
>> 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
>> <[e-mail]>
>> > 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: [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
>> >>
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> trill mailing list
>> >> [e-mail]
>> >> https://www.ietf.org/mailman/listinfo/trill
>> >>
>> >
>> _______________________________________________
>> trill mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/trill
> _______________________________________________
> trill mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/trill