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

[Donald Eastlake <[e-mail]>]

Hi,

On Thu, Jan 10, 2013 at 9:32 PM, <[e-mail]> wrote:
>
> > 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

Under the current FGL draft, there is no data topology adjacency
between FGL and VL TRILL switches. So the distribution tree or trees
built by FGL TRILL switches will be bounded by the contiguous area of
FGL switches. Sending a multi-destination FGL TRILL Data frame on such
a tree will get to every FGL TRILL switch in that area without passing
through any VL TRILL switches. So flooding unknown unicast or using a
distribution tree for multicast should work fine.

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

> 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: [phone]
> Email: [e-mail]
> """""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
>
>
>
>
> Donald Eastlake <[e-mail]>
>
> 2013-01-11 09:48
>
> 收件人
> Radia Perlman <[e-mail]>
> 抄送
> [e-mail], "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, Linda Dunbar <[e-mail]>, "[e-mail]" <[e-mail]>
> 主题
> 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   [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
>
>
>
>