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

[Phanidhar Koganti <[e-mail]>]

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]<mailto:[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]> [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of [e-mail]<mailto:[e-mail]>
Sent: Thursday, January 03, 2013 4:19 PM
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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