Re: [trill] Questions to TRILL Smart Endnodes draft

[Radia Perlman <[e-mail]>]

Actually, I wrote this too quickly (I really haven't had time to answer
carefully...still don't...but I want to correct one thing.  A smart endnode
would not receive two copies of the packet in the case I said.  All the
cases should work just fine.  When smart S1 is transmitting to S2, and S1
and S2 are on the same link, S2 will only receive the native copy from S1.
 The encapsulated one will only go to RB.

Radia

On Fri, Jan 11, 2013 at 12:37 PM, Radia Perlman <[e-mail]>wrote:

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