Re: [trill] Questions to TRILL Smart Endnodes draft

[Radia Perlman <[e-mail]>]

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