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

[Radia Perlman <[e-mail]>]

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 <[e-mail]>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****
>
> ** **
>
> *From:* Radia Perlman [mailto:[e-mail]]
> *Sent:* Wednesday, January 09, 2013 11:52 AM
>
> *To:* Phanidhar Koganti
> *Cc:* [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> *Subject:* Re: New version : TRILL Smart Endnodes draft****
>
> ** **
>
> 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 <[e-mail]>
> 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:[e-mail]]
> *Sent:* Wednesday, January 09, 2013 2:53 AM
> *To:* Phanidhar Koganti
> *Cc:* [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> *Subject:* Re: New version : TRILL Smart Endnodes draft****
>
>  ****
>
> 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 <[e-mail]>
> 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:* [e-mail] [mailto:[e-mail]] *On Behalf
> Of *[e-mail]
> *Sent:* Thursday, January 03, 2013 4:19 PM
> *To:* [e-mail]
> *Cc:* [e-mail]; [e-mail]; [e-mail]
> *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****
>
>  ****
>
> ** **
>