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

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

Maybe I have not made my meaning clear, so I try to make it clearer using 
an example. 

Assume E is an smartnode connected to TRILL campus through RB1. There are 
2,000 
RBridges in TRILL campus where 1,000 of them support FGL, and the 
remainder 1,000 
Rbridges do not support FGL. In this scenario, when E encapsulates a 
non-unicast 
frame into TRILL data frames with FGL and transmit in TRILL, it MUST know 
exactly 
which RBridges support FGL, then it has to TRILL unicast such a frame to 
all 
relevant egress RBridges (of the remainder 1,000 RBridges). Otherwise,if 
it does not
know the relevant egress RBridges, it has to employ a tree to multicast 
the frame. 
And that frame will be discarded by non-FGL RBridges and not able to reach 
the 
interested end nodes 

So if E wants to send TRILL Data packets(including multi-destination 
packets) with fine 
grained labels, it must learn which RBridges support FGL, which do not 
support FGL. 
Maybe RB1 can tell E the 1,000 FGL-RBridges by its hellos to E1 if Hello 
packet can
accommodate so many RBridges nicknames.

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: +86-25-52877345
 Email: zhai.hongjun@zte.com.cn
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""

Donald Eastlake <d3e3e3@gmail.com> 
2013-01-11 09:48

收件人
Radia Perlman <radiaperlman@gmail.com>
抄送
zhai.hongjun@zte.com.cn, "hu.fangwei@zte.com.cn" <hu.fangwei@zte.com.cn>, 
"Kesava_Vijaya_Krupak@Dell.com" <Kesava_Vijaya_Krupak@dell.com>, Linda 
Dunbar <linda.dunbar@huawei.com>, "trill@ietf.org" <trill@ietf.org>
主题
Re: [trill] New version : TRILL Smart Endnodes draft

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   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3@gmail.com

On Thu, Jan 10, 2013 at 8:34 PM, Radia Perlman <radiaperlman@gmail.com> 
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 <d3e3e3@gmail.com> 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   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3@gmail.com

On Thu, Jan 10, 2013 at 7:44 PM, <zhai.hongjun@zte.com.cn> 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: +86-25-52877345
Email: zhai.hongjun@zte.com.cn
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""

Donald Eastlake <d3e3e3@gmail.com> 
发件人:  trill-bounces@ietf.org 
2013-01-11 04:15 

收件人
Linda Dunbar <linda.dunbar@huawei.com> 
抄送
Radia Perlman <radiaperlman@gmail.com>, "Kesava_Vijaya_Krupak@Dell.com" <
Kesava_Vijaya_Krupak@dell.com>, "hu.fangwei@zte.com.cn" <
hu.fangwei@zte.com.cn>, "trill@ietf.org" <trill@ietf.org> 
主题
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
>>
>
_______________________________________________
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill