From frank.xialiang@huawei.com Sun Sep 1 20:48:43 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43B9921E808F for ; Sun, 1 Sep 2013 20:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vBzJLokTTYnU for ; Sun, 1 Sep 2013 20:48:38 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C805021E8082 for ; Sun, 1 Sep 2013 20:48:37 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AUY48416; Mon, 02 Sep 2013 03:48:36 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 2 Sep 2013 04:48:27 +0100 Received: from SZXEMA402-HUB.china.huawei.com (10.82.72.34) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 2 Sep 2013 04:48:35 +0100 Received: from SZXEMA502-MBS.china.huawei.com ([169.254.4.12]) by SZXEMA402-HUB.china.huawei.com ([10.82.72.34]) with mapi id 14.03.0146.000; Mon, 2 Sep 2013 11:48:28 +0800 From: "Xialiang (C)" To: "int-area@ietf.org" Thread-Topic: Re: [Int-area] Call for adoption of draft-nachum-sarp-06.txt Thread-Index: Ac6nj0hv5TjGHxboT7a3mXaCpUahcg== Date: Mon, 2 Sep 2013 03:48:28 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.42.220] Content-Type: multipart/alternative; boundary="_000_C02846B1344F344EB4FAA6FA7AF481F10F38489CSZXEMA502MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [Int-area] Call for adoption of draft-nachum-sarp-06.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2013 03:48:43 -0000 --_000_C02846B1344F344EB4FAA6FA7AF481F10F38489CSZXEMA502MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I have read through this draft. And I think it's a good and feasible soluti= on for resolving the FDB exploration problem whether in tradition or virtua= lized DC network. So I support it to be adopted as a WG draft. B.R. Frank --_000_C02846B1344F344EB4FAA6FA7AF481F10F38489CSZXEMA502MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

I have read through this draft.= And I think it’s a good and feasible solution for resolving the FDB = exploration problem whether in tradition or virtualized DC network. So I su= pport it to be adopted as a WG draft.

 

B.R.

Frank

--_000_C02846B1344F344EB4FAA6FA7AF481F10F38489CSZXEMA502MBSchi_-- From david.i.allan@ericsson.com Tue Sep 3 07:04:28 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D317811E820D for ; Tue, 3 Sep 2013 07:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gxWRcAGXufvh for ; Tue, 3 Sep 2013 07:04:22 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 477FD11E81FE for ; Tue, 3 Sep 2013 07:04:22 -0700 (PDT) X-AuditID: c618062d-b7fda8e0000024c6-97-5225ec65c790 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 09.D4.09414.56CE5225; Tue, 3 Sep 2013 16:04:21 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0328.009; Tue, 3 Sep 2013 10:04:20 -0400 From: David Allan I To: Linda Dunbar , "int-area@ietf.org" Thread-Topic: Call for adoption of draft-nachum-sarp-06.txt Thread-Index: Ac6k3Qh4liphP7t3SLCZUsNPa0sSWAABEZ9AAAGx72AANU9SoAC8CD3w Date: Tue, 3 Sep 2013 14:04:20 +0000 Message-ID: References: <4A95BA014132FF49AE685FAB4B9F17F645B86597@dfweml509-mbx.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645B911E9@dfweml509-mbb.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645B911E9@dfweml509-mbb.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrMLMWRmVeSWpSXmKPExsUyuXSPn27qG9Ugg1O7lCxuzLrJYnG3ZSKT A5NHy5G3rB5LlvxkCmCK4rJJSc3JLEst0rdL4MpYdPgwS8EzvooZPxYwNjC28nQxcnJICJhI 3Fp5ignCFpO4cG89WxcjF4eQwFFGibfdvxghnGWMEpf+HWMEqWITMJDY8/8LmC0iECrxeHo/ M4gtLGAlsbbnJBtE3Fpi/tPZrBC2m8SHRU/BalgEVCSmTv0MVsMr4CvxfOdEVogFK5kk3sxu YwFJcAqESfx6uQnMZgQ66fupNWDnMQuIS9x6Mh/qVAGJJXvOM0PYohIvH/9jhbCVJZY82c8C Ua8jsWD3JzYIW1ti2cLXzBCLBSVOznzCMoFRdBaSsbOQtMxC0jILScsCRpZVjBylxalluelG BpsYgRFxTIJNdwfjnpeWhxilOViUxHlX6Z0JFBJITyxJzU5NLUgtii8qzUktPsTIxMEp1cBY LCx/1/LRsehNzkcZbwhMibHRr/hXvHwVo+9qlpu+a/eWJQUf2RzS/uPKdqX65LUy3h3nJ9R+ CTg0N1azI8+y5nzYseIpf6QLDb49mxb3jU3G19zKSrZGY4ruETeHXc1+5xSYXkbME0n/8K/B pu5Qqdn7hXZJLDM/JUnv2Xjwgu3HlXqL+J8osRRnJBpqMRcVJwIANpqVdlYCAAA= Subject: Re: [Int-area] Call for adoption of draft-nachum-sarp-06.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 14:04:28 -0000 HI Linda: I understand the example you are providing, but I would assume that these m= ultiple instances are load balanced which means if individual app instances= in a subnet are poorly located traffic could be ping ponging all over the = place as any localization between the different component instances (web/ap= p/db) can no longer be guaranteed. The web server could be in one rack, the= app in another, and the db in another if each set of instances was treated= as a common pool. You would have to carve it up at a finer granularity to = hit all the criteria of goodness in the deployment of such an app... Cheers Dave -----Original Message----- From: Linda Dunbar [mailto:linda.dunbar@huawei.com]=20 Sent: Friday, August 30, 2013 1:25 PM To: David Allan I; int-area@ietf.org Subject: RE: Call for adoption of draft-nachum-sarp-06.txt > -----Original Message----- > VM placement affinity rules would NEVER see absolutely every local VM=20 > belonging to a different tenant network and requiring connectivity=20 > only to remote VMs. [Linda] Being in one VLAN (or subnet) doesn't mean that those hosts (or app= lications) have higher traffic among themselves. For a typical Data Center,= you may have many instances of WebServer in one subnet (typical one VLAN),= many instances of AppServer in another subnet (VLAN), and many instances o= f DBServer in yet another subnet. The Subnet is only for policy enforcement= and load balance purposes. The amount of traffic between "WebServer Instan= ces" <-> "AppServer instances" <-> "DB server instances" is magnitude highe= r than the heartbeat traffic among all instances of one function.=20 For some DC operators who want to optimize their traffic across racks, plac= ing instances from different subnets in one rack can eliminate a lot of tra= ffic traversing among racks.=20 Linda From ietf@rozanak.com Sun Sep 8 16:23:55 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4175E21E8108; Sun, 8 Sep 2013 16:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yHQwd9kpOaXA; Sun, 8 Sep 2013 16:23:50 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 721F021E8107; Sun, 8 Sep 2013 16:23:47 -0700 (PDT) Received: from kopoli (g225032200.adsl.alicedsl.de [92.225.32.200]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0LymY3-1W4dNT1XEN-016A26; Sun, 08 Sep 2013 19:23:43 -0400 From: "Hosnieh Rafiee" To: , Date: Mon, 9 Sep 2013 01:23:33 +0200 Message-ID: <000c01ceacea$7295d5b0$57c18110$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac6s6j1fjDMnNr7wROCtfn2old9LMA== Content-Language: en-us X-Provags-ID: V02:K0:Dvdx7RTdugkIhHRI8y9l6kdvNE3ajPUiNP4/jlgc+jn E/wb+dXI3GBY+oyEZOU6iTsb3WljSVqk+239JeW1NnnJtEJxe9 OzhoeD8DhvEFi2xlrUASKylzsTii5Y2KVnz2g+rS5y7LyAjZEV lBtWvfuzy9wPvTiKtb9criO1ETiaKvAULsNEE96kwM4D+SA6n0 gYjB91dPmmzGLPciJ/49OX03W8eo73wK8oml4KiyIi7Vu2/0vP 6MVVEVsk9Bw055wieZQBE6ilsHVNFZUvFNy231TvLhKPvqxgDY j6OU2L+Igttcjv/WQV1ndMRVAw45ndbkC3WcKcwM55SmZ0KeJ3 +Y6iXQ6JiNzihtJXNynY= Subject: [Int-area] cga-tsig new version - clarification of problem statement X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Sep 2013 23:23:55 -0000 Hello, I uploaded new version of cga-tsig, I tried to clarify the points and improved the problem statement. I improved the problem statement section and also modified the other section. For example, In the case of adding the IP addresses of other DNS servers manually to the configuration file (DNS update) or the case where you want to authenticate the resolver (you already know the IP address of the resolver via a DHCP server or an option in a RA message), the authentication is based solely on the source IP address. So it is possible for someone to spoof this IP address and poison the client's DNS cache. Of course it is possible to use it during a zone transfer as the authentication is again based on the source IP address if no security mechanisms are used. If it is used, then there is the other problem of dealing with the configuration of DNSSEC and TSIG, or shared secret leakage in TSIG. The purpose of CGA-TSIG is to eliminate these problems and to reduce the number of manual steps needed to carry out a configuration. I also explained in the document the case where the DNS server does not support SeND. So there are two options; it can either generate the CGA parameters by using any external script and then configure the IP address and use it as a means for further authentication, or it can generate the key pairs itself and skip the CGA verification step during the verification process, which is not secure in PTR or source IP address verification. http://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig I hope that this clarifies the draft. I have tried to respond to your concerns and I hope that with this version we can move forward. Thanks, Best, Hosnieh P.S. Sorry if any of you received this message twice. From cabo@tzi.org Mon Sep 9 13:22:28 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E744521F9FC6 for ; Mon, 9 Sep 2013 13:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1oFBMH953-+y for ; Mon, 9 Sep 2013 13:22:24 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id EEBED21F9FBE for ; Mon, 9 Sep 2013 13:22:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r89KMC9Z009604 for ; Mon, 9 Sep 2013 22:22:12 +0200 (CEST) Received: from [192.168.217.105] (p54893FE2.dip0.t-ipconnect.de [84.137.63.226]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 68E719B9; Mon, 9 Sep 2013 22:22:12 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Mon, 9 Sep 2013 22:22:11 +0200 To: "int-area@ietf.org" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [Int-area] New version of draft-bormann-intarea-alfi X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 20:22:29 -0000 I just submitted a re-spin of draft-bormann-intarea-alfi. Apart from typos, the major difference is that the abstract now = explicitly says: The present specification defines two alternative mechanisms [...] One design is based on the the IPv6 design and probably doesn't work on the Internet. The other design goes strictly against the IPv6 design and probably works well on the Internet. Maybe we can find some time in Vancouver to discuss this aspect of the = draft. Htmlized: = http://tools.ietf.org/html/draft-bormann-intarea-alfi-04 Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-bormann-intarea-alfi-04 Gr=FC=DFe, Carsten From Fred.L.Templin@boeing.com Mon Sep 9 13:50:25 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69D9311E8116 for ; Mon, 9 Sep 2013 13:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J+WLcSf-B6qf for ; Mon, 9 Sep 2013 13:50:20 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) by ietfa.amsl.com (Postfix) with ESMTP id 49B6821F9B07 for ; Mon, 9 Sep 2013 13:50:20 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r89KoF5m000724 for ; Mon, 9 Sep 2013 13:50:15 -0700 Received: from XCH-PHX-309.sw.nos.boeing.com (xch-phx-309.sw.nos.boeing.com [130.247.25.163]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r89KoEID000707 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 9 Sep 2013 13:50:14 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.29]) by XCH-PHX-309.sw.nos.boeing.com ([169.254.9.168]) with mapi id 14.02.0328.011; Mon, 9 Sep 2013 13:50:17 -0700 From: "Templin, Fred L" To: Carsten Bormann , "int-area@ietf.org" Thread-Topic: [Int-area] New version of draft-bormann-intarea-alfi Thread-Index: AQHOrZpXwCwDmwuB/0aiEJA9DGnOIJm933Fw Date: Mon, 9 Sep 2013 20:50:17 +0000 Message-ID: <2134F8430051B64F815C691A62D9831810456E@XCH-BLV-504.nw.nos.boeing.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Subject: Re: [Int-area] New version of draft-bormann-intarea-alfi X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 20:50:25 -0000 Hi Carsten, Here is a draft exploring a slightly different approach to "link adaptation avoidance": http://tools.ietf.org/html/draft-generic-6man-tunfrag-07 It mentions tunnels, but is applicable to any link type over which IPv6 requires the assistance of a link-specific adaptation scheme. You might also want to have a look at SEAL, which accommodates arbitrarily large MTU sizes over tunnels: http://www.ietf.org/id/draft-templin-intarea-seal-62.txt I think what you are proposing (and what the other draft I cited is proposing) would be compatible with SEAL. Thanks - Fred > -----Original Message----- > From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] On > Behalf Of Carsten Bormann > Sent: Monday, September 09, 2013 1:22 PM > To: int-area@ietf.org > Subject: [Int-area] New version of draft-bormann-intarea-alfi >=20 > I just submitted a re-spin of draft-bormann-intarea-alfi. > Apart from typos, the major difference is that the abstract now > explicitly says: >=20 > The present specification defines two alternative mechanisms [...] >=20 > One design is based on the the IPv6 design and probably doesn't work > on the Internet. The other design goes strictly against the IPv6 > design and probably works well on the Internet. >=20 > Maybe we can find some time in Vancouver to discuss this aspect of the > draft. >=20 > Htmlized: http://tools.ietf.org/html/draft-bormann-intarea-alfi- > 04 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-bormann- > intarea-alfi-04 >=20 > Gr=FC=DFe, Carsten >=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From Fred.L.Templin@boeing.com Mon Sep 9 15:26:34 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD08B21F9F9F for ; Mon, 9 Sep 2013 15:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FYKxkPtSfLs6 for ; Mon, 9 Sep 2013 15:26:29 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) by ietfa.amsl.com (Postfix) with ESMTP id 37D7221F9EA2 for ; Mon, 9 Sep 2013 15:26:17 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r89MQGVJ003354 for ; Mon, 9 Sep 2013 15:26:16 -0700 Received: from XCH-NWHT-04.nw.nos.boeing.com (xch-nwht-04.nw.nos.boeing.com [130.247.64.250]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r89MQG5C003342 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for ; Mon, 9 Sep 2013 15:26:16 -0700 Received: from XCH-EXCO-105.nw.nos.boeing.com (130.247.204.69) by XCH-NWHT-04.nw.nos.boeing.com (130.247.64.250) with Microsoft SMTP Server (TLS) id 8.3.297.1; Mon, 9 Sep 2013 15:26:16 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.29]) by XCH-EXCO-105.nw.nos.boeing.com ([fe80::f17a:6d23:e244:5ed2%14]) with mapi id 14.02.0328.011; Mon, 9 Sep 2013 17:26:13 -0500 From: "Templin, Fred L" To: "int-area@ietf.org" Thread-Topic: I-D Action: draft-templin-6man-linkadapt-00.txt Thread-Index: AQHOrarT52oj9DDWw0eDo4zaAn1w/5m9+o+w Date: Mon, 9 Sep 2013 22:26:11 +0000 Message-ID: <2134F8430051B64F815C691A62D983181046D9@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Subject: [Int-area] FW: I-D Action: draft-templin-6man-linkadapt-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 22:26:34 -0000 Hi, I revived this draft and cut out a bunch of stuff that detracted from the main idea. The main idea is that a link that is suffering from link adaptation overload can send an advisory message to the original source asking that it reduce the size of the packets it sends - even if the size is less than 1280 bytes. This is an advisory message and does not necessarily indicate packet loss. The message is also backward compatible with legacy nodes. Thanks - Fred fred.l.templin@boeing.com -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] = On Behalf Of internet-drafts@ietf.org Sent: Monday, September 09, 2013 3:20 PM To: i-d-announce@ietf.org Subject: I-D Action: draft-templin-6man-linkadapt-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : IPv6 Path MTU Interactions With Link Adaptation Author(s) : Fred L. Templin Filename : draft-templin-6man-linkadapt-00.txt Pages : 6 Date : 2013-09-09 Abstract: IPv6 intentionally deprecates fragmentation by routers in the network. Instead, links with restricting Maximum Transmission Units (MTUs) must either drop each too-large packet and return an ICMPv6 Packet Too Big (PTB) message or perform link-specific fragmentation and reassembly (also known as "link adaptation") at a layer below IPv6. This latter category of links is often performance-challenged to accommodate steady-state link adaptation. This document therefore proposes an update to the base IPv6 specification to better accommodate links that require link-specific adaptation to meet the IPv6 minimum MTU of 1280 bytes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-templin-6man-linkadapt There's also a htmlized version available at: http://tools.ietf.org/html/draft-templin-6man-linkadapt-00 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From heard@pobox.com Thu Sep 12 15:54:27 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAB1A21E8082 for ; Thu, 12 Sep 2013 15:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0XbVTHVKEKE for ; Thu, 12 Sep 2013 15:54:23 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB3421F9E01 for ; Thu, 12 Sep 2013 15:54:22 -0700 (PDT) Received: (qmail 21424 invoked from network); 12 Sep 2013 15:54:17 -0700 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 12 Sep 2013 15:54:17 -0700 Date: Thu, 12 Sep 2013 15:54:16 -0700 (PDT) From: "C. M. Heard" X-X-Sender: heard@shell4.bayarea.net To: INTAREA In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Ronald Bonica Subject: Re: [Int-area] FW: New Version Notification for draft-bonica-intarea-gre-mtu-03.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 22:54:28 -0000 Greetings, Ron asked me to take a look at this document and comment to the INTAREA mailing list. Since I'm not a GRE subject matter expert, I'm not in a position to judge whether the document accurately represents current practice. My comments will therefore necessarily be limited to issues of document consistency and clarity. Section 1, Introduction, and Section 3.1, General requirements: I see that RFC 2784 was updated by RFC 2890, and as far as I can tell, RFC 2890 is still in force. Is this worth mentioning, for sake of completeness? If yes, here are suggestions for changes to the text: Section OLD: Generic Routing Encapsulation (GRE) [RFC2784] can be used to carry any network layer protocol over any network layer protocol. GRE has been implemented by many vendors and is widely deployed on the Internet. Section 1 NEW: Generic Routing Encapsulation (GRE) [RFC2784][RFC2890] can be used to carry any network layer protocol over any network layer protocol. GRE has been implemented by many vendors and is widely deployed on the Internet. Section 3.1 OLD: Implementations MUST satisfy all of the requirements stated in [RFC2784]. Section 3.1 NEW: Implementations MUST satisfy all of the requirements stated in [RFC2784] and optionally MAY satisfy those stated in [RFC2890]. A normative reference to RFC 2890 would need then to be added. If RFC 2890 is obsolete and/or sparsely implemented, please disregard these suggestions. Section 1.2, Terminology: Presumably MPLS packets are not fragmentable. If so, I would suggest the following change: OLD: o non-fragmentable packet - all IPv4 packets with DF-bit equal to 1. Also, for the purposes of this document, all IPv6 packets are considered to be non-fragmentable. NEW: o non-fragmentable packet - all IPv4 packets with DF-bit equal to 1. Also, for the purposes of this document, all IPv6 packets and MPLS packets are considered to be non-fragmentable. Section 2.1, Candidate Strategies: OLD: Strategy 1 is an attractive alternative to Strategy 1, because it does not rely on PMTUD. [...] NEW: Strategy 1 is an attractive alternative to Strategy 4, because it does not rely on PMTUD. [...] Section 2.2, Strategic Overview, at the very end: The non-default mode of operation is desirable in some scenarios where networks block ICMP messages required by PMTUD. Would it be possible to provide an informative reference or to add some explanatory text to make this more specific? I grant that such an explanation is not strictly necessary to explain how GRE fragmentation works, but it would sure help motivate the the design choices described in the document. it also seems to me that such information would help an operator decide when (and when not) to use the non-default mode. Section 3.2, Tunnel MTU (TMTU) Estimation and Discovery However, if an implementation supports PMTUD or PLPMTUD for GRE tunnels, it MUST include a configuration option that disables those procedures. This configuration option may be required to mitigate certain denial of service attacks (see Section 8). When PMTUD is disabled, the TMTU MUST be set to a value that is less than or equal to the LMTU associated with the next-hop towards tunnel egress, minus the GRE overhead. I understand the reason for having a switch to turn off conventional PMTUD, namely the possiblility of attacks from forged ICMPv4/ICMPv6 Packet Too Big messages. However, it does not seem to me that PLPMTUD alone, without the use of ICMP messages, is vulnerable to this attack, so why turn it off, too? If that reasoning is correct, here is possible replacement text: However, if an implementation supports PMTUD for GRE tunnels, it MUST include a configuration option that disables this procedure. This configuration option may be required to mitigate certain denial of service attacks (see Section 8). When PMTUD is disabled, the TMTU MUST be set to a value that is less than or equal to the LMTU associated with the next-hop towards tunnel egress, minus the GRE overhead. PLPMTUD procedures MAY continue to be run when this option is selected, but if they do, they MUST NOT rely on the contents of any ICMPv4/ICMPv6 messages. Section 4.1, Tunneling GRE Over IPv4: However, the GRE ingress router MUST support a configuration option that invokes the following behavior: o when the GRE payload is IPv6, the DF-bit on the delivery header is set to 0 (Fragments Allowed) o when the GRE payload is IPv4, the DF-bit value is copied from the payload header to the delivery header For a while I was quite confused about the above text. After some head scratching I noticed that it seems to beinconsistent with the following text in Section 2.2, Strategic Overview, since IPv6 is considered non-fragmentable for the purposes of this draft: However, if the ingress router delivers fragmentable payload over IPv4, it copies the DF-bit value from the payload header to the delivery header. Therefore, the GRE delivery packet may be fragmented by any router between the GRE ingress and egress. When this occurs, the GRE delivery packet is reassembled by the GRE egress. After looking at the informative reference RFC 4459, and then chaining back to RFC 2003 (IP Encapsulation within IP, referenced by RFC 4459 but not the present draft), it seemed that what was said in Section 2.2 was right, and that the above-quoted text from Section 4.1 should read as follows: However, the GRE ingress router MUST support a configuration option that invokes the following behavior: o when the GRE payload is IPv6 or MPLS, the DF-bit on the delivery header is set to 1 (Fragmention Not Allowed) o when the GRE payload is IPv4, the DF-bit value is copied from the payload header to the delivery header When the DF-bit on the delivery header is set to 0, the GRE delivery packet may be fragmented by any router between the GRE ingress and egress and the GRE delivery packet will be reassembled by the GRE egress. If I correctly understood what I read in RFC 4459 and RFC 2003, the rationale for allowing the delivery packet to be fragmented when a payload IPv4 packet has DF=0 is because the IPv4 source node may not implement PMTUD (which an IPv6 node needs to do) or may be behind a middlebox that blocks ICMP messages and/or clears the DF bit (the latter being possible for IPv4 but not IPv6). But this isn't explained very clearly in either of those RFCs and not at all in the present draft; that was why I requested above a rationale for the non-default option in comments above. If I am wrong and the text should stay the way it is, I think an explanation of why to set DF=0 in the delivery header when the payload is IPv6 would very much be in order, and it would also be a good idea to specify what happens for MPLS payloads. Section 5.3, MPLS Payloads The GRE ingress router MUST discard the packet. As it is impossible to reliably identify the payload source, the GRE ingress router MUST NOT attempt to send an ICMPv4 Destination Unreachable message or an ICMPv6 Packet Too Big message to the payload source. RFC 4023 Section 5.1 identifies an exception to this situation when the ingress router is also the MPLS encapsulator. In order to take that situation into account, may I suggest the following alternative text, largely plagiarized from RFC 4023: The GRE ingress router MUST discard the packet. In general, it is impossible to reliably identify the payload source, and in that case the GRE ingress router MUST NOT attempt to send an ICMPv4 Destination Unreachable message or an ICMPv6 Packet Too Big message to the payload source. However, there is an exception to this rule if the ingress router is the MPLS encaplsuation entity and it receives an IP packet for encapsulation, which it first encapsulates in MPLS and then encapsulates in MPLS-in-GRE. In that case, if the source of the IP packet is reachable from the ingress router, and if the result of encapsulating the packet in MPLS would be a packet whose size exceeds the Tunnel MTU, then the ingress router SHOULD send the IP source of the discarded packet the proper ICMP error message. Secton 8, Security Considerations: OLD: PMTU Discovery is vulnerable to two denial of service attacks (see Section 8 of [RFC1191] for details). Both attacks are based upon on a malicious party sending forged ICMPv4 Destination Unreachable or ICMPv6 Packet Too Big messages to a host. In the first attack, the forged message indicates an inordinately small PMTU. In the second attack, the forged message indicates an inordinately large MTU. In both cases, throughput is adversely affected. On order to mitigate such attacks, GRE implementations MUST include a configuration option to disable PMTU discovery on GRE tunnels. Also, they MAY include a configuration option that conditions the behavior of PMTUD to establish a minimum PMTU. NEW: PMTU Discovery is vulnerable to a denial of service attack (see Section 8 of [RFC1191] and Section 6 of [RFC1981] for details). This attack is based upon on a malicious party sending a forged ICMPv4 Destination Unreachable or ICMPv6 Packet Too Big messages to a host indicating an inordinately small PMTU, causing throughput to be adversely affected. On order to mitigate this attack, GRE implementations MUST include a configuration option to disable PMTU discovery on GRE tunnels. Also, they MAY include a configuration option that conditions the behavior of PMTUD to establish a minimum PMTU. Rationale: both RFC 1981 and RFC 1191 specify that a host should never raise its estimate of the PMTU based on a Datagram Too Big message and so should not be vulnerable to an attacker sending forged ICMP messages indicating an inordinately large PMTU. General comment: if my understanding that Strategy 1 is never supported for IPv6 payloads is correct, then a GRE tunnel carrying IPv6 payloads must have a TMTU of at least 1280 bytes. If that was the intent, I'm content with the text as is (modulo corrections requested above). If that was NOT the intent, there is probably be a need for further clarifications. Thanks for the opportunity to review the document. I hope that my comments are helpful. Mike Heard On Thu, 15 Aug 2013, Ronald Bonica wrote: > Folks, > > This draft version addresses issues raised by Lars and Bob. > > Ron > > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: Thursday, August 15, 2013 1:49 PM > > To: Ronald Bonica; Carlos Pignataro; Joe Touch; Dr.Joseph D.Touch > > Subject: New Version Notification for draft-bonica-intarea-gre-mtu-03.txt > > > > > > A new version of I-D, draft-bonica-intarea-gre-mtu-03.txt > > has been successfully submitted by Ron Bonica and posted to the IETF > > repository. > > > > Filename: draft-bonica-intarea-gre-mtu > > Revision: 03 > > Title: A Fragmentation Strategy for Generic Routing Encapsulation (GRE) > > Creation date: 2013-08-15 > > Group: Individual Submission > > Number of pages: 12 > > URL: http://www.ietf.org/internet-drafts/draft-bonica-intarea-gre-mtu-03.txt > > Status: http://datatracker.ietf.org/doc/draft-bonica-intarea-gre-mtu > > Htmlized: http://tools.ietf.org/html/draft-bonica-intarea-gre-mtu-03 > > Diff: http://www.ietf.org/rfcdiff?url2=draft-bonica-intarea-gre-mtu-03 > > > > Abstract: > > This memo documents a GRE fragmentation strategy that has been > > implemented by many vendors and deployed in many networks. It was > > written so that a) implementors will be aware of best common practice > > and b) those who rely on GRE will understand how implementations > > work. The scope of this memo is limited to point-to-point GRE > > tunnels. All other tunnel types are beyond the scope of this memo. > > > > > > > > > > > > Please note that it may take a couple of minutes from the time of > > submission until the htmlized version and diff are available at > > tools.ietf.org. > > > > The IETF Secretariat > > > > > > From jshire@hyduke.com Thu Sep 12 16:38:13 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D6D321F8E3D for ; Thu, 12 Sep 2013 16:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tzHgkbCknaAJ for ; Thu, 12 Sep 2013 16:38:08 -0700 (PDT) Received: from mail.hyduke.net (mail.hyduke.net [204.29.213.36]) by ietfa.amsl.com (Postfix) with ESMTP id 4117111E80EE for ; Thu, 12 Sep 2013 16:38:08 -0700 (PDT) Received: from nsk1mx01.hyduke.net (192.168.9.68) by nsk1mx02.hyduke.net (192.168.10.49) with Microsoft SMTP Server id 8.1.436.0; Thu, 12 Sep 2013 17:38:07 -0600 Received: from nsk1mx01.hyduke.net ([::1]) by nsk1mx01.hyduke.net ([::1]) with mapi; Thu, 12 Sep 2013 17:38:06 -0600 From: Joshua Shire To: "int-area@ietf.org" Date: Thu, 12 Sep 2013 17:38:05 -0600 Thread-Topic: [Int-area] RE: New Version Notification for draft-bonica-intarea-gre-mtu-03.txt Thread-Index: Ac6wC4YZiShWQx7eTS6ANuVdAgpVCg== Message-ID: <766674E1C71A494B93E5386B430740DB06D4494FB0@nsk1mx01.hyduke.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_766674E1C71A494B93E5386B430740DB06D4494FB0nsk1mx01hyduk_" MIME-Version: 1.0 X-TM-AS-Product-Ver: SMEX-8.0.0.4125-6.800.1017-20144.004 X-TM-AS-Result: No--30.863000-4.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Subject: [Int-area] RE: New Version Notification for draft-bonica-intarea-gre-mtu-03.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 23:38:15 -0000 --_000_766674E1C71A494B93E5386B430740DB06D4494FB0nsk1mx01hyduk_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hey All, I took a quick peek at draft-bonica-intarea-gre-mtu-03.txt. This is very in= teresting as we ourselves are have just been dealing with GRE fragmentation= issues over a link to a new peer. I'll probably be bringing up some old ar= guments here (sorry) but here are my observations: 1) From my reading of it, the draft really doesn't deal with large (si= ze exceeding LMTU) packets with the DF bit set from a host who doesn't supp= ort PMTUD itself and/or for whatever reason can't receive ICMP type 4. It w= ould appear to call for just dropping the traffic. Perhaps I'm misreading 2= .2 but I see, for non-default operation: a. If large, non-fragmentable packet received then drop and send ICMP= type 4 to host b. If large, fragmentable packet received and transport from ingress t= o egress is IPv4, encapsulate and then fragment and transmit c. Otherwise if large fragmentable packet received and transport not = IPv4, fragment packet first then encapsulate Please feel free to correct if I've missed something. 2) Unfortunately if 1) is true and this draft is implemented as writte= n we'd be dooming a lot of communication to a black hole, which is bad, IMH= O. 3) Egress reassembly works as a good solution most of the time. The fl= ip argument is of course is that this can cause heavy burden on the egress = router, as had been pointed out. A potential compromise would be to impleme= nt egress reassembly only if the DF bit is set, and otherwise just fragment= prior to encapsulation. Unfortunately this varies from the intended aim of= the RFC as this is not implemented in code (AFAIK) and so doesn't represen= ted current available best practice. I also can't say exactly how much traf= fic would fall into either category or how much it would actually help. 4) We found that TCP MSS clamping on the tunnel interfaces was absolut= ely vital to getting fairly reliable communication and avoiding issues. I f= eel it should be included in this as best practice if you're going to have = to deal with a TMTU of less than 1500 bytes. It would be my number one piec= e of advice anyway. 5) The best, best practice we found is just to ensure you can get a PM= TU between ingress and egress of over 1524 bytes. Reassembly, whether at eg= ress router or client, causes delays in transmission and thus reduced throu= ghput, excessive resource utilization, etc. PMTUD means (small) delays for = retransmissions. I think this should be stressed in the draft that this is = the only real way to make the tunnel transparent. 6) Last paragraph on 2.1, first sentence, small typo, you compare stra= tegy 1 to itself. My 0.02. Thanks, Joshua Shire jshire@hyduke.com --_000_766674E1C71A494B93E5386B430740DB06D4494FB0nsk1mx01hyduk_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hey All,

 

I too= k a quick peek at draft-bonica-intarea-gre-mtu-03.txt. This is very interes= ting as we ourselves are have just been dealing with GRE fragmentation issu= es over a link to a new peer. I’ll probably be bringing up some old a= rguments here (sorry) but here are my observations:

 

1) &nbs= p;    From my reading of it, the dra= ft really doesn’t deal with large (size exceeding LMTU) packets with = the DF bit set from a host who doesn’t support PMTUD itself and/or fo= r whatever reason can’t receive ICMP type 4. It would appear to call = for just dropping the traffic. Perhaps I’m misreading 2.2 but I see, = for non-default operation:

&= nbsp;

a.  = ;     If large, non-fragmentabl= e packet received then drop and send ICMP type 4 to host

b.=      = If large, fragmentable packet received and transpo= rt from ingress to egress is IPv4, encapsulate and then fragment and transm= it

c. &= nbsp;     Otherwise if large fr= agmentable packet received and transport not IPv4, fragment packet first th= en encapsulate

 

Please feel free to correct if I’ve missed something.=

 

<= p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 level1 l= fo2'>2)      = Unfortunately if 1) is true and this draft is implemented as writ= ten we’d be dooming a lot of communication to a black hole, which is = bad, IMHO.

3)   &= nbsp;  Egress reassembly works as a good solut= ion most of the time. The flip argument is of course is that this can cause= heavy burden on the egress router, as had been pointed out. A potential co= mpromise would be to implement egress reassembly only if the DF bit is set,= and otherwise just fragment prior to encapsulation. Unfortunately this var= ies from the intended aim of the RFC as this is not implemented in code (AF= AIK) and so doesn’t represented current available best practice. I al= so can’t say exactly how much traffic would fall into either category= or how much it would actually help.

4)      We found that= TCP MSS clamping on the tunnel interfaces was absolutely vital to getting = fairly reliable communication and avoiding issues. I feel it should be incl= uded in this as best practice if you’re going to have to deal with a = TMTU of less than 1500 bytes. It would be my number one piece of advice any= way.

5)    &= nbsp; The best, best practice we found is just to e= nsure you can get a PMTU between ingress and egress of over 1524 bytes. Rea= ssembly, whether at egress router or client, causes delays in transmission = and thus reduced throughput, excessive resource utilization, etc. PMTUD mea= ns (small) delays for retransmissions. I think this should be stressed in t= he draft that this is the only real way to make the tunnel transparent.

6)      Last paragraph on 2.1, first sentence, small typo, yo= u compare strategy 1 to itself.

&n= bsp;

My 0.02.

 

Thanks,

 

Joshua Shire=

jshire@hyduke.com

 

= --_000_766674E1C71A494B93E5386B430740DB06D4494FB0nsk1mx01hyduk_-- From iesg-secretary@ietf.org Mon Sep 16 06:42:52 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDEBA11E8124; Mon, 16 Sep 2013 06:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.445 X-Spam-Level: X-Spam-Status: No, score=-102.445 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F5WmNOzGsfLa; Mon, 16 Sep 2013 06:42:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C1FD811E826D; Mon, 16 Sep 2013 06:42:45 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.71.p1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20130916134245.14885.98082.idtracker@ietfa.amsl.com> Date: Mon, 16 Sep 2013 06:42:45 -0700 Cc: int-area@ietf.org Subject: [Int-area] Last Call: (Using the IPv6 Flow Label for Server Load Balancing) to Informational RFC X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Reply-To: ietf@ietf.org List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 13:42:53 -0000 The IESG has received a request from the Internet Area Working Group WG (intarea) to consider the following document: - 'Using the IPv6 Flow Label for Server Load Balancing' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-09-30. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes how the IPv6 flow label as currently specified can be used to enhance layer 3/4 load distribution and balancing for large server farms. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-intarea-flow-label-balancing/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-intarea-flow-label-balancing/ballot/ No IPR declarations have been submitted directly on this I-D. From wesley.george@twcable.com Mon Sep 16 08:50:12 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B58A911E82AE; Mon, 16 Sep 2013 08:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.227 X-Spam-Level: X-Spam-Status: No, score=-0.227 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W++OMxAuAjBm; Mon, 16 Sep 2013 08:50:08 -0700 (PDT) Received: from cdcipgw01.twcable.com (cdcipgw01.twcable.com [165.237.91.110]) by ietfa.amsl.com (Postfix) with ESMTP id 8CCA911E82B7; Mon, 16 Sep 2013 08:50:01 -0700 (PDT) X-SENDER-IP: 10.136.163.10 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.90,916,1371096000"; d="scan'208";a="45139269" Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdcipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 16 Sep 2013 11:49:42 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Mon, 16 Sep 2013 11:49:28 -0400 From: "George, Wes" To: "ietf@ietf.org" Date: Mon, 16 Sep 2013 11:49:26 -0400 Thread-Topic: [Int-area] Last Call: (Using the IPv6 Flow Label for Server Load Balancing) to Informational RFC Thread-Index: Ac6y4q6N/cLdQFAoSgiMaxy2tt2nTgADVLoQ Message-ID: <2671C6CDFBB59E47B64C10B3E0BD5923043A72EEB5@PRVPEXVS15.corp.twcable.com> References: <20130916134245.14885.98082.idtracker@ietfa.amsl.com> In-Reply-To: <20130916134245.14885.98082.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "int-area@ietf.org" Subject: Re: [Int-area] Last Call: (Using the IPv6 Flow Label for Server Load Balancing) to Informational RFC X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 15:50:12 -0000 I've reviewed this draft, and have one substantive comment: I think within the operational considerations (and possibly the info model)= , you need some discussion of diagnostics and troubleshooting, both for on-= box and off-box implementations. How do I see that it's working properly, a= nd how do I diagnose problems when it's not? One of the problems with the existing hashing algorithms is that they are o= ften opaque, such that it's not clear what the device is doing, whether the= hashing is working properly and the flows are of the sort that create imba= lanced distribution, or whether hashing has broken somehow -- occasionally = you can get info, but it's usually hidden commands, with difficult-to-inter= pret responses, and it's not like most vendors publish their "secret sauce"= optimizations of hashing so that it's easy to predict what will happen giv= en a certain set of flows. In order for this to be operationally manageable, especially in the case of= on-router processing of this rebalancing, there has to be an easy way for = the operator to access the information about what's happening - what the re= sult would be if the flows were balanced according to the hash vs what is h= appening as a result of rebalancing, so that they can chase down things lik= e rebalancing misses or situations where this local optimization is creatin= g a problem elsewhere in the path because that device did something differe= nt in its attempts to balance better, etc. It may also be that this info is= necessary to properly tune the frequency of sampling, the thresholds for t= hings like long-lived vs short-lived flows, etc. to the specific network wh= ere it is being used. I realize that in the model you've proposed, we're somewhat limited because= this is using sampled flow data instead of the realtime packet hash. It ma= y be that this drives a requirement for the granularity of data being broug= ht into the system in the external mode, and some requirements about the le= vel of information available via the UI (or SNMP or XML or whatever) in the= automatic hardware-based mode. Thanks Wes George > -----Original Message----- > From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] On > Behalf Of The IESG > Sent: Monday, September 16, 2013 9:43 AM > To: IETF-Announce > Cc: int-area@ietf.org > Subject: [Int-area] Last Call: 01.txt> (Using the IPv6 Flow Label for Server Load Balancing) to > Informational RFC > > > The IESG has received a request from the Internet Area Working Group WG > (intarea) to consider the following document: > - 'Using the IPv6 Flow Label for Server Load Balancing' > as Informational RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2013-09-30. Exceptionally, comments may > be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > This document describes how the IPv6 flow label as currently > specified can be used to enhance layer 3/4 load distribution and > balancing for large server farms. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-intarea-flow-label-balancing/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-intarea-flow-label- > balancing/ballot/ > > > No IPR declarations have been submitted directly on this I-D. Anything below this line has been added by my company's mail server, I have= no control over it. ----------------- This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From wesley.george@twcable.com Mon Sep 16 13:54:27 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 232BF11E81C9; Mon, 16 Sep 2013 13:54:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.217 X-Spam-Level: X-Spam-Status: No, score=-0.217 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJjMgfhD9ivj; Mon, 16 Sep 2013 13:54:22 -0700 (PDT) Received: from cdcipgw02.twcable.com (cdcipgw02.twcable.com [165.237.91.111]) by ietfa.amsl.com (Postfix) with ESMTP id B23DB11E81AC; Mon, 16 Sep 2013 13:54:21 -0700 (PDT) X-SENDER-IP: 10.136.163.14 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.90,918,1371096000"; d="scan'208";a="38424841" Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdcipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 16 Sep 2013 16:54:17 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Mon, 16 Sep 2013 16:54:16 -0400 From: "George, Wes" To: "George, Wes" , "ietf@ietf.org" Date: Mon, 16 Sep 2013 16:54:14 -0400 Thread-Topic: [Int-area] Last Call: (Using the IPv6 Flow Label for Server Load Balancing) to Informational RFC Thread-Index: Ac6y4q6N/cLdQFAoSgiMaxy2tt2nTgADVLoQAAu0fmA= Message-ID: <2671C6CDFBB59E47B64C10B3E0BD5923043A84B622@PRVPEXVS15.corp.twcable.com> References: <20130916134245.14885.98082.idtracker@ietfa.amsl.com> <2671C6CDFBB59E47B64C10B3E0BD5923043A72EEB5@PRVPEXVS15.corp.twcable.com> In-Reply-To: <2671C6CDFBB59E47B64C10B3E0BD5923043A72EEB5@PRVPEXVS15.corp.twcable.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "int-area@ietf.org" Subject: Re: [Int-area] Last Call: (Using the IPv6 Flow Label for Server Load Balancing) to Informational RFC X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 20:54:27 -0000 Please disregard, these comments are intended for draft-ietf-opsawg-large-f= low-load-balancing-05. I replied to the wrong thread. Sorry for the spam. Thanks, Wes > -----Original Message----- > From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of > George, Wes > Sent: Monday, September 16, 2013 11:49 AM > To: ietf@ietf.org > Cc: int-area@ietf.org > Subject: RE: [Int-area] Last Call: balancing-01.txt> (Using the IPv6 Flow Label for Server Load Balancing) > to Informational RFC > > I've reviewed this draft, and have one substantive comment: > > I think within the operational considerations (and possibly the info > model), you need some discussion of diagnostics and troubleshooting, > both for on-box and off-box implementations. How do I see that it's > working properly, and how do I diagnose problems when it's not? > One of the problems with the existing hashing algorithms is that they > are often opaque, such that it's not clear what the device is doing, > whether the hashing is working properly and the flows are of the sort > that create imbalanced distribution, or whether hashing has broken > somehow -- occasionally you can get info, but it's usually hidden > commands, with difficult-to-interpret responses, and it's not like most > vendors publish their "secret sauce" optimizations of hashing so that > it's easy to predict what will happen given a certain set of flows. > In order for this to be operationally manageable, especially in the case > of on-router processing of this rebalancing, there has to be an easy way > for the operator to access the information about what's happening - what > the result would be if the flows were balanced according to the hash vs > what is happening as a result of rebalancing, so that they can chase > down things like rebalancing misses or situations where this local > optimization is creating a problem elsewhere in the path because that > device did something different in its attempts to balance better, etc. > It may also be that this info is necessary to properly tune the > frequency of sampling, the thresholds for things like long-lived vs > short-lived flows, etc. to the specific network where it is being used. > I realize that in the model you've proposed, we're somewhat limited > because this is using sampled flow data instead of the realtime packet > hash. It may be that this drives a requirement for the granularity of > data being brought into the system in the external mode, and some > requirements about the level of information available via the UI (or > SNMP or XML or whatever) in the automatic hardware-based mode. > > Thanks > Wes George > > > -----Original Message----- > > From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] On > > Behalf Of The IESG > > Sent: Monday, September 16, 2013 9:43 AM > > To: IETF-Announce > > Cc: int-area@ietf.org > > Subject: [Int-area] Last Call: balancing- > > 01.txt> (Using the IPv6 Flow Label for Server Load Balancing) to > > Informational RFC > > > > > > The IESG has received a request from the Internet Area Working Group > WG > > (intarea) to consider the following document: > > - 'Using the IPv6 Flow Label for Server Load Balancing' > > as Informational > RFC > > > > The IESG plans to make a decision in the next few weeks, and solicits > > final comments on this action. Please send substantive comments to the > > ietf@ietf.org mailing lists by 2013-09-30. Exceptionally, comments may > > be > > sent to iesg@ietf.org instead. In either case, please retain the > > beginning of the Subject line to allow automated sorting. > > > > Abstract > > > > > > This document describes how the IPv6 flow label as currently > > specified can be used to enhance layer 3/4 load distribution and > > balancing for large server farms. > > > > > > > > > > The file can be obtained via > > http://datatracker.ietf.org/doc/draft-ietf-intarea-flow-label- > balancing/ > > > > IESG discussion can be tracked via > > http://datatracker.ietf.org/doc/draft-ietf-intarea-flow-label- > > balancing/ballot/ > > > > > > No IPR declarations have been submitted directly on this I-D. > > Anything below this line has been added by my company's mail server, I > have no control over it. > ----------------- > > This E-mail and any of its attachments may contain Time Warner Cable > proprietary information, which is privileged, confidential, or subject > to copyright belonging to Time Warner Cable. This E-mail is intended > solely for the use of the individual or entity to which it is addressed. > If you are not the intended recipient of this E-mail, you are hereby > notified that any dissemination, distribution, copying, or action taken > in relation to the contents of and attachments to this E-mail is > strictly prohibited and may be unlawful. If you have received this E- > mail in error, please notify the sender immediately and permanently > delete the original and any copy of this E-mail and any printout. This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From Fred.L.Templin@boeing.com Wed Sep 25 12:35:28 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55FAF21F9B10 for ; Wed, 25 Sep 2013 12:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id alXKdlPQ9A2X for ; Wed, 25 Sep 2013 12:35:23 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) by ietfa.amsl.com (Postfix) with ESMTP id 8E87911E812C for ; Wed, 25 Sep 2013 12:35:23 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r8PJZLG7026091 for ; Wed, 25 Sep 2013 14:35:21 -0500 Received: from XCH-PHX-409.sw.nos.boeing.com (xch-phx-409.sw.nos.boeing.com [10.57.37.40]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r8PJZKZd026087 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Wed, 25 Sep 2013 14:35:21 -0500 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.29]) by XCH-PHX-409.sw.nos.boeing.com ([169.254.9.8]) with mapi id 14.02.0328.011; Wed, 25 Sep 2013 12:35:20 -0700 From: "Templin, Fred L" To: INTAREA Thread-Topic: [Int-area] FW: New Version Notification for draft-bonica-intarea-gre-mtu-03.txt Thread-Index: AQHOsAsa799S7JlG1Ue69Q8lmY43L5nW6HLA Date: Wed, 25 Sep 2013 19:35:19 +0000 Message-ID: <2134F8430051B64F815C691A62D9831811262C@XCH-BLV-504.nw.nos.boeing.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Subject: Re: [Int-area] FW: New Version Notification for draft-bonica-intarea-gre-mtu-03.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 19:35:28 -0000 Hi, this document suggests using PLPMTUD (RFC4821) for GRE tunnels, but it doesn't say anything about how that might be done or for what purposes. I have produced an implementation that does exactly that: http://linkupnetworks.com/seal/sealv2-0.0.tgz Briefly, the implementation works as follows: 1) If the inner packet is no larger than 1280 bytes minus the length of the encapsulation headers, encapsulate and send without fragmentation. 2) If the inner packet is larger than 1500 bytes but no larger than the path MTU, encapsulate and send without fragmentation. 3) For all other packets, encapsulate and use SEAL fragmentation to break the packets into a size that should be small enough to traverse the tunnel without further fragmentation even if there are other tunnels in the path. At the same time, probe the path to see if packets of this size can be delivered without fragmentation and, if so, discontinue the fragmentation process and send future packets in this size range as whole packets. The procedures are specified in 'draft-templin-intarea-seal', which can be found here: http://tools.ietf.org/html/draft-templin-intarea-seal Thanks - Fred fred.l.templin@boeing.com From swmike@swm.pp.se Wed Sep 25 22:50:32 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39AF611E8153 for ; Wed, 25 Sep 2013 22:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aj34uVnccDqO for ; Wed, 25 Sep 2013 22:50:30 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 3CF8011E8146 for ; Wed, 25 Sep 2013 22:50:29 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 270D09C; Thu, 26 Sep 2013 07:50:27 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 174F79A; Thu, 26 Sep 2013 07:50:27 +0200 (CEST) Date: Thu, 26 Sep 2013 07:50:27 +0200 (CEST) From: Mikael Abrahamsson To: Suresh Krishnan In-Reply-To: <52143AFF.3060403@ericsson.com> Message-ID: References: <52143AFF.3060403@ericsson.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Internet Area Subject: Re: [Int-area] Call for adoption of draft-nachum-sarp-06.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 05:50:35 -0000 On Tue, 20 Aug 2013, Suresh Krishnan wrote: > Hi all, > This draft has been presented at several intarea face to face meetings > and has received quite a bit of discussion. It has been difficult to > gauge whether the wg is interested in this work or not. This call is > being initiated to determine whether there is WG consensus towards > adoption of draft-nachum-sarp-06 as an intarea WG draft. Please state > whether or not you're in favor of the adoption by replying to this > email. If you are not in favor, please also state your objections in > your response. This adoption call will complete on 2013-09-04. I would be much more interested in this work if it also solved other problems, such as packets sourced or destined from/to outside the network, to make sure it gets to a router for closest exit into a default gw router. So for instance, if a VM is moved from east to west, packets destined for default gw should now be sent to default gw located in west. The L3 network should also know that this IP address has moved and inject a /32 route from the west router to make sure packets traverse the L3 network as far as possible before it goes into the DC network. But I still wonder if this shouldn't be solved on L3 totally. Why can't datacenter standards properly use L3 for routing instead of using L2 to create huge L2 domains? It's inefficient if geographical distance is substantial due to packets taking inefficient paths due to the L3 network not knowing where the end IP address actually is. -- Mikael Abrahamsson email: swmike@swm.pp.se From xuxiaohu@huawei.com Thu Sep 26 02:22:11 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 456D211E8181; Thu, 26 Sep 2013 02:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.633 X-Spam-Level: X-Spam-Status: No, score=0.633 tagged_above=-999 required=5 tests=[AWL=-2.755, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G2YDFe+9kje7; Thu, 26 Sep 2013 02:21:51 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B160111E817D; Thu, 26 Sep 2013 02:21:47 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVW54215; Thu, 26 Sep 2013 09:21:41 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 26 Sep 2013 10:20:46 +0100 Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 26 Sep 2013 10:21:34 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.24]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0146.000; Thu, 26 Sep 2013 17:21:26 +0800 From: Xuxiaohu To: Mikael Abrahamsson , Suresh Krishnan Thread-Topic: =?gb2312?B?TDMtYmFzZWQgbmV0d29yayBvdmVybGF5cy8vtPC4tDogW0ludC1hcmVhXSBD?= =?gb2312?Q?all_for_adoption_of_draft-nachum-sarp-06.txt?= Thread-Index: AQHOunxlQ7L9e2SYmE+xYq/AWEoUh5nXphUQ Date: Thu, 26 Sep 2013 09:21:25 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08211FFF@NKGEML512-MBS.china.huawei.com> References: <52143AFF.3060403@ericsson.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.130] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "nvo3@ietf.org" , Internet Area , "l3vpn@ietf.org" Subject: [Int-area] =?gb2312?b?TDMtYmFzZWQgbmV0d29yayBvdmVybGF5cy8vtPA=?= =?gb2312?b?uLQ6ICBDYWxsIGZvciBhZG9wdGlvbiBvZiBkcmFmdC1uYWNodW0tc2FycC0w?= =?gb2312?b?Ni50eHQ=?= X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 09:22:12 -0000 KGNjJ2QgdGhpcyBlbWFpbCB0byBMM1ZQTiBhbmQgTlZvMyBzaW5jZSB0aGlzIGRpc2N1c3Npb24g bWF5IGJlIGludGVyZXN0aW5nIHRvIHRoZW0pDQoNCj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ILei vP7IyzogaW50LWFyZWEtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmludC1hcmVhLWJvdW5jZXNA aWV0Zi5vcmddILT6se0NCj4gTWlrYWVsIEFicmFoYW1zc29uDQo+ILeiy83KsbzkOiAyMDEzxOo5 1MIyNsjVIDEzOjUwDQo+IMrVvP7IyzogU3VyZXNoIEtyaXNobmFuDQo+ILOty806IEludGVybmV0 IEFyZWENCj4g1vfM4jogUmU6IFtJbnQtYXJlYV0gQ2FsbCBmb3IgYWRvcHRpb24gb2YgZHJhZnQt bmFjaHVtLXNhcnAtMDYudHh0DQo+IA0KPiBPbiBUdWUsIDIwIEF1ZyAyMDEzLCBTdXJlc2ggS3Jp c2huYW4gd3JvdGU6DQo+IA0KPiA+IEhpIGFsbCwNCj4gPiAgVGhpcyBkcmFmdCBoYXMgYmVlbiBw cmVzZW50ZWQgYXQgc2V2ZXJhbCBpbnRhcmVhIGZhY2UgdG8gZmFjZSBtZWV0aW5ncw0KPiA+IGFu ZCBoYXMgcmVjZWl2ZWQgcXVpdGUgYSBiaXQgb2YgZGlzY3Vzc2lvbi4gSXQgaGFzIGJlZW4gZGlm ZmljdWx0IHRvDQo+ID4gZ2F1Z2Ugd2hldGhlciB0aGUgd2cgaXMgaW50ZXJlc3RlZCBpbiB0aGlz IHdvcmsgb3Igbm90LiBUaGlzIGNhbGwgaXMNCj4gPiBiZWluZyBpbml0aWF0ZWQgdG8gZGV0ZXJt aW5lIHdoZXRoZXIgdGhlcmUgaXMgV0cgY29uc2Vuc3VzIHRvd2FyZHMNCj4gPiBhZG9wdGlvbiBv ZiBkcmFmdC1uYWNodW0tc2FycC0wNiBhcyBhbiBpbnRhcmVhIFdHIGRyYWZ0LiBQbGVhc2Ugc3Rh dGUNCj4gPiB3aGV0aGVyIG9yIG5vdCB5b3UncmUgaW4gZmF2b3Igb2YgdGhlIGFkb3B0aW9uIGJ5 IHJlcGx5aW5nIHRvIHRoaXMNCj4gPiBlbWFpbC4gSWYgeW91IGFyZSBub3QgaW4gZmF2b3IsIHBs ZWFzZSBhbHNvIHN0YXRlIHlvdXIgb2JqZWN0aW9ucyBpbg0KPiA+IHlvdXIgcmVzcG9uc2UuIFRo aXMgYWRvcHRpb24gY2FsbCB3aWxsIGNvbXBsZXRlIG9uIDIwMTMtMDktMDQuDQo+IA0KPiBJIHdv dWxkIGJlIG11Y2ggbW9yZSBpbnRlcmVzdGVkIGluIHRoaXMgd29yayBpZiBpdCBhbHNvIHNvbHZl ZCBvdGhlcg0KPiBwcm9ibGVtcywgc3VjaCBhcyBwYWNrZXRzIHNvdXJjZWQgb3IgZGVzdGluZWQg ZnJvbS90byBvdXRzaWRlIHRoZSBuZXR3b3JrLA0KPiB0byBtYWtlIHN1cmUgaXQgZ2V0cyB0byBh IHJvdXRlciBmb3IgY2xvc2VzdCBleGl0IGludG8gYSBkZWZhdWx0IGd3DQo+IHJvdXRlci4NCj4g DQo+IFNvIGZvciBpbnN0YW5jZSwgaWYgYSBWTSBpcyBtb3ZlZCBmcm9tIGVhc3QgdG8gd2VzdCwg cGFja2V0cyBkZXN0aW5lZCBmb3INCj4gZGVmYXVsdCBndyBzaG91bGQgbm93IGJlIHNlbnQgdG8g ZGVmYXVsdCBndyBsb2NhdGVkIGluIHdlc3QuIFRoZSBMMw0KPiBuZXR3b3JrIHNob3VsZCBhbHNv IGtub3cgdGhhdCB0aGlzIElQIGFkZHJlc3MgaGFzIG1vdmVkIGFuZCBpbmplY3QgYSAvMzINCj4g cm91dGUgZnJvbSB0aGUgd2VzdCByb3V0ZXIgdG8gbWFrZSBzdXJlIHBhY2tldHMgdHJhdmVyc2Ug dGhlIEwzIG5ldHdvcmsgYXMNCj4gZmFyIGFzIHBvc3NpYmxlIGJlZm9yZSBpdCBnb2VzIGludG8g dGhlIERDIG5ldHdvcmsuDQo+IA0KPiBCdXQgSSBzdGlsbCB3b25kZXIgaWYgdGhpcyBzaG91bGRu J3QgYmUgc29sdmVkIG9uIEwzIHRvdGFsbHkuIFdoeSBjYW4ndA0KPiBkYXRhY2VudGVyIHN0YW5k YXJkcyBwcm9wZXJseSB1c2UgTDMgZm9yIHJvdXRpbmcgaW5zdGVhZCBvZiB1c2luZyBMMiB0bw0K PiBjcmVhdGUgaHVnZSBMMiBkb21haW5zPyBJdCdzIGluZWZmaWNpZW50IGlmIGdlb2dyYXBoaWNh bCBkaXN0YW5jZSBpcw0KPiBzdWJzdGFudGlhbCBkdWUgdG8gcGFja2V0cyB0YWtpbmcgaW5lZmZp Y2llbnQgcGF0aHMgZHVlIHRvIHRoZSBMMyBuZXR3b3JrDQo+IG5vdCBrbm93aW5nIHdoZXJlIHRo ZSBlbmQgSVAgYWRkcmVzcyBhY3R1YWxseSBpcy4NCg0KSGkgTWlrYWVsLA0KDQpUaGUgYXBwcm9h Y2ggZGVzY3JpYmVkIGluIHRoaXMgZHJhZnQgKGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LXh1LWwzdnBuLXZpcnR1YWwtc3VibmV0LTAxKSBtYXkgbWVldCB5b3VyIGFib3ZlIGRlc2ly ZS4gQlRXLCBzdWNoIGFwcHJvYWNoIGhhcyBhbHJlYWR5IGJlZW4gaW1wbGVtZW50ZWQgYnkgc29t ZSBkYXRhIGNlbnRlciBuZXR3b3JrIHZlbmRvcnMuIA0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUg DQoNCj4gTWlrYWVsIEFicmFoYW1zc29uICAgIGVtYWlsOiBzd21pa2VAc3dtLnBwLnNlDQo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEludC1hcmVh IG1haWxpbmcgbGlzdA0KPiBJbnQtYXJlYUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2ludC1hcmVhDQo= From zhenghewen@huawei.com Thu Sep 26 05:32:11 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AECF121F9FD5; Thu, 26 Sep 2013 05:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cbZMea5cFjwU; Thu, 26 Sep 2013 05:32:07 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id DBFFD21E804E; Thu, 26 Sep 2013 05:32:03 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVW72217; Thu, 26 Sep 2013 12:32:02 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 26 Sep 2013 13:30:31 +0100 Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 26 Sep 2013 13:31:25 +0100 Received: from z52048a (10.138.41.137) by szxeml403-hub.china.huawei.com (10.82.67.35) with Microsoft SMTP Server id 14.3.146.0; Thu, 26 Sep 2013 20:31:22 +0800 From: Zhenghewen To: "'Mikael Abrahamsson'" , "'Suresh Krishnan'" References: <52143AFF.3060403@ericsson.com> In-Reply-To: Date: Thu, 26 Sep 2013 20:31:16 +0800 Message-ID: <009401cebab4$4c2b9f90$e482deb0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac66fGcslgVDU9unR7ary5tNEconBwAN7y3A Content-Language: zh-cn X-Originating-IP: [10.138.41.137] X-CFilter-Loop: Reflected Cc: nvo3@ietf.org, 'Internet Area' Subject: Re: [Int-area] Call for adoption of draft-nachum-sarp-06.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 12:32:11 -0000 Hi, Mikael, The application mentioned is related to the consistence of VM IP = address, exactly, it is about service consistence. In theory, absolute = service consistence seems impossible because even live VM motion also = introduce some milliseconds service disruption. Let's ignore the = temporarily service disruption. There are 2 types of applications for service consistence, one for = internet data centers (IDC) served for public internet users, for = example the service provided by www.google.com; the other for (virtual) = private data centers (vPDC) served for a tenant(e.g., a company) = intranet users: 1), For IDC, in the current real deployment, especially for IDC, = operator just uses DNS to keep service consistence after VM motion, for = example, before moving a VM who owns 10.10.10.10 response to = www.example.com into another site where the VM will have new IP address = 20.20.20.20, a new DNS entry (20.20.20.20 : www.example.com) will be = added into DSN server, and then move the VM to the other site; after the = completion of VM, the original DNS entry (10.10.10.10 : www.example.com) = will be deleted . Maybe some users or connections will be impacted, but = the impaction is very limited whatever at scope or duration. Many web = sites adopt the method. Maybe that is why we do not see the live VM = motion without any service disruption in real application. Certainly, we have other choices including host routing (e.g. virtual = subnet, LISP), MAC routing. 2), For vPDC, if VM#1 is moved from east to west through a layer 2 = network (for example, IP fabric via NVO3), a gratuitous ARP will be = released from the VM#1 after its motion is completed from east to west, = then all other VMs in east and all other VMs in west know the new ARP = entry for VM#1 (i.e., VMs in east data center know new ARP [west = gateway's MAC address : VM#1's IP address] for VM#1, VMs in west data = center know new ARP [VM#1's MAC address : VM#1's IP address]) according = to the draft, the communications with VM#1 in the intranet will not be = impacted, we get the consistence of VM IP address. Certainly, after the gratuitous ARP, the gateway in east and the = gateway in west for the tenant also know the new ARP entry for VM#1. All = packets destined to VM#1 will correctly reach VM#1. Best regards, Hewen Zheng -----Original Message----- From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] On = Behalf Of Mikael Abrahamsson Sent: Thursday, September 26, 2013 1:50 PM To: Suresh Krishnan Cc: Internet Area Subject: Re: [Int-area] Call for adoption of draft-nachum-sarp-06.txt On Tue, 20 Aug 2013, Suresh Krishnan wrote: > Hi all, > This draft has been presented at several intarea face to face = meetings > and has received quite a bit of discussion. It has been difficult to > gauge whether the wg is interested in this work or not. This call is > being initiated to determine whether there is WG consensus towards > adoption of draft-nachum-sarp-06 as an intarea WG draft. Please state > whether or not you're in favor of the adoption by replying to this > email. If you are not in favor, please also state your objections in > your response. This adoption call will complete on 2013-09-04. I would be much more interested in this work if it also solved other=20 problems, such as packets sourced or destined from/to outside the = network,=20 to make sure it gets to a router for closest exit into a default gw=20 router. So for instance, if a VM is moved from east to west, packets destined = for=20 default gw should now be sent to default gw located in west. The L3=20 network should also know that this IP address has moved and inject a /32 = route from the west router to make sure packets traverse the L3 network = as=20 far as possible before it goes into the DC network. But I still wonder if this shouldn't be solved on L3 totally. Why can't=20 datacenter standards properly use L3 for routing instead of using L2 to=20 create huge L2 domains? It's inefficient if geographical distance is=20 substantial due to packets taking inefficient paths due to the L3 = network=20 not knowing where the end IP address actually is. --=20 Mikael Abrahamsson email: swmike@swm.pp.se _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area From swmike@swm.pp.se Thu Sep 26 05:44:44 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB93311E80F8; Thu, 26 Sep 2013 05:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJKQQYR2n1KY; Thu, 26 Sep 2013 05:44:44 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id C093821F9D23; Thu, 26 Sep 2013 05:44:40 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 709AC9C; Thu, 26 Sep 2013 14:44:32 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 684389A; Thu, 26 Sep 2013 14:44:32 +0200 (CEST) Date: Thu, 26 Sep 2013 14:44:32 +0200 (CEST) From: Mikael Abrahamsson To: Zhenghewen In-Reply-To: <009401cebab4$4c2b9f90$e482deb0$@com> Message-ID: References: <52143AFF.3060403@ericsson.com> <009401cebab4$4c2b9f90$e482deb0$@com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: nvo3@ietf.org, 'Internet Area' Subject: Re: [Int-area] Call for adoption of draft-nachum-sarp-06.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 12:44:44 -0000 On Thu, 26 Sep 2013, Zhenghewen wrote: > Hi, Mikael, > > The application mentioned is related to the consistence of VM IP > address, exactly, it is about service consistence. In theory, absolute > service consistence seems impossible because even live VM motion also > introduce some milliseconds service disruption. Let's ignore the > temporarily service disruption. Check, but I wasn't concerned with service continuity, I was concerned with optimizing packet flight path. If VM was moved from east to west and east and west are 10ms RTT away from each other (very far, sure), then you want to make sure that all VMs in east talk to the routers at east, not use a default gw that is located in west. You also want to make sure that packets sitting in another subnet at east don't have to traverse to the router at west and then back to east again. -- Mikael Abrahamsson email: swmike@swm.pp.se From brian@innovationslab.net Fri Sep 27 13:00:01 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B5BC21F9F8F for ; Fri, 27 Sep 2013 13:00:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.241 X-Spam-Level: X-Spam-Status: No, score=-103.241 tagged_above=-999 required=5 tests=[AWL=-0.642, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aI+jOwV5lYhq for ; Fri, 27 Sep 2013 12:59:55 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 941FD21F9EE9 for ; Fri, 27 Sep 2013 12:59:54 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 1E375880F3 for ; Fri, 27 Sep 2013 12:59:54 -0700 (PDT) Received: from clemson.local (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id E13C9130003 for ; Fri, 27 Sep 2013 12:59:53 -0700 (PDT) Message-ID: <5245E3AD.5060706@innovationslab.net> Date: Fri, 27 Sep 2013 15:59:41 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: int-area@ietf.org References: <52143AFF.3060403@ericsson.com> In-Reply-To: <52143AFF.3060403@ericsson.com> X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="2kkqjEoWS6Be5SIhxPXdWKL8mVXMnmx5J" Subject: Re: [Int-area] Call for adoption of draft-nachum-sarp-06.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 20:00:01 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --2kkqjEoWS6Be5SIhxPXdWKL8mVXMnmx5J Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Suresh, Sorry for the late feedback, but there are some issues that should be discussed. Some of the following are my views of the document and others are summarized based on feedback from others. To be clear, the following comments are being made as an individual participant. 1. The idea of creating a Layer-2 NAT is rather unappealing. Many folks in the IETF understand the rash of issues that arise with this type of approach. It appears that is what happens with SARP (at least in some instance). 2. It is unclear *who* would want to build (or has built) a layer-2 network at this size and sees the application of proxies/NATs as the solution to scaling issues. Are there operators who have built networks in this way who can clearly explain the problem space? This comes about from the outcome of ARMD. 3. Given the length of time that this draft has been around, are there implementations? 4. How does this approach deal with non-IP traffic? Now with my AD hat on... I believe there are some issues raised by Dave Allan that have been left unanswered, though Dave can correct me if I am wrong. Consensus does not require unanimity, but it does require that all concerns raised be addressed. Regards, Brian --2kkqjEoWS6Be5SIhxPXdWKL8mVXMnmx5J Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSReOtAAoJEBOZRqCi7goqsUcH/1ZsvaoLm8qSZ5eH3cQX7p1h i9xSZwImQsgClZXNXrt1/fGywc6ulxLPckkm5WmK4sIvZqrVRgGC/2TY5pVqedHB B4K9Na0LJeO0V/p0bt7/plffbfy5WxKcojLkFdQ2JeBV4jR3hOFpqT0TsNYZLu7A CO4XoWyKiifmY/vlr2qXz0FFcf+wv886ka2v4gDexGEo0JzSRq1bHZcgMos+eKGM 0D/CQIdj4Yg5h7a2H6EvaF4IGvknbZJny/D3OWsdE+7E9fhIGp1eunzd4/0QiXf2 Oz7Z0wmN/2ercQYG8mz15XxDCa2IQCnzxvE+yw6TjvUFfKkv2fGbVYYFlLRh1rw= =MTJU -----END PGP SIGNATURE----- --2kkqjEoWS6Be5SIhxPXdWKL8mVXMnmx5J-- From david.i.allan@ericsson.com Fri Sep 27 13:41:05 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90F1121F9E33 for ; Fri, 27 Sep 2013 13:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2mswA-jjD6m0 for ; Fri, 27 Sep 2013 13:40:46 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id A8D9821F9D95 for ; Fri, 27 Sep 2013 13:40:46 -0700 (PDT) X-AuditID: c618062d-b7fda8e0000024c6-ef-5245ed4d538f Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 8D.1F.09414.D4DE5425; Fri, 27 Sep 2013 22:40:46 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0328.009; Fri, 27 Sep 2013 16:40:45 -0400 From: David Allan I To: Brian Haberman , "int-area@ietf.org" Thread-Topic: [Int-area] Call for adoption of draft-nachum-sarp-06.txt Thread-Index: AQHOu7wa4515xuMxuU+ibz4KXnOs7JnaCFrw Date: Fri, 27 Sep 2013 20:40:44 +0000 Message-ID: References: <52143AFF.3060403@ericsson.com> <5245E3AD.5060706@innovationslab.net> In-Reply-To: <5245E3AD.5060706@innovationslab.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrILMWRmVeSWpSXmKPExsUyuXRPgq7fW9cggy2/uC1m9vxjtLgx6yaL A5PHkiU/mTxmHv/CEsAUxWWTkpqTWZZapG+XwJXR8vs1c8FD4YpLu9YxNjBe4e9i5OSQEDCR +DHhAROELSZx4d56ti5GLg4hgaOMEo2vVjFCOMsZJSacWMkIUsUmYCCx5/8XMFtEIELiy4oz 7CC2sICrxNxjV1kh4m4SK9dNgKoxkvjfuIWli5GDg0VAVWLZe2mQMK+Ar8SNXxfBWoUEgiU6 3i0CszmByl8s3ccGYjMCHfT91Bqw45gFxCVuPZkPdaiAxJI955khbFGJl4//sULYyhJLnuxn gajXkViw+xMbhK0tsWzha2aIvYISJ2c+YZnAKDoLydhZSFpmIWmZhaRlASPLKkaO0uLUstx0 I4NNjMBoOCbBpruDcc9Ly0OM0hwsSuK8X946BwkJpCeWpGanphakFsUXleakFh9iZOLglGpg XPDmd+OTryfyMlVYrt13TU3kc1rF/uD090Jh08WbzzGdFTqx4pTObftb2vrr/LL+K1/4nth/ UltUPdFvWewVnuSAC1Uf6/nf5prLfKtda/iS6fiPvSm/P0udWGs9b0qbrdYNuSmXsn89/ldw TPvFhzvsvXMUWpgk9rYHlNQfmv1gU5B+87L8n0osxRmJhlrMRcWJANPdBoJUAgAA Subject: Re: [Int-area] Call for adoption of draft-nachum-sarp-06.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 20:41:06 -0000 HI Brian: You offer a pretty good summary, to which I would add as such a solution wo= uld be highly likely to be limited to 4K VLANs (as it is implemented as a f= lat Ethernet technology layer). As soon as I add an overlay to address this= limitation, a chunk of the surrounding rationale for the approach IMO evap= orates....and if the solution was defined flat as advertised, given the amo= unt of ranting about the 4K limit in numerous WGs, progressing a solution t= hat embodies such a limitation would appear to be less than useful. Although the list discussion around my comments was an interesting and info= rmative one, I did not consider my concerns addressed. An L3 ARP proxy driv= ing a 1:N MAC-NAT breaks a lot of stuff. IMO that is rather fundamental and= more discussion would not change the facts. In that regard I cannot see ho= w my concerns can be addressed by SARP as it stands... I hope this helps... cheers Dave -----Original Message----- From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] On Behal= f Of Brian Haberman Sent: Friday, September 27, 2013 1:00 PM To: int-area@ietf.org Subject: Re: [Int-area] Call for adoption of draft-nachum-sarp-06.txt Suresh, Sorry for the late feedback, but there are some issues that should be = discussed. Some of the following are my views of the document and others a= re summarized based on feedback from others. To be clear, the following comments are being made as an individual pa= rticipant. 1. The idea of creating a Layer-2 NAT is rather unappealing. Many folks in= the IETF understand the rash of issues that arise with this type of approa= ch. It appears that is what happens with SARP (at least in some instance). 2. It is unclear *who* would want to build (or has built) a layer-2 network= at this size and sees the application of proxies/NATs as the solution to s= caling issues. Are there operators who have built networks in this way who= can clearly explain the problem space? This comes about from the outcome = of ARMD. 3. Given the length of time that this draft has been around, are there impl= ementations? 4. How does this approach deal with non-IP traffic? Now with my AD hat on... I believe there are some issues raised by Dave Allan that have been le= ft unanswered, though Dave can correct me if I am wrong. Consensus does no= t require unanimity, but it does require that all concerns raised be addres= sed. Regards, Brian From Ted.Lemon@nominum.com Fri Sep 27 13:45:36 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 202DB21E808A for ; Fri, 27 Sep 2013 13:45:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.539 X-Spam-Level: X-Spam-Status: No, score=-106.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R7vlQtEewByO for ; Fri, 27 Sep 2013 13:45:29 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id AFBAF11E80E8 for ; Fri, 27 Sep 2013 13:45:28 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKUkXuZ8FeTJt1y1pjdsVkaBt2Uv3yacZJ@postini.com; Fri, 27 Sep 2013 13:45:28 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 6550F1B8280 for ; Fri, 27 Sep 2013 13:45:27 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id B330E19006E; Fri, 27 Sep 2013 13:45:26 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from [10.0.10.40] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 27 Sep 2013 13:45:26 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1811\)) From: Ted Lemon In-Reply-To: Date: Fri, 27 Sep 2013 16:45:24 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <1504D45B-0AF8-4B35-BF64-D7DD913A37FD@nominum.com> References: <52143AFF.3060403@ericsson.com> <5245E3AD.5060706@innovationslab.net> To: David Allan I X-Mailer: Apple Mail (2.1811) X-Originating-IP: [192.168.1.10] Cc: "int-area@ietf.org" Subject: Re: [Int-area] Call for adoption of draft-nachum-sarp-06.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 20:45:36 -0000 On Sep 27, 2013, at 4:40 PM, David Allan I = wrote: > Although the list discussion around my comments was an interesting and = informative one, I did not consider my concerns addressed. An L3 ARP = proxy driving a 1:N MAC-NAT breaks a lot of stuff. IMO that is rather = fundamental and more discussion would not change the facts. In that = regard I cannot see how my concerns can be addressed by SARP as it = stands... I realize that for the people presenting these points it is obvious why = a L2 nat is a bad idea, and I think I know at least one reason why they = feel this way, but it would help to actually walk the working group = through it rather than just pointing out that it is so, because I = suspect that there are plenty of working group participants who are not = experts on the topic, but would understand readily if the concerns were = explained in more detail. From david.i.allan@ericsson.com Fri Sep 27 13:59:12 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC4D721F9C53 for ; Fri, 27 Sep 2013 13:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YPMNEm5Uilvq for ; Fri, 27 Sep 2013 13:59:06 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id BBF5621F9C05 for ; Fri, 27 Sep 2013 13:59:00 -0700 (PDT) X-AuditID: c618062d-b7fda8e0000024c6-68-5245f193c302 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id FE.10.09414.391F5425; Fri, 27 Sep 2013 22:59:00 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0328.009; Fri, 27 Sep 2013 16:58:59 -0400 From: David Allan I To: Ted Lemon Thread-Topic: [Int-area] Call for adoption of draft-nachum-sarp-06.txt Thread-Index: AQHOu7wa4515xuMxuU+ibz4KXnOs7JnaCFrwgABINgD//70+MA== Date: Fri, 27 Sep 2013 20:58:58 +0000 Message-ID: References: <52143AFF.3060403@ericsson.com> <5245E3AD.5060706@innovationslab.net> <1504D45B-0AF8-4B35-BF64-D7DD913A37FD@nominum.com> In-Reply-To: <1504D45B-0AF8-4B35-BF64-D7DD913A37FD@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyuXRPlO6Uj65BBj+2iVnM7PnHaHFj1k0W i63dsQ7MHkuW/GTymHn8C4vH6wPzWQOYo7hsUlJzMstSi/TtErgyZtzbwVKwl79i/8KXTA2M W3m6GDk5JARMJLaf/sYIYYtJXLi3nq2LkYtDSOAoo8SjKc+hnOWMEpcurGYBqWITMJDY8/8L WIeIgKrE9tYJYHFmgQiJPw2/mEBsYQFXibnHrrJC1LhJrFw3AareSeL+/V4wmwWo99OFNewg Nq+Ar0Tfv19sILaQwBlGicPrzEBsTgF7iYVH28DijEDXfT+1hglil7jErSfzmSCuFpBYsuc8 M4QtKvHy8T9WCFtZYsmT/VC36Ugs2P2JDcLWlli28DUzxF5BiZMzn7BMYBSbhWTsLCQts5C0 zELSsoCRZRUjR2lxalluupHBJkZg5ByTYNPdwbjnpeUhRmkOFiVx3i9vnYOEBNITS1KzU1ML Uovii0pzUosPMTJxcEo1MJrxh/h67Z7P/+dzcFR6tWx/zKS3XJ9/bDr/mn+t8ttcje6ImwnT Tt2bJbPxmhXDpXemLj8uGUSvfu7J5+d6sZ9x77FbFluKQ6d0u0gZXXS8Ma9bXean9A+GNlvl 4+yKoValrMH1qcKvzme71u5bwBhbmf1lrbqS6/dtPe+P/NH/yP9iaeyieUosxRmJhlrMRcWJ AEp5YG9qAgAA Cc: "int-area@ietf.org" Subject: Re: [Int-area] Call for adoption of draft-nachum-sarp-06.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 20:59:12 -0000 Hi Ted: The "scaling benefit" offered by the approach is that the set of subtending= end system MAC addresses is summarized as the MAC address of the ARP proxy= which overwrites the ES address in the frame. The result being that MAC ta= bles in the core tend to be smaller. The key thing is that this is a 1:N t= ranslation so the ARP proxy needs IP information in the frame and local ARP= cache information in order to successfully translate the MAC address in fr= ames addressed to itself to the subtending end system's MAC addresses.=20 What this means is any non-IP E2E protocol (CFM, QCN etc.) is broken and ho= w one would instrument and fault sectionalize this network is unclear. It l= ooks like an Ethernet subnet but does not behave like one.=20 Again hope this helps Dave -----Original Message----- From: Ted Lemon [mailto:ted.lemon@nominum.com]=20 Sent: Friday, September 27, 2013 1:45 PM To: David Allan I Cc: Brian Haberman; int-area@ietf.org Subject: Re: [Int-area] Call for adoption of draft-nachum-sarp-06.txt On Sep 27, 2013, at 4:40 PM, David Allan I wro= te: > Although the list discussion around my comments was an interesting and in= formative one, I did not consider my concerns addressed. An L3 ARP proxy dr= iving a 1:N MAC-NAT breaks a lot of stuff. IMO that is rather fundamental a= nd more discussion would not change the facts. In that regard I cannot see = how my concerns can be addressed by SARP as it stands... I realize that for the people presenting these points it is obvious why a L= 2 nat is a bad idea, and I think I know at least one reason why they feel t= his way, but it would help to actually walk the working group through it ra= ther than just pointing out that it is so, because I suspect that there are= plenty of working group participants who are not experts on the topic, but= would understand readily if the concerns were explained in more detail. From narten@us.ibm.com Fri Sep 27 14:29:13 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0CCB21F9E70 for ; Fri, 27 Sep 2013 14:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.979 X-Spam-Level: X-Spam-Status: No, score=-109.979 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z33ilkrvp1sC for ; Fri, 27 Sep 2013 14:29:07 -0700 (PDT) Received: from e9.ny.us.ibm.com (e9.ny.us.ibm.com [32.97.182.139]) by ietfa.amsl.com (Postfix) with ESMTP id F289C21F8FF8 for ; Fri, 27 Sep 2013 14:28:31 -0700 (PDT) Received: from /spool/local by e9.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 27 Sep 2013 17:28:31 -0400 Received: from d01dlp02.pok.ibm.com (9.56.250.167) by e9.ny.us.ibm.com (192.168.1.109) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 27 Sep 2013 17:28:28 -0400 Received: from b01cxnp22035.gho.pok.ibm.com (b01cxnp22035.gho.pok.ibm.com [9.57.198.25]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 4D0346E8041 for ; Fri, 27 Sep 2013 17:28:27 -0400 (EDT) Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by b01cxnp22035.gho.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r8RLSSxK61997090 for ; Fri, 27 Sep 2013 21:28:28 GMT Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r8RLSRjP019312 for ; Fri, 27 Sep 2013 17:28:27 -0400 Received: from cichlid.raleigh.ibm.com (sig-9-65-79-55.mts.ibm.com [9.65.79.55]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id r8RLSQ3A019223 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Sep 2013 17:28:27 -0400 Received: from cichlid.raleigh.ibm.com (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id r8RLSPVP002634; Fri, 27 Sep 2013 17:28:25 -0400 Message-Id: <201309272128.r8RLSPVP002634@cichlid.raleigh.ibm.com> To: Suresh Krishnan In-reply-to: <52143AFF.3060403@ericsson.com> References: <52143AFF.3060403@ericsson.com> Comments: In-reply-to Suresh Krishnan message dated "Tue, 20 Aug 2013 23:58:55 -0400." Date: Fri, 27 Sep 2013 17:28:25 -0400 From: Thomas Narten X-TM-AS-MML: No X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13092721-7182-0000-0000-0000088E5DA6 Cc: Internet Area Subject: Re: [Int-area] Call for adoption of draft-nachum-sarp-06.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 21:29:14 -0000 Given the flurry of mail, I went back and reviewed my notes on this document. I believe I understand the problem (reduce size of FDB), but am skeptical that solving it via the approach in this document is worthwhile. 1) As DaveA points out, FDB tables are large on chips these days. However, at least initially, SARP would be implemented in the service processor (consuming CPU cycles). It would be years (if ever) before silicon would implement this. But in parallel, silicon will just get better and have bigger FDB tables... Moreover, the SARP motivation section specifically cites a shortage of processor cycles as a problem ... but doing SARP in software will increase the demands on the CPU... its unclear to me that the increased CPU burdens SARP implies would be offset by the reduced amount of ARP processing that the solution is hoping will result... I.e., at least in the short term, it's unclear that SARP would actually help in practice. 2) Doing L2 NAT at line rates (an absolute requirement for edge devices) will only happen if this is done in silicon. I don't see that happening unless there is strong support from vendors/operators/chip makers... Software based solutions simply will not have sufficient performance. I think the IEEE would be a better place to have the discussion about what L2 chip makers are willing to implement... 3) Only works for IP. Doesn't work for non-IP L2. Doesn't that only solve part of the problem? 4) High availability is complex (but presumably also necessary). It smells a lot like multi-chassis LAG (with the need to synchronize state between tightly-coupled peers). Although IEEE is working in this general area now, there are tons of vendor-specific solutions for doing this at L2. Do we really want to tackle standardizing this in the IETF? Isn't the relevant expertise for this general area in IEEE? 5) This solution touchs on both L2 (NATing L2 addresses) and L3 (ARPing for IP addresses). We absolutely would need coordinate with IEEE before deciding to take on this work. 6) ARP caching will be a tradeoff. You want to cache responses for better performance, but long cache timeouts will result in black holes after VMs move. There is no great answer here. I expect long timeouts to be unacceptable operationally, which means that the benefits of caching will be limited (and these benefits are the key value proposition of this approach). It is really hard to estimate whether the benefits will be sufficient in practice. Gratuitous ARPs can help, but they are not reliable, so they will help, but have limitations... 7) I haven't fully worked this out, but I wonder if loops can form between proxies. There is the notion that when a VM moves, proxies will need to update their tables. But careful analysis will be needed to be sure that one can't ever have loops where proxies end up pointing to each other. And since the packets are L2 (with no TTL), such loops would be disasterous. (Note point 6: we are using heuristics (like gratuitous ARP) to get tables to converge after a change. Heuristics tend to have transient inconsistencies.. i.e., possibly leading to loops.) Again, overall, I understand the generic problem and that it would be nice to have a solution. However, I don't see a simple solution here. I see a fair amount of complexity, and I'm skeptical that it's worth it (e.g., when the next gen of silicon will just have a larger FDB). What I'd really like to see (before having the IETF commit to this work) is: 1) operators who are feeling the pain described in the document stepping forward and saying they think the solution being proposed is something they would be willing to deploy and is better than other approaches they have in their toolkit. 2) Vendors (including silicon) saying they see the need for this and think the would implement it. Thomas From linda.dunbar@huawei.com Fri Sep 27 14:33:05 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E74721F8F32 for ; Fri, 27 Sep 2013 14:33:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.164 X-Spam-Level: X-Spam-Status: No, score=-6.164 tagged_above=-999 required=5 tests=[AWL=0.435, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IqEtmFI-mRht for ; Fri, 27 Sep 2013 14:33:01 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9A42421F92CD for ; Fri, 27 Sep 2013 14:32:58 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYI92037; Fri, 27 Sep 2013 21:32:55 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 27 Sep 2013 22:32:01 +0100 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 27 Sep 2013 22:32:54 +0100 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.209]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.03.0146.000; Fri, 27 Sep 2013 14:32:48 -0700 From: Linda Dunbar To: Ted Lemon , David Allan I Thread-Topic: [Int-area] Call for adoption of draft-nachum-sarp-06.txt Thread-Index: AQHOniNFMXHqUclFB0+plegHtPYYUJnasUaAgAALeACAAAFOAP//lNVQ Date: Fri, 27 Sep 2013 21:32:48 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645BD0678@dfweml509-mbx.china.huawei.com> References: <52143AFF.3060403@ericsson.com> <5245E3AD.5060706@innovationslab.net> <1504D45B-0AF8-4B35-BF64-D7DD913A37FD@nominum.com> In-Reply-To: <1504D45B-0AF8-4B35-BF64-D7DD913A37FD@nominum.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.149.193] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "int-area@ietf.org" Subject: Re: [Int-area] Call for adoption of draft-nachum-sarp-06.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 21:33:05 -0000 Ted,=20 Thanks for the comments and reply.=20 Again, the draft is not about building one large Layer 2. The proposed proxy gateway is to enable subnets not to be restricted physic= ally together, i.e. allowing the gateway nodes in one access domain to be t= he "proxy gateway" for all the hosts attached regardless those hosts' subne= ts.=20 The draft is allow all the hosts attached to one "gateway" to be represente= d by this gateway, very much like today's router represent all the hosts at= tached. =20 As for L2 NAT mentioned in the draft, there are issues and the benefits. Th= e benefits have been documented in the draft and many of our emails. The is= sues need to be addressed. That is why we would like the WG to contribute.= =20 There are a lot of issues with L3 NAT too, but L3 NAT is one of the key com= ponents that make today's internet scale.=20 Linda > -----Original Message----- > From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] On > Behalf Of Ted Lemon > Sent: Friday, September 27, 2013 3:45 PM > To: David Allan I > Cc: int-area@ietf.org > Subject: Re: [Int-area] Call for adoption of draft-nachum-sarp-06.txt >=20 > On Sep 27, 2013, at 4:40 PM, David Allan I > wrote: > > Although the list discussion around my comments was an interesting > and informative one, I did not consider my concerns addressed. An L3 > ARP proxy driving a 1:N MAC-NAT breaks a lot of stuff. IMO that is > rather fundamental and more discussion would not change the facts. In > that regard I cannot see how my concerns can be addressed by SARP as it > stands... >=20 > I realize that for the people presenting these points it is obvious why > a L2 nat is a bad idea, and I think I know at least one reason why they > feel this way, but it would help to actually walk the working group > through it rather than just pointing out that it is so, because I > suspect that there are plenty of working group participants who are not > experts on the topic, but would understand readily if the concerns were > explained in more detail. >=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From linda.dunbar@huawei.com Fri Sep 27 14:36:25 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDAB521F9F45 for ; Fri, 27 Sep 2013 14:36:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.179 X-Spam-Level: X-Spam-Status: No, score=-6.179 tagged_above=-999 required=5 tests=[AWL=0.420, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ejTbiJKWywQu for ; Fri, 27 Sep 2013 14:36:21 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C995721F9994 for ; Fri, 27 Sep 2013 14:36:17 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AWF07752; Fri, 27 Sep 2013 21:36:14 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 27 Sep 2013 22:35:13 +0100 Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 27 Sep 2013 22:36:11 +0100 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.209]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.03.0146.000; Fri, 27 Sep 2013 14:36:07 -0700 From: Linda Dunbar To: David Allan I , Ted Lemon Thread-Topic: [Int-area] Call for adoption of draft-nachum-sarp-06.txt Thread-Index: AQHOniNFMXHqUclFB0+plegHtPYYUJnasUaAgAALeACAAAFOAIAAA8sA//+UH+A= Date: Fri, 27 Sep 2013 21:36:06 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645BD0686@dfweml509-mbx.china.huawei.com> References: <52143AFF.3060403@ericsson.com> <5245E3AD.5060706@innovationslab.net> <1504D45B-0AF8-4B35-BF64-D7DD913A37FD@nominum.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.149.193] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "int-area@ietf.org" Subject: Re: [Int-area] Call for adoption of draft-nachum-sarp-06.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 21:36:26 -0000 David,=20 > -----Original Message----- >=20 > What this means is any non-IP E2E protocol (CFM, QCN etc.) is broken > and how one would instrument and fault sectionalize this network is > unclear.=20 [Linda] The proposed "proxy gateway" only represents the IP applications' e= nd hosts address by the "gateway address" (i.e. only proxy them when the ho= sts issues ARP/ND).=20 For CFM, QCN and non-IP E2E, no proxy address is used.=20 Linda It looks like an Ethernet subnet but does not behave like one. >=20 > Again hope this helps > Dave >=20 > -----Original Message----- > From: Ted Lemon [mailto:ted.lemon@nominum.com] > Sent: Friday, September 27, 2013 1:45 PM > To: David Allan I > Cc: Brian Haberman; int-area@ietf.org > Subject: Re: [Int-area] Call for adoption of draft-nachum-sarp-06.txt >=20 > On Sep 27, 2013, at 4:40 PM, David Allan I > wrote: > > Although the list discussion around my comments was an interesting > and informative one, I did not consider my concerns addressed. An L3 > ARP proxy driving a 1:N MAC-NAT breaks a lot of stuff. IMO that is > rather fundamental and more discussion would not change the facts. In > that regard I cannot see how my concerns can be addressed by SARP as it > stands... >=20 > I realize that for the people presenting these points it is obvious why > a L2 nat is a bad idea, and I think I know at least one reason why they > feel this way, but it would help to actually walk the working group > through it rather than just pointing out that it is so, because I > suspect that there are plenty of working group participants who are not > experts on the topic, but would understand readily if the concerns were > explained in more detail. >=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From david.i.allan@ericsson.com Fri Sep 27 14:41:01 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA5D21F9E9F for ; Fri, 27 Sep 2013 14:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3oH3R0c7lztY for ; Fri, 27 Sep 2013 14:40:56 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id A31F921F9F45 for ; Fri, 27 Sep 2013 14:40:53 -0700 (PDT) X-AuditID: c6180641-b7fe28e000000d82-b8-5245fb6486cc Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id B1.21.03458.46BF5425; Fri, 27 Sep 2013 23:40:53 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.02.0328.009; Fri, 27 Sep 2013 17:40:52 -0400 From: David Allan I To: Linda Dunbar , Ted Lemon Thread-Topic: [Int-area] Call for adoption of draft-nachum-sarp-06.txt Thread-Index: AQHOu7wa4515xuMxuU+ibz4KXnOs7JnaCFrwgABINgD//70+MIAAUOwA//+9gTA= Date: Fri, 27 Sep 2013 21:40:51 +0000 Message-ID: References: <52143AFF.3060403@ericsson.com> <5245E3AD.5060706@innovationslab.net> <1504D45B-0AF8-4B35-BF64-D7DD913A37FD@nominum.com> <4A95BA014132FF49AE685FAB4B9F17F645BD0686@dfweml509-mbx.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645BD0686@dfweml509-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyuXSPt27qb9cgg+5rzBY3Zt1ksbjbMpHJ Ymt3rAOzR8uRt6weS5b8ZPJ4fWA+awBzFJdNSmpOZllqkb5dAlfGpMMd7AXbRCou/v3G1MC4 V6CLkZNDQsBEYsuOE2wQtpjEhXvrgWwuDiGBo4wSh58cYYFwljNKXLm3lwWkik3AQGLP/y+M ILaIgK/Eqi2LwGxmAW2JnROPMoPYwgKuEnOPXWWFqHGTWLluAlS9n8Tm5e/BalgEVCVerlwP NJODgxdozvOjChC77jBJnGrtYwKJcwqESaz8BNbKCHTc91NrmCBWiUvcejKfCeJoAYkle84z Q9iiEi8f/2OFsJUlljzZzwJRryOxYPcnNpgzly18DVbPKyAocXLmE5YJjGKzkIydhaRlFpKW WUhaFjCyrGLkKC1OLctNNzLcxAiMm2MSbI47GBd8sjzEKM3BoiTO++Wtc5CQQHpiSWp2ampB alF8UWlOavEhRiYOTqkGxhUcZk+v/36kuslZb/fkJvajDhlXFUz22l38vf2c6LdTzuVPX9vd WDGT/4vg8bRzbj8d389dEFmxmO/FtI/ZN2bcO2lX+OVbVYvV7fqAA74mjVsvFwp/eZm453/t Pa9Y2523c+cYhrPdyRO3Xt74LdfBqGSZ1y12LpddV/IXRzbZrnyhMyXlVZwSS3FGoqEWc1Fx IgBxOINDaQIAAA== Cc: "int-area@ietf.org" Subject: Re: [Int-area] Call for adoption of draft-nachum-sarp-06.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 21:41:01 -0000 HI Linda: You wrote: [Linda] The proposed "proxy gateway" only represents the IP applications' e= nd hosts address by the "gateway address" (i.e. only proxy them when the ho= sts issues ARP/ND).=20 For CFM, QCN and non-IP E2E, no proxy address is used. Then I still need a complete MAC table for these things to work as I need = both end system AND ARP proxy addresses in all FDBs, so the ARP proxy has o= nly added to the FDB size, not diminished it. While rendering my OAM protoc= ols as less effective as they are not instrumenting the path taken by IP tr= affic. They bypass the ARP proxy logic. Make sense? Dave -----Original Message----- From: Linda Dunbar [mailto:linda.dunbar@huawei.com]=20 Sent: Friday, September 27, 2013 2:36 PM To: David Allan I; Ted Lemon Cc: int-area@ietf.org Subject: RE: [Int-area] Call for adoption of draft-nachum-sarp-06.txt David,=20 > -----Original Message----- >=20 > What this means is any non-IP E2E protocol (CFM, QCN etc.) is broken=20 > and how one would instrument and fault sectionalize this network is=20 > unclear. Linda It looks like an Ethernet subnet but does not behave like one. >=20 > Again hope this helps > Dave >=20 > -----Original Message----- > From: Ted Lemon [mailto:ted.lemon@nominum.com] > Sent: Friday, September 27, 2013 1:45 PM > To: David Allan I > Cc: Brian Haberman; int-area@ietf.org > Subject: Re: [Int-area] Call for adoption of draft-nachum-sarp-06.txt >=20 > On Sep 27, 2013, at 4:40 PM, David Allan I=20 > > wrote: > > Although the list discussion around my comments was an interesting > and informative one, I did not consider my concerns addressed. An L3=20 > ARP proxy driving a 1:N MAC-NAT breaks a lot of stuff. IMO that is=20 > rather fundamental and more discussion would not change the facts. In=20 > that regard I cannot see how my concerns can be addressed by SARP as=20 > it stands... >=20 > I realize that for the people presenting these points it is obvious=20 > why a L2 nat is a bad idea, and I think I know at least one reason why=20 > they feel this way, but it would help to actually walk the working=20 > group through it rather than just pointing out that it is so, because=20 > I suspect that there are plenty of working group participants who are=20 > not experts on the topic, but would understand readily if the concerns=20 > were explained in more detail. >=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From linda.dunbar@huawei.com Fri Sep 27 14:54:23 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1561421F92E7 for ; Fri, 27 Sep 2013 14:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.194 X-Spam-Level: X-Spam-Status: No, score=-6.194 tagged_above=-999 required=5 tests=[AWL=0.405, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9mrV3dhQgmPd for ; Fri, 27 Sep 2013 14:54:18 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id AE4D521F9E95 for ; Fri, 27 Sep 2013 14:54:17 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYI92929; Fri, 27 Sep 2013 21:54:16 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 27 Sep 2013 22:53:17 +0100 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 27 Sep 2013 22:54:15 +0100 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.209]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.03.0146.000; Fri, 27 Sep 2013 14:53:52 -0700 From: Linda Dunbar To: David Allan I , Ted Lemon Thread-Topic: [Int-area] Call for adoption of draft-nachum-sarp-06.txt Thread-Index: AQHOniNFMXHqUclFB0+plegHtPYYUJnasUaAgAALeACAAAFOAIAAA8sA//+UH+CAAHeUgP//i3gA Date: Fri, 27 Sep 2013 21:53:52 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645BD06C2@dfweml509-mbx.china.huawei.com> References: <52143AFF.3060403@ericsson.com> <5245E3AD.5060706@innovationslab.net> <1504D45B-0AF8-4B35-BF64-D7DD913A37FD@nominum.com> <4A95BA014132FF49AE685FAB4B9F17F645BD0686@dfweml509-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.149.193] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "int-area@ietf.org" Subject: Re: [Int-area] Call for adoption of draft-nachum-sarp-06.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 21:54:23 -0000 David,=20 The CFM, OAM are exchanged among switches. The number of switches are limit= ed.=20 The proxy gateway is to enable edge nodes not to have individual addresses = for end hosts in remote domains. The edge nodes only need to have the remot= e gateway addresses and remote switches' addresses. Those addresses are lim= ited no matter how subnet is spread and how diverse servers are virtualized= .=20 Linda > -----Original Message----- > From: David Allan I [mailto:david.i.allan@ericsson.com] > Sent: Friday, September 27, 2013 4:41 PM > To: Linda Dunbar; Ted Lemon > Cc: int-area@ietf.org > Subject: RE: [Int-area] Call for adoption of draft-nachum-sarp-06.txt >=20 > HI Linda: >=20 > You wrote: > [Linda] The proposed "proxy gateway" only represents the IP > applications' end hosts address by the "gateway address" (i.e. only > proxy them when the hosts issues ARP/ND). > For CFM, QCN and non-IP E2E, no proxy address is used. >=20 > Then I still need a complete MAC table for these things to work as I > need both end system AND ARP proxy addresses in all FDBs, so the ARP > proxy has only added to the FDB size, not diminished it. While > rendering my OAM protocols as less effective as they are not > instrumenting the path taken by IP traffic. They bypass the ARP proxy > logic. >=20 > Make sense? > Dave >=20 > -----Original Message----- > From: Linda Dunbar [mailto:linda.dunbar@huawei.com] > Sent: Friday, September 27, 2013 2:36 PM > To: David Allan I; Ted Lemon > Cc: int-area@ietf.org > Subject: RE: [Int-area] Call for adoption of draft-nachum-sarp-06.txt >=20 > David, >=20 > > -----Original Message----- > > > > What this means is any non-IP E2E protocol (CFM, QCN etc.) is broken > > and how one would instrument and fault sectionalize this network is > > unclear. >=20 >=20 > Linda >=20 >=20 > It looks like an Ethernet subnet but does not behave like one. > > > > Again hope this helps > > Dave > > > > -----Original Message----- > > From: Ted Lemon [mailto:ted.lemon@nominum.com] > > Sent: Friday, September 27, 2013 1:45 PM > > To: David Allan I > > Cc: Brian Haberman; int-area@ietf.org > > Subject: Re: [Int-area] Call for adoption of draft-nachum-sarp-06.txt > > > > On Sep 27, 2013, at 4:40 PM, David Allan I > > > > wrote: > > > Although the list discussion around my comments was an interesting > > and informative one, I did not consider my concerns addressed. An L3 > > ARP proxy driving a 1:N MAC-NAT breaks a lot of stuff. IMO that is > > rather fundamental and more discussion would not change the facts. In > > that regard I cannot see how my concerns can be addressed by SARP as > > it stands... > > > > I realize that for the people presenting these points it is obvious > > why a L2 nat is a bad idea, and I think I know at least one reason > why > > they feel this way, but it would help to actually walk the working > > group through it rather than just pointing out that it is so, because > > I suspect that there are plenty of working group participants who are > > not experts on the topic, but would understand readily if the > concerns > > were explained in more detail. > > > > _______________________________________________ > > Int-area mailing list > > Int-area@ietf.org > > https://www.ietf.org/mailman/listinfo/int-area From david.i.allan@ericsson.com Fri Sep 27 15:27:33 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF57521F9E2B for ; Fri, 27 Sep 2013 15:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nKAYwSwVJMHZ for ; Fri, 27 Sep 2013 15:27:28 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2D36621F9E0D for ; Fri, 27 Sep 2013 15:27:27 -0700 (PDT) X-AuditID: c618062d-b7fda8e0000024c6-25-5246064d385d Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 43.44.09414.D4606425; Sat, 28 Sep 2013 00:27:25 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.02.0328.009; Fri, 27 Sep 2013 18:27:25 -0400 From: David Allan I To: Linda Dunbar , Ted Lemon Thread-Topic: [Int-area] Call for adoption of draft-nachum-sarp-06.txt Thread-Index: AQHOu7wa4515xuMxuU+ibz4KXnOs7JnaCFrwgABINgD//70+MIAAUOwA//+9gTCAAEd2AP//xfBw Date: Fri, 27 Sep 2013 22:27:24 +0000 Message-ID: References: <52143AFF.3060403@ericsson.com> <5245E3AD.5060706@innovationslab.net> <1504D45B-0AF8-4B35-BF64-D7DD913A37FD@nominum.com> <4A95BA014132FF49AE685FAB4B9F17F645BD0686@dfweml509-mbx.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645BD06C2@dfweml509-mbx.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645BD06C2@dfweml509-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBLMWRmVeSWpSXmKPExsUyuXRPiK4vm1uQwbRlehY3Zt1ksbjbMpHJ Ymt3rAOzR8uRt6weS5b8ZPJ4fWA+awBzFJdNSmpOZllqkb5dAlfG+rXn2AqWylWs3HiXtYFx nkQXIyeHhICJxLQ751ghbDGJC/fWs3UxcnEICRxllHg1cReUs5xR4u37ZkaQKjYBA4k9/7+A 2SICvhKrtiwCs5kFtCV2TjzKDGILC7hKzD12lRWixk1i5boJUPVREts+vGYCsVkEVCUOHVsO FucFmvPp0jMmiGVvmCVunDwK1swpECbRvfosWAMj0HnfT61hglgmLnHryXwmiLMFJJbsOc8M YYtKvHz8D+odZYklT/azQNTrSCzY/YkN5tBlC18zQywWlDg58wnLBEaxWUjGzkLSMgtJyywk LQsYWVYxcpQWp5blphsZbGIExs4xCTbdHYx7XloeYpTmYFES5/3y1jlISCA9sSQ1OzW1ILUo vqg0J7X4ECMTB6dUA6PEczMd0fXzMmJtWg695KquXO8y7fKfKevPrdjpcyA50WfzoR2xemnX lc+w22xd+yrzR/1hme0LJoorNZ9/9KLgX/y9jOWvveav3zJJZ+c7vtD3/zf8+DL/pw3bM4Zn 6X55feK3l7+ojEh990u3JHpTaJW3TqukpF76Cj61axtbdpW8s8/TvCurxFKckWioxVxUnAgA 2pEd22sCAAA= Cc: "int-area@ietf.org" Subject: Re: [Int-area] Call for adoption of draft-nachum-sarp-06.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 22:27:33 -0000 Hi Linda: This sounds like the location of a proxy could be arbitrary in an Ethernet = network, is this what you are suggesting? Thanks Dave -----Original Message----- From: Linda Dunbar [mailto:linda.dunbar@huawei.com]=20 Sent: Friday, September 27, 2013 2:54 PM To: David Allan I; Ted Lemon Cc: int-area@ietf.org Subject: RE: [Int-area] Call for adoption of draft-nachum-sarp-06.txt David,=20 The CFM, OAM are exchanged among switches. The number of switches are limit= ed.=20 The proxy gateway is to enable edge nodes not to have individual addresses = for end hosts in remote domains. The edge nodes only need to have the remot= e gateway addresses and remote switches' addresses. Those addresses are lim= ited no matter how subnet is spread and how diverse servers are virtualized= .=20 Linda > -----Original Message----- > From: David Allan I [mailto:david.i.allan@ericsson.com] > Sent: Friday, September 27, 2013 4:41 PM > To: Linda Dunbar; Ted Lemon > Cc: int-area@ietf.org > Subject: RE: [Int-area] Call for adoption of draft-nachum-sarp-06.txt >=20 > HI Linda: >=20 > You wrote: > [Linda] The proposed "proxy gateway" only represents the IP=20 > applications' end hosts address by the "gateway address" (i.e. only=20 > proxy them when the hosts issues ARP/ND). > For CFM, QCN and non-IP E2E, no proxy address is used. >=20 > Then I still need a complete MAC table for these things to work as I=20 > need both end system AND ARP proxy addresses in all FDBs, so the ARP=20 > proxy has only added to the FDB size, not diminished it. While=20 > rendering my OAM protocols as less effective as they are not=20 > instrumenting the path taken by IP traffic. They bypass the ARP proxy=20 > logic. >=20 > Make sense? > Dave >=20 > -----Original Message----- > From: Linda Dunbar [mailto:linda.dunbar@huawei.com] > Sent: Friday, September 27, 2013 2:36 PM > To: David Allan I; Ted Lemon > Cc: int-area@ietf.org > Subject: RE: [Int-area] Call for adoption of draft-nachum-sarp-06.txt >=20 > David, >=20 > > -----Original Message----- > > > > What this means is any non-IP E2E protocol (CFM, QCN etc.) is broken=20 > > and how one would instrument and fault sectionalize this network is=20 > > unclear. >=20 >=20 > Linda >=20 >=20 > It looks like an Ethernet subnet but does not behave like one. > > > > Again hope this helps > > Dave > > > > -----Original Message----- > > From: Ted Lemon [mailto:ted.lemon@nominum.com] > > Sent: Friday, September 27, 2013 1:45 PM > > To: David Allan I > > Cc: Brian Haberman; int-area@ietf.org > > Subject: Re: [Int-area] Call for adoption of=20 > > draft-nachum-sarp-06.txt > > > > On Sep 27, 2013, at 4:40 PM, David Allan I=20 > > > > wrote: > > > Although the list discussion around my comments was an interesting > > and informative one, I did not consider my concerns addressed. An L3=20 > > ARP proxy driving a 1:N MAC-NAT breaks a lot of stuff. IMO that is=20 > > rather fundamental and more discussion would not change the facts.=20 > > In that regard I cannot see how my concerns can be addressed by SARP=20 > > as it stands... > > > > I realize that for the people presenting these points it is obvious=20 > > why a L2 nat is a bad idea, and I think I know at least one reason > why > > they feel this way, but it would help to actually walk the working=20 > > group through it rather than just pointing out that it is so,=20 > > because I suspect that there are plenty of working group=20 > > participants who are not experts on the topic, but would understand=20 > > readily if the > concerns > > were explained in more detail. > > > > _______________________________________________ > > Int-area mailing list > > Int-area@ietf.org > > https://www.ietf.org/mailman/listinfo/int-area From talmi@marvell.com Mon Sep 30 22:26:35 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 722AD21F99F0 for ; Mon, 30 Sep 2013 22:26:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OfI5aOafKIzg for ; Mon, 30 Sep 2013 22:26:29 -0700 (PDT) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7AC21F8C7C for ; Mon, 30 Sep 2013 22:26:29 -0700 (PDT) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id r915QSgn007664; Mon, 30 Sep 2013 22:26:28 -0700 Received: from sc-owa01.marvell.com ([199.233.58.136]) by mx0b-0016f401.pphosted.com with ESMTP id 1f77dtk713-20 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 30 Sep 2013 22:26:28 -0700 Received: from YK-HUB02.marvell.com (10.4.102.52) by sc-owa01.marvell.com (10.93.76.21) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 30 Sep 2013 22:26:23 -0700 Received: from IL-MB01.marvell.com ([10.4.102.53]) by YK-HUB02.marvell.com ([10.4.102.52]) with mapi; Tue, 1 Oct 2013 07:26:20 +0200 From: Tal Mizrahi To: Brian Haberman , "int-area@ietf.org" Date: Tue, 1 Oct 2013 08:26:19 +0200 Thread-Topic: [Int-area] Call for adoption of draft-nachum-sarp-06.txt Thread-Index: Ac67vCtWHlAPZefQTpaYUJglFm57yQCqdxHg Message-ID: <74470498B659FA4687F0B0018C19A89C01B87D606A2F@IL-MB01.marvell.com> References: <52143AFF.3060403@ericsson.com> <5245E3AD.5060706@innovationslab.net> In-Reply-To: <5245E3AD.5060706@innovationslab.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-10-01_02:2013-09-30, 2013-10-01, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1309300190 Subject: Re: [Int-area] Call for adoption of draft-nachum-sarp-06.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 05:26:35 -0000 Hi Brian, Thanks for your inputs. > Given the length of time that this draft has been around, are there imple= mentations? Speaking from a chip vendor's perspective: yes, the data plane aspects of S= ARP are implemented in some of our silicons. Obviously SARP also requires f= unctionality in the control plane, but since this functionality would typic= ally be implemented in software, as a chip vendor it is less relevant for u= s. Tal Mizrahi. Marvell. -----Original Message----- From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] On Behal= f Of Brian Haberman Sent: Friday, September 27, 2013 11:00 PM To: int-area@ietf.org Subject: Re: [Int-area] Call for adoption of draft-nachum-sarp-06.txt Suresh, Sorry for the late feedback, but there are some issues that should be = discussed. Some of the following are my views of the document and others a= re summarized based on feedback from others. To be clear, the following comments are being made as an individual pa= rticipant. 1. The idea of creating a Layer-2 NAT is rather unappealing. Many folks in= the IETF understand the rash of issues that arise with this type of approa= ch. It appears that is what happens with SARP (at least in some instance). 2. It is unclear *who* would want to build (or has built) a layer-2 network= at this size and sees the application of proxies/NATs as the solution to s= caling issues. Are there operators who have built networks in this way who= can clearly explain the problem space? This comes about from the outcome = of ARMD. 3. Given the length of time that this draft has been around, are there impl= ementations? 4. How does this approach deal with non-IP traffic? Now with my AD hat on... I believe there are some issues raised by Dave Allan that have been le= ft unanswered, though Dave can correct me if I am wrong. Consensus does no= t require unanimity, but it does require that all concerns raised be addres= sed. Regards, Brian From talmi@marvell.com Mon Sep 30 23:02:17 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25F5C21F995F for ; Mon, 30 Sep 2013 23:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.645 X-Spam-Level: X-Spam-Status: No, score=-1.645 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hMhPAweqr+dR for ; Mon, 30 Sep 2013 23:02:12 -0700 (PDT) Received: from mx0a-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC2421F98AC for ; Mon, 30 Sep 2013 23:02:12 -0700 (PDT) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id r9161saw014492; Mon, 30 Sep 2013 23:02:04 -0700 Received: from sc-owa02.marvell.com ([199.233.58.137]) by mx0a-0016f401.pphosted.com with ESMTP id 1f72g2c8uf-1 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 30 Sep 2013 23:02:04 -0700 Received: from YK-HUB02.marvell.com (10.4.102.52) by sc-owa02.marvell.com (10.93.76.22) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 30 Sep 2013 23:02:03 -0700 Received: from IL-MB01.marvell.com ([10.4.102.53]) by YK-HUB02.marvell.com ([10.4.102.52]) with mapi; Tue, 1 Oct 2013 08:02:01 +0200 From: Tal Mizrahi To: Thomas Narten , Suresh Krishnan Date: Tue, 1 Oct 2013 09:01:59 +0200 Thread-Topic: [Int-area] Call for adoption of draft-nachum-sarp-06.txt Thread-Index: Ac67yKKeTip0csJIS4iiIMX8/mE7VwCniQ5Q Message-ID: <74470498B659FA4687F0B0018C19A89C01B87D606A42@IL-MB01.marvell.com> References: <52143AFF.3060403@ericsson.com> <201309272128.r8RLSPVP002634@cichlid.raleigh.ibm.com> In-Reply-To: <201309272128.r8RLSPVP002634@cichlid.raleigh.ibm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-10-01_03:2013-09-30, 2013-10-01, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1309300194 Cc: Internet Area Subject: Re: [Int-area] Call for adoption of draft-nachum-sarp-06.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 06:02:17 -0000 Hi Thomas, Thanks for taking the time to review the draft. > However, at least initially, SARP would be implemented in the service pro= cessor (consuming CPU cycles). It would be years (if ever) before silicon w= ould implement this. Speaking as a chip vendor: our existing silicons support the data plane fun= ctionality of SARP. In fact, I am taking a wild guess (but I may be wrong) = that some of our competitors' silicons that support IP/TRILL routing also s= upport the data plane functionality of SARP, simply because from a data pla= ne perspective SARP performs a somewhat similar functionality: address look= up + MAC address replacement. In general, I don't think anyone intended for the data plane of SARP to be = implemented in software. > As DaveA points out, FDB tables are large on chips these days. > silicon will just get better and have bigger FDB tables... Right, but the *demand* for bigger FDB tables is also increasing, even more= rapidly. Moreover, the FDB table is typically the biggest table in a switc= h silicon, which means that a large FDB table significantly increases the c= ost of the silicon. BTW, I took a look at RFC6820 (I am sure you are familiar with this documen= t :) ), and it certainly addresses MAC table size as a real issue: " When L= 3 extends only to aggregation switches (see Section 6.4.2), however, MAC ta= ble size limitations can be a real issue." Thanks, Tal. -----Original Message----- From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] On Behal= f Of Thomas Narten Sent: Saturday, September 28, 2013 12:28 AM To: Suresh Krishnan Cc: Internet Area Subject: Re: [Int-area] Call for adoption of draft-nachum-sarp-06.txt Given the flurry of mail, I went back and reviewed my notes on this documen= t. I believe I understand the problem (reduce size of FDB), but am skeptical t= hat solving it via the approach in this document is worthwhile. 1) As DaveA points out, FDB tables are large on chips these days. However, = at least initially, SARP would be implemented in the service processor (con= suming CPU cycles). It would be years (if ever) before silicon would implem= ent this. But in parallel, silicon will just get better and have bigger FDB= tables... Moreover, the SARP motivation section specifically cites a short= age of processor cycles as a problem ... but doing SARP in software will in= crease the demands on the CPU... its unclear to me that the increased CPU = burdens SARP implies would be offset by the reduced amount of ARP processin= g that the solution is hoping will result... I.e., at least in the short te= rm, it's unclear that SARP would actually help in practice. 2) Doing L2 NAT at line rates (an absolute requirement for edge devices) will only happen if this is done in silicon. I don't see that happ= ening unless there is strong support from vendors/operators/chip makers... = Software based solutions simply will not have sufficient performance. I thi= nk the IEEE would be a better place to have the discussion about what L2 ch= ip makers are willing to implement... 3) Only works for IP. Doesn't work for non-IP L2. Doesn't that only solve p= art of the problem? 4) High availability is complex (but presumably also necessary). It smells = a lot like multi-chassis LAG (with the need to synchronize state between ti= ghtly-coupled peers). Although IEEE is working in this general area now, th= ere are tons of vendor-specific solutions for doing this at L2. Do we reall= y want to tackle standardizing this in the IETF? Isn't the relevant expert= ise for this general area in IEEE? 5) This solution touchs on both L2 (NATing L2 addresses) and L3 (ARPing for= IP addresses). We absolutely would need coordinate with IEEE before decidi= ng to take on this work. 6) ARP caching will be a tradeoff. You want to cache responses for better p= erformance, but long cache timeouts will result in black holes after VMs mo= ve. There is no great answer here. I expect long timeouts to be unacceptabl= e operationally, which means that the benefits of caching will be limited (= and these benefits are the key value proposition of this approach). It is r= eally hard to estimate whether the benefits will be sufficient in practice.= Gratuitous ARPs can help, but they are not reliable, so they will help, bu= t have limitations... 7) I haven't fully worked this out, but I wonder if loops can form between = proxies. There is the notion that when a VM moves, proxies will need to upd= ate their tables. But careful analysis will be needed to be sure that one c= an't ever have loops where proxies end up pointing to each other. And since= the packets are L2 (with no TTL), such loops would be disasterous. (Note p= oint 6: we are using heuristics (like gratuitous ARP) to get tables to conv= erge after a change. Heuristics tend to have transient inconsistencies.. i.= e., possibly leading to loops.) Again, overall, I understand the generic problem and that it would be nice = to have a solution. However, I don't see a simple solution here. I see a fa= ir amount of complexity, and I'm skeptical that it's worth it (e.g., when t= he next gen of silicon will just have a larger FDB). What I'd really like to see (before having the IETF commit to this work) is: 1) operators who are feeling the pain described in the document stepping fo= rward and saying they think the solution being proposed is something they w= ould be willing to deploy and is better than other approaches they have in = their toolkit. 2) Vendors (including silicon) saying they see the need for this and think = the would implement it. Thomas _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area