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

[Radia Perlman <[e-mail]>]

OK.  I've gotten confused here.  If a packet needs an FGL, and it is being
encapsulated by a smart endnode, the smart endnode needs to put on the FGL,
just like it would need to put on a VLAN.

So I'm not sure what the last 4 or 5 messages in the thread are about.

Radia



On Thu, Jan 10, 2013 at 5:23 PM, Donald Eastlake <[e-mail]> wrote:

> I believe FGL support should be announced in Hellos.
>
> I think the main reason for an end station to want to receive/send FGL
> TRILL Data packets is because it wants to handle data packets with a very
> large number of different labels. This strikes me as a bit unusual,
> probably a large gateway or server, so the network would normally be
> configured so that the TRILL switches it is connected with support FGL.
>
> Thanks,
> Donald
> =============================
>  Donald E. Eastlake 3rd   [phone] (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  [e-mail]
>
>
> On Thu, Jan 10, 2013 at 7:44 PM, <[e-mail]> wrote:
>
>>
>> Hi Donald,
>>
>> > 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.
>>
>> As smartnodes have no Link State Database information for TRILL campus,
>> they do not know whether all the RBridges in TRILL campus support FGL
>> or not, or which RBridges support FGL and which does not support FGL.
>> Therefore, if a smartnode sends TRILL multi-destination data packets
>> with FGL, the packets might be discarded by some RBridgs that do not
>> support FGL. In this case, how such a sartnode makes sure those FGL
>> packets are able to arrive at their destination(s)?
>>
>>
>>
>> Best Regards,
>> Zhai Hongjun
>> """"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
>> Protocol Development Dept.VI, Central R&D Institute, ZTE Corporation
>> No. 68, Zijinghua Road, Yuhuatai District, Nanjing, P.R.China, 210012
>>
>> Zhai Hongjun
>>
>> Tel: [phone]
>> Email: [e-mail]
>> """""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
>>
>>
>>
>>
>>  *Donald Eastlake <[e-mail]>*
>> 发件人:  [e-mail]
>>
>> 2013-01-11 04:15
>>   收件人
>> Linda Dunbar <[e-mail]>
>> 抄送
>> Radia Perlman <[e-mail]>, "[e-mail]" <
>> [e-mail]>, "[e-mail]" <
>> [e-mail]>, "[e-mail]" <[e-mail]>
>> 主题
>> 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
>>
>>
>