[trill] Questions to TRILL Smart Endnodes draft
Linda Dunbar <linda.dunbar@huawei.com> Wed, 09 January 2013 20:55 UTC
Return-Path: <linda.dunbar@huawei.com>
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89E161F0CFD for <trill@ietfa.amsl.com>; Wed, 9 Jan 2013 12:55:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.998
X-Spam-Level:
X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[AWL=-0.601, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQYNH3sLln8g for <trill@ietfa.amsl.com>; Wed, 9 Jan 2013 12:55:43 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E804E1F0CFC for <trill@ietf.org>; Wed, 9 Jan 2013 12:55:41 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AOO95512; Wed, 09 Jan 2013 20:55:39 +0000 (GMT)
Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 9 Jan 2013 20:54:40 +0000
Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 9 Jan 2013 20:55:38 +0000
Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.003; Wed, 9 Jan 2013 12:55:33 -0800
From: Linda Dunbar <linda.dunbar@huawei.com>
To: Radia Perlman <radiaperlman@gmail.com>, Phanidhar Koganti <pkoganti@brocade.com>
Thread-Topic: Questions to TRILL Smart Endnodes draft
Thread-Index: AQHN7quqE8c/67/j9UujxW5Rg87JVg==
Date: Wed, 09 Jan 2013 20:55:32 +0000
Message-ID: <4A95BA014132FF49AE685FAB4B9F17F6450E01E4@dfweml505-mbx>
References: <D5A6F3355F664C40AFB65BB1277D8D450186C7F7AD@MAAX7MCDC101.APAC.DELL.COM> <6895EAE0CA8DEE40B92D7CA88BB521F32414007827@HQ1-EXCH02.corp.brocade.com> <CAFOuuo7t8xt8Z1mx78G2SsE8tkmAMNs44xd11Mc43S1_WfH6RA@mail.gmail.com> <6895EAE0CA8DEE40B92D7CA88BB521F32414007BC1@HQ1-EXCH02.corp.brocade.com> <CAFOuuo626hw-c0kM4-1Fp-w2gByPenRnkFP3xNT+cTB4YcJ2kg@mail.gmail.com>
In-Reply-To: <CAFOuuo626hw-c0kM4-1Fp-w2gByPenRnkFP3xNT+cTB4YcJ2kg@mail.gmail.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.192.11.236]
Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F6450E01E4dfweml505mbx_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "d3e3e3@gmail.com" <d3e3e3@gmail.com>, "Kesava_Vijaya_Krupak@Dell.com" <Kesava_Vijaya_Krupak@dell.com>, "hu.fangwei@zte.com.cn" <hu.fangwei@zte.com.cn>, "trill@ietf.org" <trill@ietf.org>
Subject: [trill] Questions to TRILL Smart Endnodes draft
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Developing a hybrid router/bridge." <trill.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trill>, <mailto:trill-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/trill>
List-Post: <mailto:trill@ietf.org>
List-Help: <mailto:trill-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trill>, <mailto:trill-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Jan 2013 20:55:48 -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: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf Of Radia Perlman Sent: Wednesday, January 09, 2013 12:22 AM To: Phanidhar Koganti Cc: d3e3e3@gmail.com; Kesava_Vijaya_Krupak@Dell.com; hu.fangwei@zte.com.cn; trill@ietf.org 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 <pkoganti@brocade.com<mailto:pkoganti@brocade.com>> 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:radiaperlman@gmail.com<mailto:radiaperlman@gmail.com>] Sent: Wednesday, January 09, 2013 2:53 AM To: Phanidhar Koganti Cc: Kesava_Vijaya_Krupak@Dell.com; trill@ietf.org<mailto:trill@ietf.org>; d3e3e3@gmail.com<mailto:d3e3e3@gmail.com>; hu.fangwei@zte.com.cn<mailto:hu.fangwei@zte.com.cn> 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 <pkoganti@brocade.com<mailto:pkoganti@brocade.com>> 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: trill-bounces@ietf.org<mailto:trill-bounces@ietf.org> [mailto:trill-bounces@ietf.org<mailto:trill-bounces@ietf.org>] On Behalf Of Kesava_Vijaya_Krupak@Dell.com<mailto:Kesava_Vijaya_Krupak@Dell.com> Sent: Thursday, January 03, 2013 4:19 PM To: trill@ietf.org<mailto:trill@ietf.org> Cc: d3e3e3@gmail.com<mailto:d3e3e3@gmail.com>; radiaperlman@gmail.com<mailto:radiaperlman@gmail.com>; hu.fangwei@zte.com.cn<mailto:hu.fangwei@zte.com.cn> 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] New version : TRILL Smart Endnodes draft Kesava_Vijaya_Krupak
- Re: [trill] New version : TRILL Smart Endnodes dr… Phanidhar Koganti
- Re: [trill] New version : TRILL Smart Endnodes dr… Radia Perlman
- Re: [trill] New version : TRILL Smart Endnodes dr… Phanidhar Koganti
- Re: [trill] New version : TRILL Smart Endnodes dr… Radia Perlman
- Re: [trill] New version : TRILL Smart Endnodes dr… Phanidhar Koganti
- Re: [trill] New version : TRILL Smart Endnodes dr… Radia Perlman
- Re: [trill] New version : TRILL Smart Endnodes dr… Phanidhar Koganti
- [trill] Questions to TRILL Smart Endnodes draft Linda Dunbar
- Re: [trill] Questions to TRILL Smart Endnodes dra… Radia Perlman
- Re: [trill] New version : TRILL Smart Endnodes dr… Linda Dunbar
- Re: [trill] New version : TRILL Smart Endnodes dr… Radia Perlman
- Re: [trill] New version : TRILL Smart Endnodes dr… Linda Dunbar
- Re: [trill] New version : TRILL Smart Endnodes dr… Linda Dunbar
- Re: [trill] New version : TRILL Smart Endnodes dr… Radia Perlman
- Re: [trill] New version : TRILL Smart Endnodes dr… Donald Eastlake
- Re: [trill] New version : TRILL Smart Endnodes dr… Linda Dunbar
- Re: [trill] New version : TRILL Smart Endnodes dr… Donald Eastlake
- Re: [trill] New version : TRILL Smart Endnodes dr… zhai.hongjun
- Re: [trill] New version : TRILL Smart Endnodes dr… Donald Eastlake
- Re: [trill] New version : TRILL Smart Endnodes dr… Radia Perlman
- Re: [trill] New version : TRILL Smart Endnodes dr… Donald Eastlake
- Re: [trill] New version : TRILL Smart Endnodes dr… zhai.hongjun
- Re: [trill] New version : TRILL Smart Endnodes dr… Donald Eastlake
- Re: [trill] Questions to TRILL Smart Endnodes dra… Linda Dunbar
- Re: [trill] Questions to TRILL Smart Endnodes dra… Radia Perlman
- Re: [trill] Questions to TRILL Smart Endnodes dra… Linda Dunbar
- Re: [trill] Questions to TRILL Smart Endnodes dra… Donald Eastlake
- Re: [trill] Questions to TRILL Smart Endnodes dra… Linda Dunbar
- Re: [trill] Questions to TRILL Smart Endnodes dra… Radia Perlman