Re: [trill] Questions to TRILL Smart Endnodes draft

Hi Linda,

On Fri, Jan 11, 2013 at 4:00 PM, Linda Dunbar <linda.dunbar@huawei.com> 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   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3@gmail.com

> Linda
>
>
>
>
>
>
>
> From: Radia Perlman [mailto:radiaperlman@gmail.com]
> Sent: Friday, January 11, 2013 2:38 PM
> To: Linda Dunbar
> Cc: d3e3e3@gmail.com; Kesava_Vijaya_Krupak@Dell.com; hu.fangwei@zte.com.cn;
> trill@ietf.org
>
>
> 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 <linda.dunbar@huawei.com>
> wrote:
>
> Radia,
>
>
>
> Questions inserted below:
>
>
>
> From: Radia Perlman [mailto:radiaperlman@gmail.com]
> Sent: Wednesday, January 09, 2013 4:32 PM
> To: Linda Dunbar
> Cc: Phanidhar Koganti; d3e3e3@gmail.com; Kesava_Vijaya_Krupak@Dell.com;
> hu.fangwei@zte.com.cn; trill@ietf.org
> 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
> trill@ietf.org
> https://www.ietf.org/mailman/listinfo/trill
>
>
>
>
> _______________________________________________
> trill mailing list
> trill@ietf.org
> https://www.ietf.org/mailman/listinfo/trill
>