Re: [trill] Questions to TRILL Smart Endnodes draft

[Linda Dunbar <[e-mail]>]

Donald, 

Thanks for the explanation. 
Normally the Egress RBridge simply decapsulates the TRILL header and forward the "inner Ethernet frames" to its attached LAN. 

When there are  Smart endnodes attached to an RBridge, the behavior on RBridge is more like intermediate RBridge, less like Egress RBridge. 

Therefore, it may be more accurate to use the term "Slave RBridge", (i.e. a group of RBridges sharing their master's nickname) instead of smart "endnode". 

Linda

> -----Original Message-----
> From: Donald Eastlake [mailto:[e-mail]]
> Sent: Friday, January 11, 2013 4:47 PM
> To: Linda Dunbar
> Cc: Radia Perlman; [e-mail]; [e-mail];
> [e-mail]
> Subject: Re: [trill] Questions to TRILL Smart Endnodes draft
> 
> Hi Linda,
> 
> On Fri, Jan 11, 2013 at 4:00 PM, Linda Dunbar <[e-mail]>
> wrote:
> > Radia,
> >
> >
> > Thank you very much for the detailed description. Yes most of your
> > description are in the draft.
> >
> >
> > I am sorry for not stating my question clearly. What I want to ask is
> the
> > processing of Egress R receiving TRILL frames from the TRILL domain
> and
> > there are multiple End Nodes attached via the same physical port.  I
> don't
> > think it is described clearly in the draft.
> >
> >
> > Since multiple Smart Nodes on the LAN sharing the same Nickname,
> Egress node
> > has to add another layer Ethernet header before sending the data to
> the
> > correct Smart End node. Basically the inner Ethernet header has to be
> > repeated on the outer header (with all the header information, e.g.
> VLAN,
> > etc) in order for the frame to reach the correct Smart Node.
> 
> Assuming we are talking just about Ethernet links, TRILL switches
> normally change the outer MAC source and destination addresses and, if
> necessary, the outer VLAN label, on every hop. In this case, instead
> of setting the Outer.MacDA to the address of the next hop TRILL switch
> it copies the Inner.MacDA to the Outer.MacDA. I think it needs to to
> do this for unicast packets regardless of whether there is one Smart
> Endnode out a port or lots of them. I don't see how this is adding
> another layer of Ethernet header.
> 
> Thanks,
> Donald
> =============================
>  Donald E. Eastlake 3rd   [phone] (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  [e-mail]
> 
> > Linda
> >
> >
> >
> >
> >
> >
> >
> > From: Radia Perlman [mailto:[e-mail]]
> > Sent: Friday, January 11, 2013 2:38 PM
> > To: Linda Dunbar
> > Cc: [e-mail]; [e-mail];
> [e-mail];
> > [e-mail]
> >
> >
> > Subject: Re: [trill] Questions to TRILL Smart Endnodes draft
> >
> >
> >
> > I believe that the smart endnode draft already discusses that.  It
> considers
> > having a shared link that has any collection of smart and not smart
> > endnodes.
> >
> >
> >
> > Endnodes on that link will talk to each other using non-encapsulated
> frames,
> > whether or not they are smart endnodes.
> >
> >
> >
> > So for a few examples, let D1 and D2 be "not smart" endnodes, and S1
> and S2
> > be "smart" endnodes.  And let R be the attached RBridge.
> >
> >
> >
> > D1 and D2 always transmit and receive native (non-encapsulated).  If
> R does
> > not know where D2 is, then R might encapsulate and flood a packet D1
> sends
> > to D2, but once R learns (from seeing traffic from D2 on the link)
> that D2
> > is on the link, R will drop native packets it sees on the link with
> > destination D2.
> >
> >
> >
> > Now let S1 want to talk to D2.  (As stated in the draft), if S1 does
> not
> > know where D2 is, S1 must send two copies:
> >
> > 1) native on the link, in case D2 is there
> >
> > 2) encapsulated as a to-be-flooded packet to R, in case D2 is
> elsewhere on
> > the campus
> >
> >
> >
> > If D2 wants to talk to S1, D2 just sends it native, and S1 receives
> it just
> > fine (S1 has to be able to receive native as well as encapsulated
> packets).
> >
> >
> >
> > R drops the packet because S1 has informed R of all of the MAC
> addresses
> > that S1 owns.
> >
> >
> >
> > Now let's say S1 wants to talk to S2.  If S1 has received traffic
> from S2,
> > S1 will know that S2 is on the link, and will only send a single copy
> to S2;
> > a native copy.
> >
> >
> >
> >  If S1 does not know where S2 is, it sends two copies; one
> encapsulated, and
> > one native.  R has already learned S2's MAC addresses, so R knows it
> should
> > drop the packet.  S2, however, will receive two copies of the packet;
> one
> > native, and one encapsulated, and S2 will receive both of them.  But
> S2 will
> > learn that S1 is on the link, and when it sends something to S1, S1
> will
> > learn that S2 is on the link.
> >
> >
> >
> > So once in a blue moon, a smart endnode might receive two copies of a
> > packet, from another smart node on the link, until they learn about
> the
> > other one.  I suppose we could have the smart endnodes on the link
> listen to
> > the Hellos of other smart endnodes, in order to learn all the MAC
> addresses
> > on the link owned by smart endnodes, in order to avoid the
> > once-in-a-blue-moon receipt of a double packet, but I prefer not
> adding that
> > complexity.
> >
> >
> >
> > Radia
> >
> >
> >
> >
> >
> > On Fri, Jan 11, 2013 at 12:21 PM, Linda Dunbar
> <[e-mail]>
> > wrote:
> >
> > Radia,
> >
> >
> >
> > Questions inserted below:
> >
> >
> >
> > From: Radia Perlman [mailto:[e-mail]]
> > Sent: Wednesday, January 09, 2013 4:32 PM
> > To: Linda Dunbar
> > Cc: Phanidhar Koganti; [e-mail];
> [e-mail];
> > [e-mail]; [e-mail]
> > Subject: Re: [trill] Questions to TRILL Smart Endnodes draft
> >
> >
> >
> >
> >
> > If there is a smart endnode on a shared link with other endnodes, it
> learns
> > about its endnode neighbors, and sends directly to them (without
> > encapsulation).  If smart E wants to talk to unknown destination D, E
> has to
> > send two copies; one (without encapsulation), multicast on the link,
> and the
> > other (with encapsulation), forwarded to the attached RBridge R.
> >
> > [Linda] Agree
> >
> >
> >
> > R has been warned by E of all the MAC addresses E owns.  R must drop
> all
> > packets it receives on the link if either the source or destination
> MAC is
> > one of the ones owned by a smart endnode on the link.
> >
> >
> >
> > [Linda] What if multiple "smart endnode" sharing one link? For
> example,
> > there could be a bridge aggregating traffic from multiple end nodes
> (smart
> > and regular), or the multiple smart nodes as VMs sharing a physical
> server?
> >
> >
> >
> > 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
> >