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

[Donald Eastlake <[e-mail]>]

Maybe I should have used a TRILL Header extension as an example of
additional information that can be included by sending the TRILL Data
packet rather than egressing.

Some the latest messages in this thread are because all TRILL switches are
required to support VLANs but not necessarily fine grained labels. So if a
smart endnote wanted to use FGL TRILL Data frames and was connected to both
VL and FGL TRILL switches, it would want to know which was which.

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


On Thu, Jan 10, 2013 at 8:34 PM, Radia Perlman <[e-mail]>wrote:

> 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
>>>
>>>
>>
>