Re: [trill] Questions to TRILL Smart Endnodes draft

[Radia Perlman <[e-mail]>]

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 <[e-mail]>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****
>
> ** **
>
> ** **
>
> *From:* [e-mail] [mailto:[e-mail]] *On Behalf
> Of *Radia Perlman
> *Sent:* Wednesday, January 09, 2013 12:22 AM
> *To:* Phanidhar Koganti
> *Cc:* [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> *Subject:* Re: [trill] 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****
>
>  ****
>
> ** **
>
> _______________________________________________
> trill mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/trill
>
>