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

From: <[email-masked]>
Date: Thu, 3 Jan 2013 16:18:42 +0530

Hi all,

A new version of the Trill Smart Endnodes draft has been posted.

http://datatracker.ietf.org/doc/draft-perlman-trill-smart-endnodes

Kindly let us know your comments.

Thanks,
kvk

---

From: Phanidhar Koganti <[email-masked]>
Date: Thu, 3 Jan 2013 03:19:45 -0800

The draft defines the control and data path behavior from smart end-node to edge-RB. 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. Edge-RB to smart endnode cannot have TRILL encapsulation right? If so for my clarification we are saying the traffic towards the end-node will be non-TRILL while towards the ingress edge-RB will be TRILL encapsulated?

Phani

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, January 03, 2013 4:19 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: [trill] New version : TRILL Smart Endnodes draft

Hi all,

Thanks,
kvk

---

From: Radia Perlman <[email-masked]>
Date: Tue, 8 Jan 2013 13:23:25 -0800

Most of what you said is correct.  One correction

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

b) Edge-RB to smart endnode cannot have TRILL encapsulation right?

Not correct.  Traffic from egress RB to smart endnode will have TRILL
encapsulation.  So for example, let's say R is the egress RB, and R has a
link with two endnodes; E1 (which is smart) and E2 (which is not smart).

When R receives a TRILL packet from the campus, with TRILL destination
nickname=R, R looks at the MAC destination.  If it is E2, then R removes
the TRILL encapulation and forwards a native packet onto the link.  If it
is E1, then R forwards the packet with the TRILL header.

c) Edge-RB to smart endnode cannot have TRILL encapsulation right? If so
for my clarification we are saying the traffic towards the end-node will be
non-TRILL while towards the ingress edge-RB will be TRILL encapsulated?

Hopefully my answer to b) clarified this.  On the link between endnodes and
R, whether it's to or from endnode <--> edge RB, the packet will have TRILL
encapsulation if the endnode is smart, and not have TRILL encapsulation if
the endnode is not smart.

Radia

On Thu, Jan 3, 2013 at 3:19 AM, Phanidhar Koganti <[email-masked]>wrote:

> The draft defines the control and data path behavior from smart end-node
> to edge-RB. 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. Edge-RB
> to smart endnode cannot have TRILL encapsulation right? If so for my
> clarification we are saying the traffic towards the end-node will be
> non-TRILL while towards the ingress edge-RB will be TRILL encapsulated?***
> *
>
> ** **
>
> Phani****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of [email-masked]
> *Sent:* Thursday, January 03, 2013 4:19 PM
> *To:* [email-masked]
> *Cc:* [email-masked]; [email-masked]; [email-masked]
> *Subject:* [trill] New version : TRILL Smart Endnodes draft****
>
> ** **
>
> Hi all,****
>
> ** **
>
> A new version of the Trill Smart Endnodes draft has been posted.****
>
> ** **
>
> http://datatracker.ietf.org/doc/draft-perlman-trill-smart-endnodes****
>
> ** **
>
> Kindly let us know your comments.****
>
> ** **
>
> Thanks,****
>
> kvk****
>

---

From: Phanidhar Koganti <[email-masked]>
Date: Tue, 8 Jan 2013 20:32:40 -0800

Thanks Radia. That clarifies for me. A more descriptive text in draft can surely help vendors as they implement it in their hardware.

Another question on handling multi-homing
E can choose either R1 or R2's nickname, when encapsulating a
       frame, whether the encapsulated frame is sent via R1 or R2. If E
       wants to do active-active load splitting, and uses R1's nickname
       when forwarding through R1, and R2's nickname when forwarding
       through R2, this will cause distant RBridges (or smart endnodes)
       to keep changing their endnode table entry for D between (D, R1's
       nickname) and (D, R2's nickname). So it would be preferable for E
       to always encapsulate using the same nickname (R1 or R2) unless E
       detects a problem with connectivity using that nickname. And in
       this case, R1 and R2 need to be informed that the smart endnode
       might encapsulate with a different nickname, i.e., R1 might
       receive an encapsulated packet from smart endnode E using ingress
       nickname "R2".

If the smart endnode uses either R1 or R2 in the above example, would we have TRILL RPF issues where upstream RBs see a packet with SRB=say R1 coming from a wrong TRILL port? Let's say the RPF happens for multicast only then we will atleast need to make sure the multicast (broadcast, unknown unicast and multcast) is sent via the edge-RB whose RBID the smart endnode is using.

This problem should not be there when using different RBID other than R1 and R2 as described in approach-2

Phani
From: Radia Perlman [mailto:[email-masked]]
Sent: Wednesday, January 09, 2013 2:53 AM
To: Phanidhar Koganti
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: New version : TRILL Smart Endnodes draft

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

Not correct.  Traffic from egress RB to smart endnode will have TRILL encapsulation.  So for example, let's say R is the egress RB, and R has a link with two endnodes; E1 (which is smart) and E2 (which is not smart).

When R receives a TRILL packet from the campus, with TRILL destination nickname=R, R looks at the MAC destination.  If it is E2, then R removes the TRILL encapulation and forwards a native packet onto the link.  If it is E1, then R forwards the packet with the TRILL header.

c) Edge-RB to smart endnode cannot have TRILL encapsulation right? If so for my clarification we are saying the traffic towards the end-node will be non-TRILL while towards the ingress edge-RB will be TRILL encapsulated?

Hopefully my answer to b) clarified this.  On the link between endnodes and R, whether it's to or from endnode <--> edge RB, the packet will have TRILL encapsulation if the endnode is smart, and not have TRILL encapsulation if the endnode is not smart.

Radia

On Thu, Jan 3, 2013 at 3:19 AM, Phanidhar Koganti <[email-masked]<mailto:[email-masked]>> wrote:
The draft defines the control and data path behavior from smart end-node to edge-RB. 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. Edge-RB to smart endnode cannot have TRILL encapsulation right? If so for my clarification we are saying the traffic towards the end-node will be non-TRILL while towards the ingress edge-RB will be TRILL encapsulated?

Phani

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Thursday, January 03, 2013 4:19 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [trill] New version : TRILL Smart Endnodes draft

Hi all,

Thanks,
kvk

---

From: Radia Perlman <[email-masked]>
Date: Tue, 8 Jan 2013 22:21:33 -0800

Good point (see Phani's comment below).  I'll summarize:

The current  text implies that it's OK for smart endnode E, multihomed to
R1 and R2, to choose one of the nicknames (say R1) for "ingress nickname"
in the TRILL header, and forward to either R1 or R2.  There are two
problems with E forwarding a TRILL-encapsulated frame using ingeress "R1",
through R2:

a) for multicast, likely to confuse the RPF check
b) for unicast, E would probably need to warn R2 that E is multihomed to R1
and will e using R1's nickname for ingress.

And actually, E won't get that much load splitting benefit from being
multihomed if it uses "R1" as ingress, since all traffic to E will go
through R1.  So, if E doesn't have a pseudonode nickname to use, then
perhaps E should just use one R1 or R2.

Or E could get its own nickname (I've been floating around the idea of a
"dumb RBridge", which is like a "smart endnode", except it gets its own
nickname, and does generate an LSP with "overloaded" flag.  It probably has
to receive LSPs and calculate Dijkstra, in order to know which port to send
multicast on (unless its attached true RBs are helpful enough to tell
it..."you can send multicast with trees X or Y through me")

So, it seems like there are several options which should be discussed, for
a smart endnode multihomed to R1 and R2
1) Always use a pseudnode nickname (but that's kind of complicated since
that nickname can only be used by smart endnodes that are multihomed to the
exact same set of RBridges)
2) Don't do active-active...choose one or R1 or R2 and always send
everything that way
3) Do active-active, but only for unicast...choose one of the nicknames,
say "R1", and it's OK to send unicast either through R1 or R2, but
multicast has to go through R1
4) Give E its own nickname (and somehow make sure it knows which port it
can multicast on)
5) Other possibilities?

Radia

On Tue, Jan 8, 2013 at 8:32 PM, Phanidhar Koganti <[email-masked]>wrote:

> Thanks Radia. That clarifies for me. A more descriptive text in draft can
> surely help vendors as they implement it in their hardware.****
>
> ** **
>
> Another question on handling multi-homing****
>
> E can choose either R1 or R2's nickname, when encapsulating a****
>
>        frame, whether the encapsulated frame is sent via R1 or R2. If E***
> *
>
>        wants to do active-active load splitting, and uses R1's nickname***
> *
>
>        when forwarding through R1, and R2's nickname when forwarding****
>
>        through R2, this will cause distant RBridges (or smart endnodes)***
> *
>
>        to keep changing their endnode table entry for D between (D, R1's**
> **
>
>        nickname) and (D, R2's nickname). So it would be preferable for E**
> **
>
>        to always encapsulate using the same nickname (R1 or R2) unless E**
> **
>
>        detects a problem with connectivity using that nickname. And in****
>
>        this case, R1 and R2 need to be informed that the smart endnode****
>
>        might encapsulate with a different nickname, i.e., R1 might****
>
>        receive an encapsulated packet from smart endnode E using ingress**
> **
>
>        nickname "R2".****
>
> ** **
>
> If the smart endnode uses either R1 or R2 in the above example, would we
> have TRILL RPF issues where upstream RBs see a packet with SRB=say R1
> coming from a wrong TRILL port? Let’s say the RPF happens for multicast
> only then we will atleast need to make sure the multicast (broadcast,
> unknown unicast and multcast) is sent via the edge-RB whose RBID the smart
> endnode is using.****
>
> ** **
>
> This problem should not be there when using different RBID other than R1
> and R2 as described in approach-2****
>
> ** **
>
> Phani****
>
> *From:* Radia Perlman [mailto:[email-masked]]
> *Sent:* Wednesday, January 09, 2013 2:53 AM
> *To:* Phanidhar Koganti
> *Cc:* [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> *Subject:* Re: New version : TRILL Smart Endnodes draft****
>
> ** **
>
> Most of what you said is correct.  One correction****
>
> ** **
>
> 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****
>
> ** **
>
> b) Edge-RB to smart endnode cannot have TRILL encapsulation right?****
>
> ** **
>
> link with two endnodes; E1 (which is smart) and E2 (which is not smart).**
> **
>
> ** **
>
> is E1, then R forwards the packet with the TRILL header.****
>
> ** **
>
> Hopefully my answer to b) clarified this.  On the link between endnodes
> and R, whether it's to or from endnode <--> edge RB, the packet will have
> TRILL encapsulation if the endnode is smart, and not have TRILL
> encapsulation if the endnode is not smart.****
>
> ** **
>
> Radia****
>
> ** **
>
> ** **
>
> On Thu, Jan 3, 2013 at 3:19 AM, Phanidhar Koganti <[email-masked]>
> wrote:****
>
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****

---

From: Phanidhar Koganti <[email-masked]>
Date: Wed, 9 Jan 2013 00:24:46 -0800

Radia,

Valid point for unicast that the pair in the example needs to be aware that it might get unicast traffic with TRILL Source RBID equal to its RBID. This brings up an interesting scenario.

Let's say there are two smart end-nodes e1 & e2 which are both multi-homed behind R1 & R2. Also say both e1 & e2 pick R1 to use in TRILL source RBID, then when e1 is talking to e2 we end up in a encap where both TRILL SA/DA will have the same value = R1.

I am inclined towards a pseudo RB for the end-node with its own nickname, but am not clear on the impact on Dijkstra as the number of routable RBIDs will considerably go up.

Few additional concerns:

For multicast it will also trigger confusion on source suppression that needs to happen in the peer RB. Let's say there is a smart end-node e1 & e2 multi-homed behind R1 and R2. For multicast or flooded traffic we need source suppression so that the traffic does not go back to the smart endnode. Or is the draft assuming that the smart end-node will perform the suppression if the packet comes back to it?

Also for the packet direction edge-RB to smart end-node, if we end up with unknown MAC then we should flood to all the locally hanging smart end-nodes and regular end-nodes. When flooding towards smart end-nodes are we expected to continue the TRILL packet with M=0 or convert it to M=1 with T_DA=ROOT. If we like to continue with M=0 then the edge-RB needs to support unicast replication for multicast.

Phani

From: Radia Perlman [mailto:[email-masked]]
Sent: Wednesday, January 09, 2013 11:52 AM
To: Phanidhar Koganti
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: New version : TRILL Smart Endnodes draft

The current  text implies that it's OK for smart endnode E, multihomed to R1 and R2, to choose one of the nicknames (say R1) for "ingress nickname" in the TRILL header, and forward to either R1 or R2.  There are two problems with E forwarding a TRILL-encapsulated frame using ingeress "R1", through R2:

a) for multicast, likely to confuse the RPF check
b) for unicast, E would probably need to warn R2 that E is multihomed to R1 and will e using R1's nickname for ingress.

And actually, E won't get that much load splitting benefit from being multihomed if it uses "R1" as ingress, since all traffic to E will go through R1.  So, if E doesn't have a pseudonode nickname to use, then perhaps E should just use one R1 or R2.

Or E could get its own nickname (I've been floating around the idea of a "dumb RBridge", which is like a "smart endnode", except it gets its own nickname, and does generate an LSP with "overloaded" flag.  It probably has to receive LSPs and calculate Dijkstra, in order to know which port to send multicast on (unless its attached true RBs are helpful enough to tell it..."you can send multicast with trees X or Y through me")

So, it seems like there are several options which should be discussed, for a smart endnode multihomed to R1 and R2
1) Always use a pseudnode nickname (but that's kind of complicated since that nickname can only be used by smart endnodes that are multihomed to the exact same set of RBridges)
2) Don't do active-active...choose one or R1 or R2 and always send everything that way
3) Do active-active, but only for unicast...choose one of the nicknames, say "R1", and it's OK to send unicast either through R1 or R2, but multicast has to go through R1
4) Give E its own nickname (and somehow make sure it knows which port it can multicast on)
5) Other possibilities?

Radia

On Tue, Jan 8, 2013 at 8:32 PM, Phanidhar Koganti <[email-masked]<mailto:[email-masked]>> wrote:
Thanks Radia. That clarifies for me. A more descriptive text in draft can surely help vendors as they implement it in their hardware.

Phani
From: Radia Perlman [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, January 09, 2013 2:53 AM
To: Phanidhar Koganti
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: New version : TRILL Smart Endnodes draft

Radia

Phani

Hi all,

Thanks,
kvk

---

From: Radia Perlman <[email-masked]>
Date: Wed, 9 Jan 2013 00:36:20 -0800

Hmm.  Interesting example...

Let's first ignore multihoming, and assuming that two smart endnodes, E1
and E2, are both connected to R1.  I think the case works where E1 and E2
are on the same shared link...they will learn that the other can be reached
directly, and talk to each other without TRILL encapsulation.

But let's consider the case where E1 and E2 are both singly homed to R, but
using different ports.  Then they will have to talk to each other with
TRILL encapsulation with both ingress and egress nickname=R1.  That's a bit
weird, but I think it works.  Does it?

-------
As for multicast showing up twice...it shouldn't...only one RB should be
attached to a link with an endnode via any particular tree, so I think only
one copy of a multicast packet should be delivered.

--------
As for having each smart endnode use its own nickname...the real problem is
nickname exhaustion (running out of nicknames).  There's only 64K
nicknames, unless we do the multilevel thing where nicknames only need to
be unique within an area, but the RBs that forward between level 1 and
level 2 have to rewrite the nickname fields.

----
As for unknown destinations/learning...I thought we considered that.  But
smart endnodes will not be unknown to the attached RB...they explicitly
announce themselves.

Radia

On Wed, Jan 9, 2013 at 12:24 AM, Phanidhar Koganti <[email-masked]>wrote:

> Radia,****
>
> ** **
>
> Valid point for unicast that the pair in the example needs to be aware
> that it might get unicast traffic with TRILL Source RBID equal to its RBID.
> This brings up an interesting scenario. ****
>
> ** **
>
> Let’s say there are two smart end-nodes e1 & e2 which are both multi-homed
> behind R1 & R2. Also say both e1 & e2 pick R1 to use in TRILL source RBID,
> then when e1 is talking to e2 we end up in a encap where both TRILL SA/DA
> will have the same value = R1.****
>
> ** **
>
> I am inclined towards a pseudo RB for the end-node with its own nickname,
> but am not clear on the impact on Dijkstra as the number of routable RBIDs
> will considerably go up. ****
>
> ** **
>
> Few additional concerns:****
>
> ** **
>
> For multicast it will also trigger confusion on source suppression that
> needs to happen in the peer RB. Let’s say there is a smart end-node e1 & e2
> multi-homed behind R1 and R2. For multicast or flooded traffic we need
> source suppression so that the traffic does not go back to the smart
> endnode. Or is the draft assuming that the smart end-node will perform the
> suppression if the packet comes back to it? ****
>
> ** **
>
> Also for the packet direction edge-RB to smart end-node, if we end up with
> unknown MAC then we should flood to all the locally hanging smart end-nodes
> and regular end-nodes. When flooding towards smart end-nodes are we
> expected to continue the TRILL packet with M=0 or convert it to M=1 with
> T_DA=ROOT. If we like to continue with M=0 then the edge-RB needs to
> support unicast replication for multicast.****
>
> ** **
>
> Phani****
>
> ** **
>
> *Sent:* Wednesday, January 09, 2013 11:52 AM
>
> *To:* Phanidhar Koganti
> Good point (see Phani's comment below).  I'll summarize:****
>
> ** **
>
> through R2:****
> a) for multicast, likely to confuse the RPF check****
>
> b) for unicast, E would probably need to warn R2 that E is multihomed to
> R1 and will e using R1's nickname for ingress.****
>
> ** **
>
> perhaps E should just use one R1 or R2.****
>
> ** **
>
> it..."you can send multicast with trees X or Y through me")****
>
> ** **
>
> a smart endnode multihomed to R1 and R2****
>
> exact same set of RBridges)****
>
> everything that way****
> multicast has to go through R1****
>
> can multicast on)****
> 5) Other possibilities?****
>
> ** **
>
> Radia****
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> On Tue, Jan 8, 2013 at 8:32 PM, Phanidhar Koganti <[email-masked]>
> wrote:****
>

---

From: Phanidhar Koganti <[email-masked]>
Date: Wed, 9 Jan 2013 00:47:02 -0800

Inline

From: Radia Perlman [mailto:[email-masked]]
Sent: Wednesday, January 09, 2013 2:06 PM
To: Phanidhar Koganti
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: New version : TRILL Smart Endnodes draft

Let's first ignore multihoming, and assuming that two smart endnodes, E1 and E2, are both connected to R1.  I think the case works where E1 and E2 are on the same shared link...they will learn that the other can be reached directly, and talk to each other without TRILL encapsulation.

But let's consider the case where E1 and E2 are both singly homed to R, but using different ports.  Then they will have to talk to each other with TRILL encapsulation with both ingress and egress nickname=R1.  That's a bit weird, but I think it works.  Does it?
[Phanidhar Koganti] We can make it work :). It sounds weird so will need to put more thought....

-------
As for multicast showing up twice...it shouldn't...only one RB should be attached to a link with an endnode via any particular tree, so I think only one copy of a multicast packet should be delivered.
[Phanidhar Koganti] Got you, so the link is chosen on a tree basis and not like a LAG where each side picks the link for multicast without coordination with remote.

--------
As for having each smart endnode use its own nickname...the real problem is nickname exhaustion (running out of nicknames).  There's only 64K nicknames, unless we do the multilevel thing where nicknames only need to be unique within an area, but the RBs that forward between level 1 and level 2 have to rewrite the nickname fields.
[Phanidhar Koganti] Yes the nickname space can be localized to an area and the need for nickname rewrites will come into picture for very large scale deployments and can potentially be justified.

----
As for unknown destinations/learning...I thought we considered that.  But smart endnodes will not be unknown to the attached RB...they explicitly announce themselves.
[Phanidhar Koganti] Agree if smart endnodes are always known we are good.

Radia

On Wed, Jan 9, 2013 at 12:24 AM, Phanidhar Koganti <[email-masked]<mailto:[email-masked]>> wrote:
Radia,

Few additional concerns:

Phani

To: Phanidhar Koganti

Radia

Phani

Radia

Phani

Hi all,

Thanks,
kvk

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 9 Jan 2013 20:55:32 +0000

Radia, et al,

The draft states that Smart End Node does both TRILL encapsulation and Decapsulation.
When there are multiple end nodes attached to one RBridge, this one RBridge is the egress node for data frames  to all those end nodes.
If the RBridge doesn't decapsulate the TRILL header, how does it send the data frame to the correct end node?

https://datatracker.ietf.org/doc/draft-dunbar-trill-directory-assisted-encap/ describes another type of smart node which only encapsulates TRILL header when sending data frames to remote nodes (i.e. attached to different RBridges). All RBridges decapsulate TRILL header for data frames received from TRILL domain and towards directly attached end nodes, so that the data frames can be forwarded by Ethernet destination address. Do you think this approach will work?

Thanks, Linda

From: [email-masked] [mailto:[email-masked]] On Behalf Of Radia Perlman
Sent: Wednesday, January 09, 2013 12:22 AM
To: Phanidhar Koganti
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [trill] New version : TRILL Smart Endnodes draft

Radia

Phani
From: Radia Perlman [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, January 09, 2013 2:53 AM
To: Phanidhar Koganti
Cc: [email-masked]; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: New version : TRILL Smart Endnodes draft

Radia

Phani

Hi all,

Thanks,
kvk

---

From: Radia Perlman <[email-masked]>
Date: Wed, 9 Jan 2013 14:31:59 -0800

I think that's in the smart endnode draft. I hope it is (I'll have to
reread it).  But it was certainly discussed in email.

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.

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.

Radia

On Wed, Jan 9, 2013 at 12:55 PM, Linda Dunbar <[email-masked]>wrote:

>  Radia, et al, ****
>
> ** **
>
> The draft states that Smart End Node does both TRILL encapsulation and
> Decapsulation. ****
>
> When there are multiple end nodes attached to one RBridge, this one
> RBridge is the egress node for data frames  to all those end nodes.  ****
>
> If the RBridge doesn’t decapsulate the TRILL header, how does it send the
> data frame to the correct end node? ****
>
> ** **
>
>
> https://datatracker.ietf.org/doc/draft-dunbar-trill-directory-assisted-encap/ describes
> another type of smart node which only encapsulates TRILL header when
> sending data frames to remote nodes (i.e. attached to different RBridges).
> All RBridges decapsulate TRILL header for data frames received from TRILL
> domain and towards directly attached end nodes, so that the data frames can
> be forwarded by Ethernet destination address. Do you think this approach
> will work?****
>
> ** **
>
> Thanks, Linda****
>
> ** **
>
> ** **
>
> Of *Radia Perlman
> *Sent:* Wednesday, January 09, 2013 12:22 AM
> *To:* Phanidhar Koganti
> *Cc:* [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> *Subject:* Re: [trill] New version : TRILL Smart Endnodes draft****
>
> ** **
>
> _______________________________________________
> trill mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trill
>
>

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 10 Jan 2013 17:42:38 +0000

Radia,

Questions inserted below:

[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

---

From: Radia Perlman <[email-masked]>
Date: Thu, 10 Jan 2013 09:54:07 -0800

The reason RB has to leave it encapsulated when forwarding to a smart
endnode is for the case where the smart endnode will be learning
(destination MAC, egress nickname) from received traffic.

Radia

On Thu, Jan 10, 2013 at 9:42 AM, Linda Dunbar <[email-masked]>wrote:

>  Radia, ****
>
> ** **
>
> Questions inserted below:****
>
> ** **
>
> ** **
>
> [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****
>
> ** **
>

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 10 Jan 2013 18:03:07 +0000

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: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [trill] New version : TRILL Smart Endnodes draft

Radia,

Thanks, Linda

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 10 Jan 2013 18:18:41 +0000

Radia,

It would be much simpler to let the egress RBridge send a freshly learned mapping to the Smart node when decapsulating a TRILL frame. By doing so, the (egress) RBridge doesn't have make any change to its current learning processing
If the RBridge can't keep up all the learned mapping due to massive number of end nodes, the egress RBridge doesn't  have to cache the mapping (or set the timer for the cache very small).

You can use the Hello message between RBridge and smart node to carry this mapping information.

Alternatively, let the Smart Node be assisted by Directory Servers, which makes lot of sense in Data Center environment.

Linda

From: Radia Perlman [mailto:[email-masked]]
Sent: Thursday, January 10, 2013 11:54 AM
To: Linda Dunbar
Cc: Phanidhar Koganti; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [trill] New version : TRILL Smart Endnodes draft

The reason RB has to leave it encapsulated when forwarding to a smart endnode is for the case where the smart endnode will be learning (destination MAC, egress nickname) from received traffic.

Radia
On Thu, Jan 10, 2013 at 9:42 AM, Linda Dunbar <[email-masked]<mailto:[email-masked]>> wrote:
Radia,

Thanks, Linda

_______________________________________________
trill mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/trill

---

From: Radia Perlman <[email-masked]>
Date: Thu, 10 Jan 2013 10:24:02 -0800

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 <[email-masked]>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
> *Subject:* RE: [trill] New version : TRILL Smart Endnodes draft****
>
> ** **
>
> Radia, ****
>
> ** **
>

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 10 Jan 2013 15:15:46 -0500

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   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

On Thu, Jan 10, 2013 at 1:24 PM, Radia Perlman <[email-masked]> wrote:
>> 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
>> it has to do anyway without smart endnodes, in order to choose which port to
>> is smart node or not?
>> frames anyway (for communication within the directly attached LAN).
>>
>>
>>
>> Thanks, Linda
>>
>>
>>
>>

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 10 Jan 2013 20:56:34 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf
> Of Donald Eastlake
> Sent: Thursday, January 10, 2013 2:16 PM
> To: Linda Dunbar
> Cc: Radia Perlman; [email-masked]; [email-masked];
> [email-masked]
> > On Thu, Jan 10, 2013 at 10:03 AM, Linda Dunbar
> <[email-masked]>
> > wrote:
> >>
> >> *        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
> >>
> >> *        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
> >> [Linda] Why can't the egress RB R simply decapsulates the TRILL
> header and
> >> So RB processing is much simpler. It doesn't have to attach
> different

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 10 Jan 2013 16:21:50 -0500

Linda,

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

No. By "TRILL data packet information" I mean information tied to the
payload in the packet and which might vary from data packet to data
packet. Stuff in any "special Hello" or whatever other sort of control
packets there are seems appropriate for information related to the
state of the RBridge to Smart End node but not for information tied to
a data payload.

Thanks,
Donald

---

From: [email-masked]
Date: Fri, 11 Jan 2013 08:44:46 +0800

Hi Donald,

> able to send and receive TRILL Data packets with fine grained labels.

As smartnodes have no Link State Database information for TRILL campus, 
they do not know whether all the RBridges in TRILL campus support FGL 
or not, or which RBridges support FGL and which does not support FGL.
Therefore, if a smartnode sends TRILL multi-destination data packets 
with FGL, the packets might be discarded by some RBridgs that do not 
support FGL. In this case, how such a sartnode makes sure those FGL 
packets are able to arrive at their destination(s)?

Best Regards,
Zhai Hongjun
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
 Protocol Development Dept.VI, Central R&D Institute, ZTE Corporation
 No. 68, Zijinghua Road, Yuhuatai District, Nanjing, P.R.China, 210012
 
 Zhai Hongjun
 
 Tel: +86-25-52877345
 Email: [email-masked]
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""

Donald Eastlake <[email-masked]> 
发件人:  [email-masked]
2013-01-11 04:15

收件人
Linda Dunbar <[email-masked]>
抄送
Radia Perlman <[email-masked]>, "[email-masked]" 
<[email-masked]>, "[email-masked]" 
<[email-masked]>, "[email-masked]" <[email-masked]>
主题
Re: [trill] New version : TRILL Smart Endnodes draft

Thanks,
Donald

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 10 Jan 2013 20:23:24 -0500

I believe FGL support should be announced in Hellos.

I think the main reason for an end station to want to receive/send FGL
TRILL Data packets is because it wants to handle data packets with a very
large number of different labels. This strikes me as a bit unusual,
probably a large gateway or server, so the network would normally be
configured so that the TRILL switches it is connected with support FGL.

Thanks,
Donald

On Thu, Jan 10, 2013 at 7:44 PM, <[email-masked]> wrote:

>  *Donald Eastlake <[email-masked]>*
> Radia Perlman <[email-masked]>, "[email-masked]" <
> [email-masked]>, "[email-masked]" <
> [email-masked]>, "[email-masked]" <[email-masked]>
> 主题
> >> ・        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

---

From: Radia Perlman <[email-masked]>
Date: Thu, 10 Jan 2013 17:34:41 -0800

OK.  I've gotten confused here.  If a packet needs an FGL, and it is being
encapsulated by a smart endnode, the smart endnode needs to put on the FGL,
just like it would need to put on a VLAN.

So I'm not sure what the last 4 or 5 messages in the thread are about.

Radia

On Thu, Jan 10, 2013 at 5:23 PM, Donald Eastlake <[email-masked]> wrote:

>> > On Thu, Jan 10, 2013 at 10:03 AM, Linda Dunbar <[email-masked]
>> >
>> > wrote:
>> >>

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 10 Jan 2013 20:48:09 -0500

Maybe I should have used a TRILL Header extension as an example of
additional information that can be included by sending the TRILL Data
packet rather than egressing.

Some the latest messages in this thread are because all TRILL switches are
required to support VLANs but not necessarily fine grained labels. So if a
smart endnote wanted to use FGL TRILL Data frames and was connected to both
VL and FGL TRILL switches, it would want to know which was which.

Thanks,
Donald

On Thu, Jan 10, 2013 at 8:34 PM, Radia Perlman <[email-masked]>wrote:

>>> <[email-masked]>, "[email-masked]" <
>>> > On Thu, Jan 10, 2013 at 10:03 AM, Linda Dunbar <
>>> [email-masked]>
>>> > wrote:
>>> >>

---

From: [email-masked]
Date: Fri, 11 Jan 2013 10:32:32 +0800

> Some the latest messages in this thread are because all TRILL switches 
are required to 
> support VLANs but not necessarily fine grained labels. So if a smart 
endnote wanted to 
> use FGL TRILL Data frames and was connected to both VL and FGL TRILL 
switches, it would 
> want to know which was which.

Maybe I have not made my meaning clear, so I try to make it clearer using 
an example. 

Assume E is an smartnode connected to TRILL campus through RB1. There are 
2,000 
RBridges in TRILL campus where 1,000 of them support FGL, and the 
remainder 1,000 
Rbridges do not support FGL. In this scenario, when E encapsulates a 
non-unicast 
frame into TRILL data frames with FGL and transmit in TRILL, it MUST know 
exactly 
which RBridges support FGL, then it has to TRILL unicast such a frame to 
all 
relevant egress RBridges (of the remainder 1,000 RBridges). Otherwise,if 
it does not
know the relevant egress RBridges, it has to employ a tree to multicast 
the frame. 
And that frame will be discarded by non-FGL RBridges and not able to reach 
the 
interested end nodes 

So if E wants to send TRILL Data packets(including multi-destination 
packets) with fine 
grained labels, it must learn which RBridges support FGL, which do not 
support FGL. 
Maybe RB1 can tell E the 1,000 FGL-RBridges by its hellos to E1 if Hello 
packet can
accommodate so many RBridges nicknames.

Best Regards,
Zhai Hongjun
 
 Zhai Hongjun
 
 Tel: +86-25-52877345

2013-01-11 09:48

收件人
Radia Perlman <[email-masked]>
抄送
[email-masked], "[email-masked]" <[email-masked]>, 
"[email-masked]" <[email-masked]>, Linda 
Dunbar <[email-masked]>, "[email-masked]" <[email-masked]>
主题
Re: [trill] New version : TRILL Smart Endnodes draft

Some the latest messages in this thread are because all TRILL switches are 
required to support VLANs but not necessarily fine grained labels. So if a 
smart endnote wanted to use FGL TRILL Data frames and was connected to 
both VL and FGL TRILL switches, it would want to know which was which.

Thanks,
Donald

On Thu, Jan 10, 2013 at 8:34 PM, Radia Perlman <[email-masked]> 
wrote:
OK.  I've gotten confused here.  If a packet needs an FGL, and it is being 
encapsulated by a smart endnode, the smart endnode needs to put on the 
FGL, just like it would need to put on a VLAN.

Radia

Thanks,
Donald

Hi Donald, 

Best Regards,
Zhai Hongjun

Zhai Hongjun

Tel: +86-25-52877345

收件人

Thanks,
Donald

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 10 Jan 2013 21:54:53 -0500

Hi,

On Thu, Jan 10, 2013 at 9:32 PM, <[email-masked]> wrote:
>
> > Some the latest messages in this thread are because all TRILL switches are required to
> > support VLANs but not necessarily fine grained labels. So if a smart endnote wanted to
> > use FGL TRILL Data frames and was connected to both VL and FGL TRILL switches, it would
> Maybe I have not made my meaning clear, so I try to make it clearer using an example.
>
> Assume E is an smartnode connected to TRILL campus through RB1. There are 2,000
> RBridges in TRILL campus where 1,000 of them support FGL, and the remainder 1,000
> Rbridges do not support FGL. In this scenario, when E encapsulates a non-unicast
> frame into TRILL data frames with FGL and transmit in TRILL, it MUST know exactly
> which RBridges support FGL, then it has to TRILL unicast such a frame to all
> relevant egress RBridges (of the remainder 1,000 RBridges). Otherwise,if it does not
> know the relevant egress RBridges, it has to employ a tree to multicast the frame.
> And that frame will be discarded by non-FGL RBridges and not able to reach the
> interested end nodes

Under the current FGL draft, there is no data topology adjacency
between FGL and VL TRILL switches. So the distribution tree or trees
built by FGL TRILL switches will be bounded by the contiguous area of
FGL switches. Sending a multi-destination FGL TRILL Data frame on such
a tree will get to every FGL TRILL switch in that area without passing
through any VL TRILL switches. So flooding unknown unicast or using a
distribution tree for multicast should work fine.

Thanks,
Donald

> So if E wants to send TRILL Data packets(including multi-destination packets) with fine
> grained labels, it must learn which RBridges support FGL, which do not support FGL.
> Maybe RB1 can tell E the 1,000 FGL-RBridges by its hellos to E1 if Hello packet can
> [email-masked], "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Linda Dunbar <[email-masked]>, "[email-masked]" <[email-masked]>
> 主题
> Maybe I should have used a TRILL Header extension as an example of additional information that can be included by sending the TRILL Data packet rather than egressing.
>
> Some the latest messages in this thread are because all TRILL switches are required to support VLANs but not necessarily fine grained labels. So if a smart endnote wanted to use FGL TRILL Data frames and was connected to both VL and FGL TRILL switches, it would want to know which was which.
>
> Thanks,
> Donald
> On Thu, Jan 10, 2013 at 8:34 PM, Radia Perlman <[email-masked]> wrote:
> OK.  I've gotten confused here.  If a packet needs an FGL, and it is being encapsulated by a smart endnode, the smart endnode needs to put on the FGL, just like it would need to put on a VLAN.
>
> I think the main reason for an end station to want to receive/send FGL TRILL Data packets is because it wants to handle data packets with a very large number of different labels. This strikes me as a bit unusual, probably a large gateway or server, so the network would normally be configured so that the TRILL switches it is connected with support FGL.
>
> Thanks,
> Donald
> Radia Perlman <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
> 主题
> >> ・        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
> >>

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 11 Jan 2013 20:21:19 +0000

Radia,

From: Radia Perlman [mailto:[email-masked]]
Sent: Wednesday, January 09, 2013 4:32 PM
To: Linda Dunbar
Cc: Phanidhar Koganti; [email-masked]; [email-masked]; [email-masked]; [email-masked]
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

---

From: Radia Perlman <[email-masked]>
Date: Fri, 11 Jan 2013 12:37:48 -0800

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 <[email-masked]>wrote:

> *Sent:* Wednesday, January 09, 2013 4:32 PM
> *To:* Linda Dunbar
> *Cc:* Phanidhar Koganti; [email-masked]; [email-masked];
> *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
> the other (with encapsulation), forwarded to the attached RBridge R.****
>
> [Linda] Agree****
>
> ** **
>
> 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 ****
>
> ** **
>

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 11 Jan 2013 21:00:06 +0000

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.

Linda

From: Radia Perlman [mailto:[email-masked]]
Sent: Friday, January 11, 2013 2:38 PM
To: Linda Dunbar
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
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 <[email-masked]<mailto:[email-masked]>> wrote:
Radia,

From: Radia Perlman [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, January 09, 2013 4:32 PM
To: Linda Dunbar
Cc: Phanidhar Koganti; [email-masked]<mailto:[email-masked]>; [email-masked]; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [trill] Questions to TRILL Smart Endnodes draft

Linda

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 11 Jan 2013 17:46:33 -0500

Hi Linda,

On Fri, Jan 11, 2013 at 4:00 PM, Linda Dunbar <[email-masked]> wrote:
> 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

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

---

From: Linda Dunbar <[email-masked]>
Date: Sat, 12 Jan 2013 00:00:45 +0000

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

> From: Donald Eastlake [mailto:[email-masked]]
> Sent: Friday, January 11, 2013 4:47 PM
> To: Linda Dunbar
> > there are multiple End Nodes attached via the same physical port.  I
> don't
> > Cc: [email-masked]; [email-masked];
> [email-masked];
> > [email-masked]
> >
> >
> considers
> > On Fri, Jan 11, 2013 at 12:21 PM, Linda Dunbar
> > Cc: Phanidhar Koganti; [email-masked];
> [email-masked];
> learns
> > [Linda] What if multiple "smart endnode" sharing one link? For
> example,

---

From: Radia Perlman <[email-masked]>
Date: Sun, 13 Jan 2013 11:37:12 -0800

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 <[email-masked]>wrote:

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