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

[Linda Dunbar <[e-mail]>]

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?

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