From Internet-Drafts@ietf.org Sun Mar 6 19:15:03 2011 Return-Path: X-Original-To: forces@core3.amsl.com Delivered-To: forces@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B3A23A68BA; Sun, 6 Mar 2011 19:15:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qNa5LIcWaC2; Sun, 6 Mar 2011 19:15:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 704013A68CC; Sun, 6 Mar 2011 19:15:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110307031502.31896.62835.idtracker@localhost> Date: Sun, 06 Mar 2011 19:15:02 -0800 Cc: forces@ietf.org Subject: [forces] I-D Action:draft-ietf-forces-interop-00.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 03:15:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Forwarding and Control Element Separation Working Group of the IETF. Title : Interoperability Report for Forwarding and Control Element Separation (ForCES) Author(s) : W. Wang, et al. Filename : draft-ietf-forces-interop-00.txt Pages : 34 Date : 2011-03-06 This document captures test results from the second Forwarding and control Element Separation (ForCES) interop testing which took place March 24-25, 2011 at the Internet Technology Lab (ITL) of Zhejiang Gongshang University in China. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-forces-interop-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-forces-interop-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-06190915.I-D@ietf.org> --NextPart-- From ogawa.kentaro@lab.ntt.co.jp Mon Mar 7 21:46:26 2011 Return-Path: X-Original-To: forces@core3.amsl.com Delivered-To: forces@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2F5E28C0D9 for ; Mon, 7 Mar 2011 21:46:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.369 X-Spam-Level: ** X-Spam-Status: No, score=2.369 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jqFOceukxlzT for ; Mon, 7 Mar 2011 21:46:25 -0800 (PST) Received: from tama500.ecl.ntt.co.jp (tama500.ecl.ntt.co.jp [129.60.39.148]) by core3.amsl.com (Postfix) with ESMTP id CB6EB3A6882 for ; Mon, 7 Mar 2011 21:46:24 -0800 (PST) Received: from mfs5.rdh.ecl.ntt.co.jp (mfs5.rdh.ecl.ntt.co.jp [129.60.39.144]) by tama500.ecl.ntt.co.jp (8.14.4/8.14.4) with ESMTP id p285lceB017016 for ; Tue, 8 Mar 2011 14:47:38 +0900 (JST) Received: from mfs5.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id EA8EB6D40 for ; Tue, 8 Mar 2011 14:47:37 +0900 (JST) Received: from imail2.m.ecl.ntt.co.jp (imail2-mgr.m.ecl.ntt.co.jp [129.60.144.42]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id E42AB6D3F for ; Tue, 8 Mar 2011 14:47:37 +0900 (JST) Received: from [IPv6:::1] ([129.60.80.52]) by imail2.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id p285lEjO010449 for ; Tue, 8 Mar 2011 14:47:37 +0900 Message-ID: <4D75C34E.8000401@lab.ntt.co.jp> Date: Tue, 08 Mar 2011 14:49:02 +0900 From: Kentaro Ogawa User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; ja; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: forces@ietf.org References: <201102250841152030006@mail.zjgsu.edu.cn> In-Reply-To: <201102250841152030006@mail.zjgsu.edu.cn> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [forces] xml definition issues that need to be discussed X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 05:46:26 -0000 Hi, All Through the interop test, I and Ming discuss about xml definition of data type of IPv4NetMask, component ID=2 in Portv4AddrInforType. We agree that it's appropriate to change the definition from IPv4NetMask IPv4 net mask length uint32 to IPv4PrefixLen IPv4 net mask length uchar because to unify the style with other data types. How about reflecting the change to LFB-lib04 draft? cheers, Ken From hadi@mojatatu.com Tue Mar 8 04:38:01 2011 Return-Path: X-Original-To: forces@core3.amsl.com Delivered-To: forces@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A76E3A6810 for ; Tue, 8 Mar 2011 04:38:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.327 X-Spam-Level: X-Spam-Status: No, score=-101.327 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_37=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15ZjYQHSZCbt for ; Tue, 8 Mar 2011 04:38:00 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 4BC2B3A63D2 for ; Tue, 8 Mar 2011 04:38:00 -0800 (PST) Received: by vxg33 with SMTP id 33so5474295vxg.31 for ; Tue, 08 Mar 2011 04:39:14 -0800 (PST) Received: by 10.220.176.139 with SMTP id be11mr1275512vcb.168.1299587953192; Tue, 08 Mar 2011 04:39:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.175.135 with HTTP; Tue, 8 Mar 2011 04:38:53 -0800 (PST) In-Reply-To: <4D75C34E.8000401@lab.ntt.co.jp> References: <201102250841152030006@mail.zjgsu.edu.cn> <4D75C34E.8000401@lab.ntt.co.jp> From: Jamal Hadi Salim Date: Tue, 8 Mar 2011 07:38:53 -0500 Message-ID: To: Kentaro Ogawa Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: forces@ietf.org Subject: Re: [forces] xml definition issues that need to be discussed X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 12:38:01 -0000 Hi Ken, Yes - that makes sense. Note that IPv4NetMask is still defined in BaseTypeLibrary and the Portv4AddrInforType is the only place it is used. It may make sense to still leave it defined since a netmask is a useful definition to have. I have many comments on LFBlib that i was waiting for the interop to complete before starting any discussion - should i start posting= ? cheers, jamal On Tue, Mar 8, 2011 at 12:49 AM, Kentaro Ogawa wrote: > Hi, All > > Through the interop test, I and Ming discuss about xml definition of > data type of IPv4NetMask, component ID=3D2 in Portv4AddrInforType. > > We agree that it's appropriate to change the definition > from > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 IPv4NetMask > =A0 =A0 =A0 =A0 =A0 =A0 =A0 IPv4 net mask length > =A0 =A0 =A0 =A0 =A0 =A0 =A0 uint32 > =A0 =A0 =A0 =A0 =A0 =A0 > to > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 IPv4PrefixLen > =A0 =A0 =A0 =A0 =A0 =A0 =A0 IPv4 net mask length > =A0 =A0 =A0 =A0 =A0 =A0 =A0 uchar > =A0 =A0 =A0 =A0 =A0 =A0 > > because to unify the style with other data types. > How about reflecting the change to LFB-lib04 draft? > > cheers, > Ken > > > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces > From ogawa.kentaro@lab.ntt.co.jp Tue Mar 8 20:35:50 2011 Return-Path: X-Original-To: forces@core3.amsl.com Delivered-To: forces@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 756023A6812 for ; Tue, 8 Mar 2011 20:35:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.439 X-Spam-Level: * X-Spam-Status: No, score=1.439 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xy4nFX-XfhIE for ; Tue, 8 Mar 2011 20:35:49 -0800 (PST) Received: from tama500.ecl.ntt.co.jp (tama500.ecl.ntt.co.jp [129.60.39.148]) by core3.amsl.com (Postfix) with ESMTP id 098043A680E for ; Tue, 8 Mar 2011 20:35:48 -0800 (PST) Received: from mfs5.rdh.ecl.ntt.co.jp (mfs5.rdh.ecl.ntt.co.jp [129.60.39.144]) by tama500.ecl.ntt.co.jp (8.14.4/8.14.4) with ESMTP id p294b4fR016127; Wed, 9 Mar 2011 13:37:04 +0900 (JST) Received: from mfs5.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 196A36D40; Wed, 9 Mar 2011 13:37:04 +0900 (JST) Received: from imail2.m.ecl.ntt.co.jp (imail2-mgr.m.ecl.ntt.co.jp [129.60.144.42]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 133626D3C; Wed, 9 Mar 2011 13:37:04 +0900 (JST) Received: from [IPv6:::1] ([129.60.80.52]) by imail2.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id p294am42032007; Wed, 9 Mar 2011 13:36:57 +0900 Message-ID: <4D77044C.8010700@lab.ntt.co.jp> Date: Wed, 09 Mar 2011 13:38:36 +0900 From: Kentaro Ogawa User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; ja; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Jamal Hadi Salim References: <201102250841152030006@mail.zjgsu.edu.cn> <4D75C34E.8000401@lab.ntt.co.jp> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: forces@ietf.org Subject: Re: [forces] xml definition issues that need to be discussed X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 04:35:50 -0000 Hi Jamal, I think we can start the discussion because ongoing interop may not occur the new issue affecting to the LFB definitions. cheers, Ken -------- Original Message -------- > Hi Ken, > > Yes - that makes sense. > Note that IPv4NetMask is still defined in BaseTypeLibrary and > the Portv4AddrInforType is the only place it is used. It may make > sense to still leave it defined since a netmask is a useful definition > to have. > > I have many comments on LFBlib that i was waiting for the > interop to complete before starting any discussion - should i start posting? > > cheers, > jamal > > On Tue, Mar 8, 2011 at 12:49 AM, Kentaro Ogawa > wrote: >> Hi, All >> >> Through the interop test, I and Ming discuss about xml definition of >> data type of IPv4NetMask, component ID=2 in Portv4AddrInforType. >> >> We agree that it's appropriate to change the definition >> from >> >> IPv4NetMask >> IPv4 net mask length >> uint32 >> >> to >> >> IPv4PrefixLen >> IPv4 net mask length >> uchar >> >> >> because to unify the style with other data types. >> How about reflecting the change to LFB-lib04 draft? >> >> cheers, >> Ken >> >> >> _______________________________________________ >> forces mailing list >> forces@ietf.org >> https://www.ietf.org/mailman/listinfo/forces >> > > From hadi@mojatatu.com Wed Mar 9 04:40:17 2011 Return-Path: X-Original-To: forces@core3.amsl.com Delivered-To: forces@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23C543A6813 for ; Wed, 9 Mar 2011 04:40:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.844 X-Spam-Level: X-Spam-Status: No, score=-101.844 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ul6CGsGQBW0D for ; Wed, 9 Mar 2011 04:40:16 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 4C6183A695E for ; Wed, 9 Mar 2011 04:40:16 -0800 (PST) Received: by vws6 with SMTP id 6so510235vws.31 for ; Wed, 09 Mar 2011 04:41:32 -0800 (PST) Received: by 10.220.65.89 with SMTP id h25mr1615399vci.273.1299674492108; Wed, 09 Mar 2011 04:41:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.175.135 with HTTP; Wed, 9 Mar 2011 04:41:12 -0800 (PST) From: Jamal Hadi Salim Date: Wed, 9 Mar 2011 07:41:12 -0500 Message-ID: To: forces@ietf.org Content-Type: multipart/mixed; boundary=001485e0ed706cff43049e0c0cdd Subject: [forces] LFBLib v3: comment #1 X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 12:40:17 -0000 --001485e0ed706cff43049e0c0cdd Content-Type: text/plain; charset=ISO-8859-1 LFBLib authors, I am going to try and post one comment a day as long as i am getting some responses back. Here's the first comment on section 3. 1) There is mention of port LFB which doesnt exist in the draft. Perhaps somewhere we need to say that a "port" constitutes a unique combination of PHY and MAC combo. 2) There is only mention of dynamic routing protocols on page 8. ForCES can work with static routing. 3) Figure 1 is missing a few input/outputs/errors for all LFBs depicted in that diagram. It probably makes sense for the sake of simplicity to illustrate the important pieces like you did; however, if that is what you are intending then please state so in leading text. 4) To avoid the diagram being mangled I am attaching a txt file to illustrate a small correction. cheers, jamal --001485e0ed706cff43049e0c0cdd Content-Type: text/plain; charset=US-ASCII; name="sec3-dig.txt" Content-Disposition: attachment; filename="sec3-dig.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gl28l0si0 RmlndXJlIDEgaW5kZW50YXRpb246Ci4uCi4uCi4uCiAgICAgICAgICAgICAgICAgKy0tLS0tKyAg IHwgICB8IHwgICBJUHY0ICAgICAgICAgICAgICAgICAgKy0tLSsgIHwgfAogICAgICAgICAgICAg ICAgIHwgICAgIHwgICB8ICAgfCB8ICAgVmFsaWRhdG9yICAgICAgICAgICAgICBJUHY0ICB8IHwK ICAgICAgICArLS0tLS0rICB8RXRoZXJ8ICAgfCAgIHwtKyAgICAgICAgICAgICAgICAgICAgICAg IE5leHRIb3AgfCB8CiAgICAgICAgfCAgICAgfC0+fE1BQ0lufC0tPnwgICB8SVB2NCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHwgfAogICAgICAgIHwgICAgIHwgIHwgICAgIHwgICB8ICAg fC0tLS0tPklQdjYgUGFja2V0cyAgICAgICAgICAgICAgICB8IHwKICAgICAgICB8RXRoZXJ8ICAr LS0tLS0rICAgKy0tLSsgICAgICAgICAgICAgICstLS0tKyAgICAgICAgICAgICAgfCB8CiAgICAg ICAgfFBIWSAgfCAgICAgICAgICAgRXRoZXIgICAgICAgICAgICAgICB8ICAgIHwgICAgICAgICAg ICAgIHwgfAogICAgICAgIHxDb3AgIHwgICAgICAgICAgIENsYXNzaWZpZXIgICAgICAgICAgfCAg ICB8ICAgKy0tLS0tLS0rICB8IHwKICAgICAgICB8I24gICB8ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwgICAgfCAgIHwgICAgICAgfCAgfCB8CiAgICAgICAgfCAgICAgfCAgICAgICAg ICAgICAgICArLS0tLS0tKyAgICAgICB8ICAgIHw8LS18IEV0aGVyIHw8LSsgfAogICAgICAgIHwg ICAgIHwgICAgICAgICAgICAgICAgfCAgICAgIHw8LS0tLS0tfCAgICB8ICAgfCBFbmNhcCB8ICAg IHwKICAgICAgICB8ICAgICB8PC0tLS0tLS0tLS0tLS0tLXxFdGhlciB8ICAgIC4uLnwgICAgfCAg ICstLS0tLS0tKyAgICB8CiAgICAgICAgfCAgICAgfCAgICAgICAgICAgICAgICB8TUFDT3V0fCAg ICstLS18ICAgIHwgICAgICAgICAgICAgICAgfAogICAgICAgIHwgICAgIHwgICAgICAgICAgICAg ICAgfCAgICAgIHwgICB8ICAgKy0tLS0rICAgICAgICAgICAgICAgIHwKICAgICAgICArLS0tLS0r ICAgICAgICAgICAgICAgICstLS0tLS0rICAgfCBCYXNpY01ldGFkYXRhRGlzcGF0Y2ggICB8CiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tKwoKCkNhbiB5b3UgaW5kZW50IEV0aGVyTUFDT3V0IHNvIGl0IGxpbmVzIHVwIHdp dGggRXRoZXJNQUNJbj8KQWxzbyBhcHBseSB0byBCYXNpY01ldGFkYXRhRGlzcGF0Y2ggdnMgRXRo ZXJDbGFzc2lmaWVyIGFuZApCYXNpY01ldGFkYXRhRGlzcGF0Y2ggdnMgSVB2NFZhbGlkYXRvciBl dGMKCg== --001485e0ed706cff43049e0c0cdd-- From wmwang2001@hotmail.com Wed Mar 9 18:45:08 2011 Return-Path: X-Original-To: forces@core3.amsl.com Delivered-To: forces@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74C183A67F6 for ; Wed, 9 Mar 2011 18:45:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.73 X-Spam-Level: X-Spam-Status: No, score=-97.73 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FORGED_MUA_OUTLOOK=3.116, MIME_BASE64_TEXT=1.753, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aVGRuZ7V+myG for ; Wed, 9 Mar 2011 18:45:07 -0800 (PST) Received: from blu0-omc4-s4.blu0.hotmail.com (blu0-omc4-s4.blu0.hotmail.com [65.55.111.143]) by core3.amsl.com (Postfix) with ESMTP id 6C4693A67EC for ; Wed, 9 Mar 2011 18:45:07 -0800 (PST) Received: from BLU0-SMTP192 ([65.55.111.135]) by blu0-omc4-s4.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Mar 2011 18:46:24 -0800 X-Originating-IP: [221.12.10.218] X-Originating-Email: [wmwang2001@hotmail.com] Message-ID: Received: from ZJGSUIEE ([221.12.10.218]) by BLU0-SMTP192.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Mar 2011 18:46:23 -0800 From: "Wang,Weiming" To: "Jamal Hadi Salim" , References: Date: Thu, 10 Mar 2011 10:46:26 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-OriginalArrivalTime: 10 Mar 2011 02:46:23.0320 (UTC) FILETIME=[57D17D80:01CBDECD] Subject: Re: [forces] LFBLib v3: comment #1 X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 02:45:08 -0000 SGkgSmFtYWwsDQoNClRoa3MgZm9yIHRoZSBjb21tZW50cy4gUGxzIHNlZSBpbmxpbmUgdGhlIHJl cGx5LiANCg0KdGhhbmtzLA0KV2VpbWluZw0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0t IA0KRnJvbTogIkphbWFsIEhhZGkgU2FsaW0iIDxoYWRpQG1vamF0YXR1LmNvbT4NCg0KPiBMRkJM aWIgYXV0aG9ycywNCj4gDQo+IEkgYW0gZ29pbmcgdG8gdHJ5IGFuZCBwb3N0IG9uZSBjb21tZW50 IGEgZGF5IGFzIGxvbmcNCj4gYXMgaSBhbSBnZXR0aW5nIHNvbWUgcmVzcG9uc2VzIGJhY2suDQo+ IA0KPiBIZXJlJ3MgdGhlIGZpcnN0IGNvbW1lbnQgb24gc2VjdGlvbiAzLg0KPiANCj4gMSkgVGhl cmUgaXMgbWVudGlvbiBvZiBwb3J0IExGQiB3aGljaCBkb2VzbnQgZXhpc3QgaW4gdGhlIGRyYWZ0 Lg0KPiBQZXJoYXBzIHNvbWV3aGVyZSB3ZSBuZWVkIHRvIHNheSB0aGF0IGEgInBvcnQiIGNvbnN0 aXR1dGVzDQo+IGEgdW5pcXVlIGNvbWJpbmF0aW9uIG9mIFBIWSBhbmQgTUFDIGNvbWJvLg0KDQpQ bHMgcmV2aWV3IHRoZSBmb2xsb2luZyB0ZXh0IG1vZGlmaWNhdGlvbiB0byBzZWUgaWYgaXQgaXMg ZW5vdWdoPyANCg0KLS0tLS1vcmlnaW5hbDogDQpJbiBhIHR5cGljYWwgcGFja2V0IGZsb3cgd2l0 aGluIGFuIElQIHJvdXRlciwgYSBwb3J0IExGQiByZWNlaXZlcw0KICAgcGFja2V0cyBhbmQgZGVj YXBzdWxhdGVzIHRoZW0gdG8gZm9ybSBJUCBsZXZlbCBwYWNrZXRzLiAgRGlmZmVyZW50DQogICBw b3J0IG1lZGlhIHdpbGwgaGF2ZSBkaWZmZXJlbnQgd2F5cyB0byBhY2hpZXZlIHRoZSBnb2FsIG9m DQogICBkZWNhcHN1bGF0aW5nIG1lZGlhLXNwZWNpZmljIGhlYWRlcnMgYW5kIHRoZXJlZm9yZSBM RkJzIGZvciB2YXJpb3VzDQogICBtZWRpYSB3aWxsIGhhdmUgdG8gYmUgZGVmaW5lZCBhbHRob3Vn aCB0aGlzIGRvY3VtZW50IHN0aWNrcyB0bw0KICAgZXRoZXJuZXQgb25seS4gIElQIHBhY2tldHMg ZW1hbmF0aW5nIGZyb20gcG9ydCBMRkJzIGFyZSB0aGVuDQogICBwcm9jZXNzZWQgYnkgYSB2YWxp ZGF0aW9uIExGQiBiZWZvcmUgYmVpbmcgZnVydGhlciBmb3J3YXJkZWQgdG8gdGhlDQogICBuZXh0 IExGQi4gDQoNCi0tLS1jaGFuZ2VkIHRvOiANCkluIGEgdHlwaWNhbCBwYWNrZXQgZmxvdyB3aXRo aW4gYW4gSVAgcm91dGVyLCBhbiBMRkIgd2hpY2ggYWJzdHJhY3RzIGEgbWVkaWEgcG9ydCByZWNl aXZlcyBwYWNrZXRzIGFuZCBkZWNhcHN1bGF0ZXMgdGhlbSB0byBmb3JtIElQIGxldmVsIHBhY2tl dHMuIERpZmZlcmVudCBwb3J0IG1lZGlhIHdpbGwgaGF2ZSBkaWZmZXJlbnQgd2F5cyB0byBhY2hp ZXZlIHRoZSBnb2FsIG9mIGRlY2Fwc3VsYXRpbmcgbWVkaWEtc3BlY2lmaWMgaGVhZGVycyBhbmQg dGhlcmVmb3JlIHZhcmlvdXMgTEZCcyBmb3IgaW5kaXZpZHVhbCBtZWRpYSB3aWxsIGhhdmUgdG8g YmUgZGVmaW5lZCB0aG91Z2ggdGhpcyBkb2N1bWVudCBzdGlja3MgdG8gRXRoZXJuZXQgcG9ydCBt ZWRpYSBvbmx5LiBJUCBwYWNrZXRzIGVtYW5hdGluZyBmcm9tIHZhcmlvdXMgbWVkaWEgcG9ydCBM RkJzIGFyZSB0aGVuIHByb2Nlc3NlZCBieSBhIHZhbGlkYXRpb24gTEZCIGJlZm9yZSBiZWluZyBm dXJ0aGVyIGZvcndhcmRlZCB0byB0aGUgbmV4dCBMRkIuDQoNCj4gDQo+IDIpIFRoZXJlIGlzIG9u bHkgbWVudGlvbiBvZiBkeW5hbWljIHJvdXRpbmcgcHJvdG9jb2xzIG9uIHBhZ2UgOC4NCj4gRm9y Q0VTIGNhbiB3b3JrIHdpdGggc3RhdGljIHJvdXRpbmcuDQpEbyB5b3UgbWVhbiB0aGlzIHBhcmFn cmFwaCBvZiB0ZXh0ID8NCi0tLS0tDQogICAoNSkgVXN1YWxseSBzdXBwb3J0IGFuIGludGVyaW9y IGdhdGV3YXkgcHJvdG9jb2wgKElHUCkgdG8gY2Fycnkgb3V0DQogICBkaXN0cmlidXRlZCByb3V0 aW5nIGFuZCByZWFjaGFiaWxpdHkgYWxnb3JpdGhtcyB3aXRoIHRoZSBvdGhlcg0KICAgcm91dGVy cyBpbiB0aGUgc2FtZSBhdXRvbm9tb3VzIHN5c3RlbS4gIEluIGFkZGl0aW9uLCBzb21lIHJvdXRl cnMNCiAgIHdpbGwgbmVlZCB0byBzdXBwb3J0IGFuIGV4dGVyaW9yIGdhdGV3YXkgcHJvdG9jb2wg KEVHUCkgdG8gZXhjaGFuZ2UNCiAgIHRvcG9sb2dpY2FsIGluZm9ybWF0aW9uIHdpdGggb3RoZXIg YXV0b25vbW91cyBzeXN0ZW1zLg0KLS0tLS0tDQpJdCBpcyBqdXN0IGNvcGllZCBmcm9tIHJmYzE4 MTIuIFdvdWxkIHlvdSBwcm92aWRlIGEgdGV4dCB0byBtb2RpZnkgdGhlIHRleHQ/IHRoYW5rcy4N Cg0KPiANCj4gMykgRmlndXJlIDEgaXMgbWlzc2luZyBhIGZldyBpbnB1dC9vdXRwdXRzL2Vycm9y cyBmb3IgYWxsIExGQnMNCj4gZGVwaWN0ZWQgaW4gdGhhdCBkaWFncmFtLiBJdCBwcm9iYWJseSBt YWtlcyBzZW5zZSBmb3IgdGhlIHNha2UNCj4gb2Ygc2ltcGxpY2l0eSB0byBpbGx1c3RyYXRlIHRo ZSBpbXBvcnRhbnQgcGllY2VzIGxpa2UgeW91IGRpZDsNCj4gaG93ZXZlciwgaWYgdGhhdCBpcyB3 aGF0IHlvdSBhcmUgaW50ZW5kaW5nIHRoZW4gcGxlYXNlIHN0YXRlDQo+IHNvIGluIGxlYWRpbmcg dGV4dC4NCg0KLS0tLSBvcmlnaW5hbDogDQogICBGaWd1cmUgMSBzaG93cyB0aGUgdHlwaWNhbCBM RkIgcHJvY2Vzc2luZyBwYXRoIGZvciB0aGUgSVB2NCB1bmljYXN0DQogICBmb3J3YXJkaW5nIGNh c2Ugd2l0aCBFdGhlcm5ldCBtZWRpYSBpbnRlcmZhY2VzLiAgU2VjdGlvbiA3LjEgd2lsbA0KICAg ZGVzY3JpYmUgdGhlIExGQiB0b3BvbG9neSBpbiBtb3JlIGRldGFpbHMuDQotLS0tLXRvOiANCkZp Z3VyZSAxIHNob3dzIHRoZSB0eXBpY2FsIExGQiBwcm9jZXNzaW5nIHBhdGggZm9yIHRoZSBJUHY0 IHVuaWNhc3QgZm9yd2FyZGluZyBjYXNlIHdpdGggRXRoZXJuZXQgbWVkaWEgaW50ZXJmYWNlcy4g Tm90ZSB0aGF0IHRvIG1ha2UgZm9jdXNlZCBvbiBkYXRhIGZvcndhcmRpbmcgZnVuY3Rpb24sIHRo ZSBkaWFncmFtIGlzIGRyYXduIHdpdGggc29tZSBMRkIgaW5wdXRzIG9yIG91dHB1dHMgd2hpY2gg YXJlIG5vdCByZWxhdGVkIHRvIElQIGZvcndhcmRpbmcgbWlzc2luZy4gIFNlY3Rpb24gNy4xIHdp bGwgZGVzY3JpYmUgdGhlIExGQiB0b3BvbG9neSBpbiBtb3JlIGRldGFpbHMuDQotLS0tDQoNCj4g DQo+IDQpIFRvIGF2b2lkIHRoZSBkaWFncmFtIGJlaW5nIG1hbmdsZWQgSSBhbSBhdHRhY2hpbmcg YQ0KPiB0eHQgZmlsZSB0byBpbGx1c3RyYXRlIGEgc21hbGwgY29ycmVjdGlvbi4NCg0KVGhlIGRp YWdyYW0gd2lsbCBiZSBkcmF3biBhZ2FpbiB0byBtYWtlIGl0IG1vcmUgbGluZWQgdXAuIHRoYW5r cy4NCg0KPiANCj4gY2hlZXJzLA0KPiBqYW1hbA0KPg0KDQoNCg0KPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBmb3JjZXMgbWFpbGluZyBsaXN0DQo+ IGZvcmNlc0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2ZvcmNlcw0KPg== From tena@huawei.com Wed Mar 9 18:54:35 2011 Return-Path: X-Original-To: forces@core3.amsl.com Delivered-To: forces@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58D1F3A680B for ; Wed, 9 Mar 2011 18:54:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.254 X-Spam-Level: X-Spam-Status: No, score=-106.254 tagged_above=-999 required=5 tests=[AWL=0.345, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qYu7SZSl-7ds for ; Wed, 9 Mar 2011 18:54:34 -0800 (PST) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 6560C3A67F6 for ; Wed, 9 Mar 2011 18:54:34 -0800 (PST) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LHT00LUJMT3HM@usaga04-in.huawei.com> for forces@ietf.org; Wed, 09 Mar 2011 20:55:51 -0600 (CST) Received: from TingZousc1 ([10.193.34.192]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LHT008EHMT10O@usaga04-in.huawei.com> for forces@ietf.org; Wed, 09 Mar 2011 20:55:51 -0600 (CST) Date: Wed, 09 Mar 2011 18:55:49 -0800 From: Tina Tsou In-reply-to: To: "'Wang,Weiming'" , 'Jamal Hadi Salim' , forces@ietf.org Message-id: <012f01cbdece$a9f62060$fde26120$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcvezZRs+zSda28rTQOP/UJ4GjDAjQAAMZjw x-cr-hashedpuzzle: ApWw BKNl KK7h L9uZ L+1E NM2U NNqE P1G2 QxgK RQdI UCnO U7x9 WnHW YI91 akwf a4sZ; 3; ZgBvAHIAYwBlAHMAQABpAGUAdABmAC4AbwByAGcAOwBoAGEAZABpAEAAbQBvAGoAYQB0AGEAdAB1AC4AYwBvAG0AOwB3AG0AdwBhAG4AZwAyADAAMAAxAEAAaABvAHQAbQBhAGkAbAAuAGMAbwBtAA==; Sosha1_v1; 7; {D54126FC-AF16-4498-A3CE-48F94E30BFD9}; dABlAG4AYQBAAGgAdQBhAHcAZQBpAC4AYwBvAG0A; Thu, 10 Mar 2011 02:55:44 GMT;RgBvAHIAYwBlAHMAIABhAG4AZAAgAE8AcABlAG4ARgBsAG8AdwAgADEALgAxAA== x-cr-puzzleid: {D54126FC-AF16-4498-A3CE-48F94E30BFD9} References: Subject: [forces] Forces and OpenFlow 1.1 X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 02:54:35 -0000 Hi, I would like to understand the similarity of current Forces and the current OpenFlow 1.1. Are they totally different now? We keep our promises with one another - no matter what! Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html From hadi@mojatatu.com Thu Mar 10 06:08:27 2011 Return-Path: X-Original-To: forces@core3.amsl.com Delivered-To: forces@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A26163A6996 for ; Thu, 10 Mar 2011 06:08:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eaNCafmeCzEe for ; Thu, 10 Mar 2011 06:08:26 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id A8BD03A69BC for ; Thu, 10 Mar 2011 06:08:26 -0800 (PST) Received: by vws6 with SMTP id 6so1865200vws.31 for ; Thu, 10 Mar 2011 06:09:44 -0800 (PST) Received: by 10.220.163.2 with SMTP id y2mr1994776vcx.203.1299766183872; Thu, 10 Mar 2011 06:09:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.175.135 with HTTP; Thu, 10 Mar 2011 06:09:22 -0800 (PST) In-Reply-To: References: From: Jamal Hadi Salim Date: Thu, 10 Mar 2011 09:09:22 -0500 Message-ID: To: "Wang,Weiming" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: forces@ietf.org Subject: Re: [forces] LFBLib v3: comment #1 X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 14:08:27 -0000 Hi Weiming, On Wed, Mar 9, 2011 at 9:46 PM, Wang,Weiming wrote= : > Hi Jamal, > > Thks for the comments. Pls see inline the reply. > > thanks, > Weiming > > ----- Original Message ----- > From: "Jamal Hadi Salim" > > ----changed to: > In a typical packet flow within an IP router, an LFB which abstracts a me= dia port receives packets and decapsulates them to form IP level packets. D= ifferent port media will have different ways to achieve the goal of decapsu= lating media-specific headers and therefore various LFBs for individual med= ia will have to be defined though this document sticks to Ethernet port med= ia only. IP packets emanating from various media port LFBs are then process= ed by a validation LFB before being further forwarded to the next LFB. > Probably something along the lines of: Packets in an IP router packets are received and transmitted on physical media typically referred to as "ports". Different physical port media will have different way for encapsulating outgoing frames and decapsulating incoming frames. The different physical media will also have different attributes that influence its behavior and how frames get encapsulated or decapsulated. This document will only deal with etherne= t physical media. Other future documents may deal with other types of media. This document will also interchangeably refer to a port to be an abstraction that constitutes a PHY and a MAC as described by the LFBs blah blah.. >> >> 2) There is only mention of dynamic routing protocols on page 8. >> ForCES can work with static routing. > Do you mean this paragraph of text ? > ----- > =A0 (5) Usually support an interior gateway protocol (IGP) to carry out > =A0 distributed routing and reachability algorithms with the other > =A0 routers in the same autonomous system. =A0In addition, some routers > =A0 will need to support an exterior gateway protocol (EGP) to exchange > =A0 topological information with other autonomous systems. > ------ > It is just copied from rfc1812. Would you provide a text to modify the te= xt? thanks. > I think an IP router will _usually_ support IGP and EGP but MUST minimally support static input. I am not sure - i just wanted to make sure that the r= eader understands that you can still conform to this document without caring abou= t presence of I/EGP. >> >> 3) Figure 1 is missing a few input/outputs/errors for all LFBs >> depicted in that diagram. It probably makes sense for the sake >> of simplicity to illustrate the important pieces like you did; >> however, if that is what you are intending then please state >> so in leading text. > > ---- original: > =A0 Figure 1 shows the typical LFB processing path for the IPv4 unicast > =A0 forwarding case with Ethernet media interfaces. =A0Section 7.1 will > =A0 describe the LFB topology in more details. > -----to: > Figure 1 shows the typical LFB processing path for the IPv4 unicast forwa= rding case with Ethernet media interfaces. Note that to make focused on dat= a forwarding function, the diagram is drawn with some LFB inputs or outputs= which are not related to IP forwarding missing. =A0Section 7.1 will descri= be the LFB topology in more details. > ---- Good but there are a lot of inputs/outputs related to IP forwarding that are missing (eg ECMP etc). So how about second sentence to: Note that this diagram is simplified to illustrate the most important parts of a simple IP forwarding FE. I have more comments I will post - I need to find my annotated copy of the draft. cheers, jamal From hadi@mojatatu.com Thu Mar 10 06:23:22 2011 Return-Path: X-Original-To: forces@core3.amsl.com Delivered-To: forces@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CBD43A69B0 for ; Thu, 10 Mar 2011 06:23:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.357 X-Spam-Level: X-Spam-Status: No, score=-102.357 tagged_above=-999 required=5 tests=[AWL=0.620, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mAZobIbWGifN for ; Thu, 10 Mar 2011 06:23:21 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 742E73A67F8 for ; Thu, 10 Mar 2011 06:23:21 -0800 (PST) Received: by vws6 with SMTP id 6so1883068vws.31 for ; Thu, 10 Mar 2011 06:24:39 -0800 (PST) Received: by 10.220.201.205 with SMTP id fb13mr2011015vcb.238.1299767078792; Thu, 10 Mar 2011 06:24:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.175.135 with HTTP; Thu, 10 Mar 2011 06:24:10 -0800 (PST) In-Reply-To: <012f01cbdece$a9f62060$fde26120$@com> References: <012f01cbdece$a9f62060$fde26120$@com> From: Jamal Hadi Salim Date: Thu, 10 Mar 2011 09:24:10 -0500 Message-ID: To: Tina Tsou Content-Type: text/plain; charset=ISO-8859-1 Cc: forces@ietf.org Subject: Re: [forces] Forces and OpenFlow 1.1 X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 14:23:22 -0000 Brief summary: The end goal of opening up TheBigBadBox is the same. The approach is different both from a technical, philosophical and business point of view. ForCES is a lot more revolutionary, technically richer, vetted over at least two interops, being done at the IETF and could be used to implement openflow (the other direction is not true). cheers, jamal On Wed, Mar 9, 2011 at 9:55 PM, Tina Tsou wrote: > Hi, > I would like to understand the similarity of current Forces and the current > OpenFlow 1.1. Are they totally different now? > > > We keep our promises with one another - no matter what! > > Best Regards, > Tina TSOU > http://tinatsou.weebly.com/contact.html > > > From hadi@mojatatu.com Thu Mar 10 06:48:28 2011 Return-Path: X-Original-To: forces@core3.amsl.com Delivered-To: forces@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E5DA3A69CD for ; Thu, 10 Mar 2011 06:48:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.46 X-Spam-Level: X-Spam-Status: No, score=-102.46 tagged_above=-999 required=5 tests=[AWL=0.517, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t4QMwIGrrFRi for ; Thu, 10 Mar 2011 06:48:27 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 9A7A33A69E9 for ; Thu, 10 Mar 2011 06:48:27 -0800 (PST) Received: by qwh6 with SMTP id 6so1517036qwh.31 for ; Thu, 10 Mar 2011 06:49:45 -0800 (PST) Received: by 10.52.67.103 with SMTP id m7mr1307495vdt.178.1299768549028; Thu, 10 Mar 2011 06:49:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.175.135 with HTTP; Thu, 10 Mar 2011 06:48:48 -0800 (PST) From: Jamal Hadi Salim Date: Thu, 10 Mar 2011 09:48:48 -0500 Message-ID: To: forces@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [forces] LFBLib v3: comment #2 LPM/NH X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 14:48:28 -0000 I am going to skip a few other issues i have and jump to this one because it may take more discussion to resolve. Implementations vary but the most common denominator for ASICs involves passing some index to some NH table or LFB to find the NH details. Typically the NH info is pre-populated by the CE when the route entry in the LPM is set. For software based FEs alternatively the NH information could be resolved at runtime (although even Linux allows for ARP to be offloaded to user space). If i am reading correctly, the document assumes a non-offload only. My fear is we are adding unnecessary overhead for the offload scheme - therefore we need to support both models. cheers, jamal From tena@huawei.com Thu Mar 10 11:43:57 2011 Return-Path: X-Original-To: forces@core3.amsl.com Delivered-To: forces@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF00B3A691A for ; Thu, 10 Mar 2011 11:43:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.277 X-Spam-Level: X-Spam-Status: No, score=-106.277 tagged_above=-999 required=5 tests=[AWL=0.322, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bwX7xrOC0Mbz for ; Thu, 10 Mar 2011 11:43:56 -0800 (PST) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id AF19D3A6A4E for ; Thu, 10 Mar 2011 11:43:56 -0800 (PST) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LHU002DDXJDDB@usaga02-in.huawei.com> for forces@ietf.org; Thu, 10 Mar 2011 11:45:14 -0800 (PST) Received: from TingZousc1 ([10.193.34.192]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LHU008CYXJD54@usaga02-in.huawei.com> for forces@ietf.org; Thu, 10 Mar 2011 11:45:13 -0800 (PST) Date: Thu, 10 Mar 2011 11:45:13 -0800 From: Tina Tsou In-reply-to: To: 'Jamal Hadi Salim' Message-id: <013d01cbdf5b$ac80a0c0$0581e240$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcvfLuaRsQMIT1u/S1qFsXyZ6YDueAALJKsA References: <012f01cbdece$a9f62060$fde26120$@com> Cc: forces@ietf.org Subject: Re: [forces] Forces and OpenFlow 1.1 X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 19:43:57 -0000 Hi Jamal, Thank and respect your summary. Therefore, if there will be a WG "OpenFlow 1.1", is it WG Forces? Or could be a new WG? We keep our promises with one another - no matter what! Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@mojatatu.com] Sent: Thursday, March 10, 2011 6:24 AM To: Tina Tsou Cc: Wang,Weiming; forces@ietf.org Subject: Re: Forces and OpenFlow 1.1 Brief summary: The end goal of opening up TheBigBadBox is the same. The approach is different both from a technical, philosophical and business point of view. ForCES is a lot more revolutionary, technically richer, vetted over at least two interops, being done at the IETF and could be used to implement openflow (the other direction is not true). cheers, jamal On Wed, Mar 9, 2011 at 9:55 PM, Tina Tsou wrote: > Hi, > I would like to understand the similarity of current Forces and the current > OpenFlow 1.1. Are they totally different now? > > > We keep our promises with one another - no matter what! > > Best Regards, > Tina TSOU > http://tinatsou.weebly.com/contact.html > > > From hadi@mojatatu.com Thu Mar 10 17:34:39 2011 Return-Path: X-Original-To: forces@core3.amsl.com Delivered-To: forces@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A4C73A6AC2 for ; Thu, 10 Mar 2011 17:34:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.443, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yVFljy8b5ma2 for ; Thu, 10 Mar 2011 17:34:38 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 59A053A69B6 for ; Thu, 10 Mar 2011 17:34:38 -0800 (PST) Received: by vws12 with SMTP id 12so222763vws.31 for ; Thu, 10 Mar 2011 17:35:56 -0800 (PST) Received: by 10.52.177.101 with SMTP id cp5mr12494457vdc.218.1299807356107; Thu, 10 Mar 2011 17:35:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.175.135 with HTTP; Thu, 10 Mar 2011 17:35:36 -0800 (PST) In-Reply-To: <013d01cbdf5b$ac80a0c0$0581e240$@com> References: <012f01cbdece$a9f62060$fde26120$@com> <013d01cbdf5b$ac80a0c0$0581e240$@com> From: Jamal Hadi Salim Date: Thu, 10 Mar 2011 20:35:36 -0500 Message-ID: To: Tina Tsou Content-Type: text/plain; charset=ISO-8859-1 Cc: forces@ietf.org Subject: Re: [forces] Forces and OpenFlow 1.1 X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 01:34:39 -0000 Hi Tina, If they decide to come to the IETF, it seems to be a natural fit with ForCES. cheers, jamal On Thu, Mar 10, 2011 at 2:45 PM, Tina Tsou wrote: > Hi Jamal, > Thank and respect your summary. > > Therefore, if there will be a WG "OpenFlow 1.1", is it WG Forces? Or could > be a new WG? > > > We keep our promises with one another - no matter what! > > Best Regards, > Tina TSOU > http://tinatsou.weebly.com/contact.html > > > -----Original Message----- > From: Jamal Hadi Salim [mailto:hadi@mojatatu.com] > Sent: Thursday, March 10, 2011 6:24 AM > To: Tina Tsou > Cc: Wang,Weiming; forces@ietf.org > Subject: Re: Forces and OpenFlow 1.1 > > Brief summary: > The end goal of opening up TheBigBadBox is the same. > The approach is different both from a technical, philosophical and > business point of view. ForCES is a lot more revolutionary, technically > richer, vetted over at least two interops, being done at the IETF > and could be used to implement openflow (the other direction > is not true). > > cheers, > jamal > > On Wed, Mar 9, 2011 at 9:55 PM, Tina Tsou wrote: >> Hi, >> I would like to understand the similarity of current Forces and the > current >> OpenFlow 1.1. Are they totally different now? >> >> >> We keep our promises with one another - no matter what! >> >> Best Regards, >> Tina TSOU >> http://tinatsou.weebly.com/contact.html >> >> >> > > From joel@stevecrocker.com Fri Mar 11 10:53:05 2011 Return-Path: X-Original-To: forces@core3.amsl.com Delivered-To: forces@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C87613A696E for ; Fri, 11 Mar 2011 10:53:05 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DcP+Ni38rQyY for ; Fri, 11 Mar 2011 10:53:04 -0800 (PST) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id 70DF03A6992 for ; Fri, 11 Mar 2011 10:53:02 -0800 (PST) Received: from [129.192.147.67] (helo=[10.154.181.170]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Py7Th-0003pa-HZ; Fri, 11 Mar 2011 13:54:21 -0500 Message-ID: <4D7A6FD9.3070703@stevecrocker.com> Date: Fri, 11 Mar 2011 13:54:17 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Jamal Hadi Salim References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 9f083ca8aeb2d326d5a073bfd238dd844d2b10475b571120722a701a702434e92a7cc93fa5207b0924e7e4fc47a0583f350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 129.192.147.67 Cc: forces@ietf.org Subject: Re: [forces] LFBLib v3: comment #2 LPM/NH X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 18:53:05 -0000 Sorry, I missed something. I do not know what "resolved at run time" means in this context. This tables are always dynamically filled in every implementation, hardware or software. The table structure in the model separates the LPM from the NextHop, with the LPM returning an index for the nexthop. That allows the common hardware implementation. If the implementation wants a single-stage lookup, then the FE keeps track of the two sets of information, and folds them together to populate the single table. it can do this under the covers perfectly legitimately. (Such an implementation would declare in its capabilities that an LPM must be followed by a next-hop table, so that the CE does not try to insert anything between the two pieces. Yours, Joel On 3/10/2011 9:48 AM, Jamal Hadi Salim wrote: > I am going to skip a few other issues i have and jump to this one > because it may take more discussion to resolve. > > Implementations vary but the most common denominator for ASICs > involves passing some index to some NH table or LFB to find the > NH details. Typically the NH info is pre-populated by the CE when > the route entry in the LPM is set. > For software based FEs alternatively the NH information > could be resolved at runtime (although even Linux allows for ARP to > be offloaded to user space). > If i am reading correctly, the document assumes a non-offload only. > My fear is we are adding unnecessary overhead for the offload > scheme - therefore we need to support both models. > > cheers, > jamal > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces > From hadi@mojatatu.com Sat Mar 12 08:15:49 2011 Return-Path: X-Original-To: forces@core3.amsl.com Delivered-To: forces@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4C2F3A6A19 for ; Sat, 12 Mar 2011 08:15:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.387, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HFlBGASWfrhQ for ; Sat, 12 Mar 2011 08:15:48 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id B6C653A69D2 for ; Sat, 12 Mar 2011 08:15:48 -0800 (PST) Received: by vws12 with SMTP id 12so1761306vws.31 for ; Sat, 12 Mar 2011 08:17:09 -0800 (PST) Received: by 10.52.97.165 with SMTP id eb5mr2733844vdb.298.1299946628162; Sat, 12 Mar 2011 08:17:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.175.135 with HTTP; Sat, 12 Mar 2011 08:16:48 -0800 (PST) In-Reply-To: <4D7A6FD9.3070703@stevecrocker.com> References: <4D7A6FD9.3070703@stevecrocker.com> From: Jamal Hadi Salim Date: Sat, 12 Mar 2011 11:16:48 -0500 Message-ID: To: "Joel M. Halpern" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: forces@ietf.org Subject: Re: [forces] LFBLib v3: comment #2 LPM/NH X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Mar 2011 16:15:50 -0000 Whatever model conceptualization one chooses will always be favoring one implementation approach over another. Yes, modelling shouldnt care about those details but to be fair and to make ForCES more usable, we need to minimally justify the choices made. If i was doing a MIB i wouldnt worr= y as much - but my view is we are too close to the metal to ignore things.... I think it may be sufficient in the document to pick a few examples of real world approaches and say how one would morph the LFBlib model onto them. Joel, your email provided one such example at the end. There are many others... I will try to be verbose below to flesh out some details. For the sake of context in discussion, let me repeat what a successful LPM lookup must provide: 1) NH details i.e i) what port to go out and ii) what destination MACaddr to use 2) src details i.e i) what src MACaddr to use ii) optionally what VLAN info to use. I will try to spell out the variables involved in modeling the above in an implementation. There are a lot of permutations on how info can be stored in an FE and how a packet traverses them; I am going to use the two that have come up so far in the last 2 emails: A) both #1 and #2 in the LPM table - if all you are implementing is an L3 router, this would be a lot more efficient lookup-wise at the expense of storage and modularity. A lot of software implementations go this path. B) #1 and #2 in separate tables (from the LPM table). A lot of ASICs implement this way. This is clearly more efficient storage wise, definetely more modular, but I doubt it can beat #A lookup cycle-wise. The LFBlib went with a variant of #B without saying why. The LFBlib should also say what other approaches should provide an example or two of how to scrape/massage information from the CE to their datapath. If you go with #B, then: - there are several permutations on what each table takes as input. For example, the LFBlib uses an IP address as an index to lookup the NH. An IP address implies context lookup; the typical approach is to use a table index. We dont say why. - there are several permutations of the details of the different tables get populated in order to approach the lookup efficiency of #A. The most common trick is "offloading" things like ARP/ND to the CE and pre-populating all t= he required tables from the CE once we know the route. The LFBlib approach implies an ARP/ND living at the FE. I think we need to allow for a minimal the ARP/ND offloading to the CE in addition. I am not sure what to do with the IP address as metadata for NH lookup (it looks clever and fits well with a datapath NH resolution, but there is no need for it in a datapath). I apologize for the long email - I hope my view was not lost in the details at the end. cheers, jamal On Fri, Mar 11, 2011 at 1:54 PM, Joel M. Halpern wr= ote: > Sorry, I missed something. > > I do not know what "resolved at run time" means in this context. =A0This > tables are always dynamically filled in every implementation, hardware or > software. > > The table structure in the model separates the LPM from the NextHop, with > the LPM returning an index for the nexthop. =A0That allows the common har= dware > implementation. > If the implementation wants a single-stage lookup, then the FE keeps trac= k > of the two sets of information, and folds them together to populate the > single table. =A0it can do this under the covers perfectly legitimately. > =A0(Such an implementation would declare in its capabilities that an LPM = must > be followed by a next-hop table, so that the CE does not try to insert > anything between the two pieces. > > Yours, > Joel > > On 3/10/2011 9:48 AM, Jamal Hadi Salim wrote: >> >> I am going to skip a few other issues i have and jump to this one >> because it may take more discussion to resolve. >> >> Implementations vary but the most common denominator for ASICs >> involves passing some index to some NH table or LFB to find the >> NH details. Typically the NH info is pre-populated by the CE when >> the route entry in the LPM is set. >> For software based FEs alternatively the NH information >> could be resolved at runtime (although even Linux allows for ARP to >> be offloaded to user space). >> If i am reading correctly, the document assumes a non-offload only. >> My fear is we are adding unnecessary overhead for the offload >> scheme - therefore we need to support both models. >> >> cheers, >> jamal >> _______________________________________________ >> forces mailing list >> forces@ietf.org >> https://www.ietf.org/mailman/listinfo/forces >> > > From joel@stevecrocker.com Sun Mar 13 09:00:22 2011 Return-Path: X-Original-To: forces@core3.amsl.com Delivered-To: forces@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAC383A6A1E for ; Sun, 13 Mar 2011 09:00:21 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SO3sEtygTBuK for ; Sun, 13 Mar 2011 09:00:18 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id 8BBDA3A6A06 for ; Sun, 13 Mar 2011 09:00:18 -0700 (PDT) Received: from [64.168.229.50] (helo=[172.31.177.192]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Pynjg-0001T5-Aj; Sun, 13 Mar 2011 12:01:40 -0400 Message-ID: <4D7CEA60.5000403@stevecrocker.com> Date: Sun, 13 Mar 2011 12:01:36 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Jamal Hadi Salim References: <4D7A6FD9.3070703@stevecrocker.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 9f083ca8aeb2d326d5a073bfd238dd844d2b10475b5711207755a6ff4eebf18fd7527921186c5644790fad917fc14d6b350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.168.229.50 Cc: forces@ietf.org Subject: Re: [forces] LFBLib v3: comment #2 LPM/NH X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2011 16:00:22 -0000 Two points: 1) I thought we had articulated why we went with the decomposed structure (what you call B) rather than combined. The basic reason is that it is easy for an FE to transform a decomposed structure into a combined implementation. It is hard for an FE to decompose a combined structure into a separated implementation. (I will admit that the fact that virtually all routers use the decomposed structure was also relevant., but I believe the above was the primary reason.) 2) The structure proposed does not require ARP/ND protocol processing to be on the FE. The most likely CE implementation of ARP/ND that is relevant is taht for any routing next hop, the CE does the ARP/ND resolution first, so it can fill in the table on the FE. (Yes, the ARP/ND tables are needed, but the protocol processing isn't.) Yours, Joel PS: I thought we had this discussion years ago. On 3/12/2011 11:16 AM, Jamal Hadi Salim wrote: > Whatever model conceptualization one chooses will always be favoring one > implementation approach over another. Yes, modelling shouldnt care > about those details but to be fair and to make ForCES more usable, we need > to minimally justify the choices made. If i was doing a MIB i wouldnt worry > as much - but my view is we are too close to the metal to ignore things.... > I think it may be sufficient in the document to pick a few examples of > real world approaches and say how one would morph the LFBlib model > onto them. Joel, your email provided one such example at the end. > There are many others... > > I will try to be verbose below to flesh out some details. > > For the sake of context in discussion, let me repeat what a successful > LPM lookup must provide: > 1) NH details i.e i) what port to go out and ii) what destination > MACaddr to use > 2) src details i.e i) what src MACaddr to use ii) optionally what VLAN > info to use. > > I will try to spell out the variables involved in modeling the above in an > implementation. > There are a lot of permutations on how info can be stored in an FE and how > a packet traverses them; I am going to use the two that have come up so > far in the last 2 emails: > > A) both #1 and #2 in the LPM table - if all you are implementing is an > L3 router, this would be a lot more efficient lookup-wise at the expense > of storage and modularity. A lot of software implementations go this path. > B) #1 and #2 in separate tables (from the LPM table). A lot of ASICs > implement this way. This is clearly more efficient storage wise, definetely > more modular, but I doubt it can beat #A lookup cycle-wise. > > The LFBlib went with a variant of #B without saying why. > The LFBlib should also say what other approaches should provide an > example or two of how to scrape/massage information from the CE to > their datapath. > > If you go with #B, then: > - there are several permutations on what each table takes as input. > For example, the LFBlib uses an IP address as an index to lookup the > NH. An IP address implies context lookup; the typical approach is to > use a table index. We dont say why. > - there are several permutations of the details of the different tables get > populated in order to approach the lookup efficiency of #A. The most common > trick is "offloading" things like ARP/ND to the CE and pre-populating all the > required tables from the CE once we know the route. > > The LFBlib approach implies an ARP/ND living at the FE. > I think we need to allow for a minimal the ARP/ND offloading to the CE > in addition. I am not sure what to do with the IP address as metadata for > NH lookup (it looks clever and fits well with a datapath NH resolution, but > there is no need for it in a datapath). > > > I apologize for the long email - I hope my view was not lost in > the details at the end. > > cheers, > jamal > > > On Fri, Mar 11, 2011 at 1:54 PM, Joel M. Halpern wrote: >> Sorry, I missed something. >> >> I do not know what "resolved at run time" means in this context. This >> tables are always dynamically filled in every implementation, hardware or >> software. >> >> The table structure in the model separates the LPM from the NextHop, with >> the LPM returning an index for the nexthop. That allows the common hardware >> implementation. >> If the implementation wants a single-stage lookup, then the FE keeps track >> of the two sets of information, and folds them together to populate the >> single table. it can do this under the covers perfectly legitimately. >> (Such an implementation would declare in its capabilities that an LPM must >> be followed by a next-hop table, so that the CE does not try to insert >> anything between the two pieces. >> >> Yours, >> Joel >> >> On 3/10/2011 9:48 AM, Jamal Hadi Salim wrote: >>> >>> I am going to skip a few other issues i have and jump to this one >>> because it may take more discussion to resolve. >>> >>> Implementations vary but the most common denominator for ASICs >>> involves passing some index to some NH table or LFB to find the >>> NH details. Typically the NH info is pre-populated by the CE when >>> the route entry in the LPM is set. >>> For software based FEs alternatively the NH information >>> could be resolved at runtime (although even Linux allows for ARP to >>> be offloaded to user space). >>> If i am reading correctly, the document assumes a non-offload only. >>> My fear is we are adding unnecessary overhead for the offload >>> scheme - therefore we need to support both models. >>> >>> cheers, >>> jamal >>> _______________________________________________ >>> forces mailing list >>> forces@ietf.org >>> https://www.ietf.org/mailman/listinfo/forces >>> >> >> > From hadi@mojatatu.com Sun Mar 13 10:02:21 2011 Return-Path: X-Original-To: forces@core3.amsl.com Delivered-To: forces@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2AD93A6A0B for ; Sun, 13 Mar 2011 10:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.833 X-Spam-Level: X-Spam-Status: No, score=-101.833 tagged_above=-999 required=5 tests=[AWL=-0.456, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_22=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UvltPMkPJPB3 for ; Sun, 13 Mar 2011 10:02:21 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id D73043A69FA for ; Sun, 13 Mar 2011 10:02:20 -0700 (PDT) Received: by vxg33 with SMTP id 33so4642059vxg.31 for ; Sun, 13 Mar 2011 10:03:42 -0700 (PDT) Received: by 10.220.90.146 with SMTP id i18mr2974271vcm.263.1300035822344; Sun, 13 Mar 2011 10:03:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.195.73 with HTTP; Sun, 13 Mar 2011 10:03:22 -0700 (PDT) In-Reply-To: <4D7CEA60.5000403@stevecrocker.com> References: <4D7A6FD9.3070703@stevecrocker.com> <4D7CEA60.5000403@stevecrocker.com> From: Jamal Hadi Salim Date: Sun, 13 Mar 2011 13:03:22 -0400 Message-ID: To: "Joel M. Halpern" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: forces@ietf.org Subject: Re: [forces] LFBLib v3: comment #2 LPM/NH X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2011 17:02:21 -0000 On Sun, Mar 13, 2011 at 12:01 PM, Joel M. Halpern w= rote: > Two points: > > 1) I thought we had articulated why we went with the decomposed structure > (what you call B) rather than combined. =A0The basic reason is that it is= easy > for an FE to transform a decomposed structure into a combined > implementation. =A0It is hard for an FE to decompose a combined structure= into > a separated implementation. =A0(I will admit that the fact that virtually= all > routers use the decomposed structure was also relevant., but I believe th= e > above was the primary reason.) Iam sorry for rehashing this specific point; i did that mainly to provide a context for the ARP/ND resolution (point #2 below). But there is still confusion ev= en if we ignored the ARP/ND issue which i think could be cleared with at least some example text (maybe an appendix) what the massaging constitutes. [I had someone who had done an L3 ASIC in the past (the combined approach) and he was confused as to how he would fit without a huge amount of scrappi= ng.] > 2) The structure proposed does not require ARP/ND protocol processing to = be > on the FE. =A0The most likely CE implementation of ARP/ND that is relevan= t is > taht for any routing next hop, the CE does the ARP/ND resolution first, s= o > it can fill in the table on the FE. =A0(Yes, the ARP/ND tables are needed= , but > the protocol processing isn't.) Thats my feeling as well. That is not the proposal in this document. The approach discussed considers that an LPM entry can exist without a resolved corresponding NH entry. i.e, the LPM points to the neighbors IP address and further downstream, the packet processing assumes it needs to resolve an ARP/ND for that neighbors IP address and does that while buffering the packet (whose LPM is already resolved) somewhere. I actually like this scheme (it is the approach Linux kernel uses) but i think we need to allow for the model you described; besided that one could argue that in a dynamic routing environment the approach described is susceptible to a race condition where the NH for the destination may change while we are waiting for the neighbor to be resolved via ARP/ND. Again apologies for the long email - i dont have a TL;DR version. cheers, jamal From Internet-Drafts@ietf.org Sun Mar 13 19:45:03 2011 Return-Path: X-Original-To: forces@core3.amsl.com Delivered-To: forces@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C1833A6C01; Sun, 13 Mar 2011 19:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WsEECy9t2tuO; Sun, 13 Mar 2011 19:45:01 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B25A3A6AB9; Sun, 13 Mar 2011 19:45:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110314024501.8655.37675.idtracker@localhost> Date: Sun, 13 Mar 2011 19:45:01 -0700 Cc: forces@ietf.org Subject: [forces] I-D Action:draft-ietf-forces-interop-01.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 02:45:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Forwarding and Control Element Separation Working Group of the IETF. Title : Interoperability Report for Forwarding and Control Element Separation (ForCES) Author(s) : W. Wang, et al. Filename : draft-ietf-forces-interop-01.txt Pages : 37 Date : 2011-03-13 This document captures test results from the second Forwarding and control Element Separation (ForCES) interop testing which took place on March 24-25, 2011 at the Internet Technology Lab (ITL) of Zhejiang Gongshang University in China. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-forces-interop-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-forces-interop-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-13193339.I-D@ietf.org> --NextPart-- From wmwang2001@hotmail.com Mon Mar 14 02:12:04 2011 Return-Path: X-Original-To: forces@core3.amsl.com Delivered-To: forces@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02E9C3A68E0 for ; Mon, 14 Mar 2011 02:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.58 X-Spam-Level: X-Spam-Status: No, score=-96.58 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, FORGED_MUA_OUTLOOK=3.116, MANGLED_TOOL=2.3, MIME_BASE64_TEXT=1.753, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FZgJyQ5N47DN for ; Mon, 14 Mar 2011 02:12:03 -0700 (PDT) Received: from blu0-omc4-s28.blu0.hotmail.com (blu0-omc4-s28.blu0.hotmail.com [65.55.111.167]) by core3.amsl.com (Postfix) with ESMTP id C469B3A6853 for ; Mon, 14 Mar 2011 02:12:02 -0700 (PDT) Received: from BLU0-SMTP168 ([65.55.111.137]) by blu0-omc4-s28.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Mar 2011 02:13:25 -0700 X-Originating-IP: [221.12.10.218] X-Originating-Email: [wmwang2001@hotmail.com] Message-ID: Received: from ZJGSUIEE ([221.12.10.218]) by BLU0-SMTP168.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Mar 2011 02:13:24 -0700 From: "Wang,Weiming" To: References: <20110314024501.8655.37675.idtracker@localhost> Date: Mon, 14 Mar 2011 17:11:44 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-OriginalArrivalTime: 14 Mar 2011 09:13:24.0809 (UTC) FILETIME=[128E8390:01CBE228] Subject: Re: [forces] I-D Action:draft-ietf-forces-interop-01.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 09:12:04 -0000 SGksDQoNCldlJ3YganVzdCB1cGRhdGVkIHRoZSBpbnRlcm9wIGRyYWZ0IHRvIDAxIHZlcnNpb24s IHdoZW4gd2UgY2hlY2tlZCBhIGJ1ZyBpbiB0aGUgdGV4dC4gVGhlIGludGVyb3BlcmFiaWxpdHkg dGVzdCBtZWV0aW5nIHdhcyBhY3R1YWxseSBoZWxkIG9uIFNlcC4gMjQtMjUgMjAxMSwgcmF0aGVy IHRoYW4gTWFyLiAyNC00NSAyMDExIGFzIG1pc3Rha2VuIGluIHRoZSBkcmFmdC4gDQoNClNvcnJ5 IGZvciB0aGlzLg0KDQp0aGFua3MsDQpXZWltaW5nDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2Ug LS0tLS0gDQpGcm9tOiA8SW50ZXJuZXQtRHJhZnRzQGlldGYub3JnPg0KDQo+QSBOZXcgSW50ZXJu ZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRp cmVjdG9yaWVzLg0KPiBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBGb3J3YXJkaW5n IGFuZCBDb250cm9sIEVsZW1lbnQgU2VwYXJhdGlvbiBXb3JraW5nIEdyb3VwIG9mIHRoZSBJRVRG Lg0KPiANCj4gDQo+IFRpdGxlICAgICAgICAgICA6IEludGVyb3BlcmFiaWxpdHkgUmVwb3J0IGZv ciBGb3J3YXJkaW5nIGFuZCBDb250cm9sIEVsZW1lbnQgU2VwYXJhdGlvbiAoRm9yQ0VTKQ0KPiBB dXRob3IocykgICAgICAgOiBXLiBXYW5nLCBldCBhbC4NCj4gRmlsZW5hbWUgICAgICAgIDogZHJh ZnQtaWV0Zi1mb3JjZXMtaW50ZXJvcC0wMS50eHQNCj4gUGFnZXMgICAgICAgICAgIDogMzcNCj4g RGF0ZSAgICAgICAgICAgIDogMjAxMS0wMy0xMw0KPiANCj4gVGhpcyBkb2N1bWVudCBjYXB0dXJl cyB0ZXN0IHJlc3VsdHMgZnJvbSB0aGUgc2Vjb25kIEZvcndhcmRpbmcgYW5kDQo+IGNvbnRyb2wg RWxlbWVudCBTZXBhcmF0aW9uIChGb3JDRVMpIGludGVyb3AgdGVzdGluZyB3aGljaCB0b29rIHBs YWNlDQo+IG9uIE1hcmNoIDI0LTI1LCAyMDExIGF0IHRoZSBJbnRlcm5ldCBUZWNobm9sb2d5IExh YiAoSVRMKSBvZiBaaGVqaWFuZw0KPiBHb25nc2hhbmcgVW5pdmVyc2l0eSBpbiBDaGluYS4NCj4g DQo+IEEgVVJMIGZvciB0aGlzIEludGVybmV0LURyYWZ0IGlzOg0KPiBodHRwOi8vd3d3LmlldGYu b3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLWZvcmNlcy1pbnRlcm9wLTAxLnR4dA0KPiAN Cj4gSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0 Og0KPiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPiANCj4gQmVsb3cgaXMg dGhlIGRhdGEgd2hpY2ggd2lsbCBlbmFibGUgYSBNSU1FIGNvbXBsaWFudCBtYWlsIHJlYWRlcg0K PiBpbXBsZW1lbnRhdGlvbiB0byBhdXRvbWF0aWNhbGx5IHJldHJpZXZlIHRoZSBBU0NJSSB2ZXJz aW9uIG9mIHRoZQ0KPiBJbnRlcm5ldC1EcmFmdC4NCj4NCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KDQoNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gZm9yY2VzIG1haWxpbmcgbGlzdA0KPiBmb3JjZXNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9mb3JjZXMNCj4= From hadi@mojatatu.com Mon Mar 14 05:12:47 2011 Return-Path: X-Original-To: forces@core3.amsl.com Delivered-To: forces@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9404C3A6994 for ; Mon, 14 Mar 2011 05:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.337 X-Spam-Level: X-Spam-Status: No, score=-100.337 tagged_above=-999 required=5 tests=[AWL=-1.860, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_21=0.6, J_CHICKENPOX_47=0.6, MANGLED_TOOL=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id exrRk-YYvYrd for ; Mon, 14 Mar 2011 05:12:46 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id B98A43A695D for ; Mon, 14 Mar 2011 05:12:46 -0700 (PDT) Received: by vxg33 with SMTP id 33so5224340vxg.31 for ; Mon, 14 Mar 2011 05:14:10 -0700 (PDT) Received: by 10.220.90.146 with SMTP id i18mr3186357vcm.263.1300104849775; Mon, 14 Mar 2011 05:14:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.195.73 with HTTP; Mon, 14 Mar 2011 05:13:19 -0700 (PDT) In-Reply-To: References: <20110314024501.8655.37675.idtracker@localhost> From: Jamal Hadi Salim Date: Mon, 14 Mar 2011 08:13:19 -0400 Message-ID: To: "Wang,Weiming" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: forces@ietf.org Subject: Re: [forces] I-D Action:draft-ietf-forces-interop-01.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 12:12:47 -0000 Weiming, You mean Feb 24-25 ;-> cheers, jamal On Mon, Mar 14, 2011 at 5:11 AM, Wang,Weiming wrot= e: > Hi, > > We'v just updated the interop draft to 01 version, when we checked a bug = in the text. The interoperability test meeting was actually held on Sep. 24= -25 2011, rather than Mar. 24-45 2011 as mistaken in the draft. > > Sorry for this. > > thanks, > Weiming > > ----- Original Message ----- > From: > >>A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. >> This draft is a work item of the Forwarding and Control Element Separati= on Working Group of the IETF. >> >> >> Title =A0 =A0 =A0 =A0 =A0 : Interoperability Report for Forwarding and C= ontrol Element Separation (ForCES) >> Author(s) =A0 =A0 =A0 : W. Wang, et al. >> Filename =A0 =A0 =A0 =A0: draft-ietf-forces-interop-01.txt >> Pages =A0 =A0 =A0 =A0 =A0 : 37 >> Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-03-13 >> >> This document captures test results from the second Forwarding and >> control Element Separation (ForCES) interop testing which took place >> on March 24-25, 2011 at the Internet Technology Lab (ITL) of Zhejiang >> Gongshang University in China. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-forces-interop-01.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> > > > -------------------------------------------------------------------------= ------- > > >> _______________________________________________ >> forces mailing list >> forces@ietf.org >> https://www.ietf.org/mailman/listinfo/forces >> > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces > From joel@stevecrocker.com Mon Mar 14 18:56:32 2011 Return-Path: X-Original-To: forces@core3.amsl.com Delivered-To: forces@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FC0D3A6D75 for ; Mon, 14 Mar 2011 18:56:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, J_CHICKENPOX_22=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hpxo2kCnmhWY for ; Mon, 14 Mar 2011 18:56:31 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id 8C62E3A68AB for ; Mon, 14 Mar 2011 18:56:31 -0700 (PDT) Received: from [71.161.52.147] (helo=[10.10.10.101]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1PzJWF-0004Qm-19; Mon, 14 Mar 2011 21:57:55 -0400 Message-ID: <4D7EC79F.9060604@stevecrocker.com> Date: Mon, 14 Mar 2011 21:57:51 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Jamal Hadi Salim References: <4D7A6FD9.3070703@stevecrocker.com> <4D7CEA60.5000403@stevecrocker.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 9f083ca8aeb2d326d5a073bfd238dd844d2b10475b57112055bdb15f1912147b83dc40c5444451eb42fd9741984be237350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 71.161.52.147 Cc: forces@ietf.org Subject: Re: [forces] LFBLib v3: comment #2 LPM/NH X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 01:56:32 -0000 In line. On 3/13/2011 1:03 PM, Jamal Hadi Salim wrote: > On Sun, Mar 13, 2011 at 12:01 PM, Joel M. Halpern wrote: >> Two points: >> >> 1) I thought we had articulated why we went with the decomposed structure >> (what you call B) rather than combined. The basic reason is that it is easy >> for an FE to transform a decomposed structure into a combined >> implementation. It is hard for an FE to decompose a combined structure into >> a separated implementation. (I will admit that the fact that virtually all >> routers use the decomposed structure was also relevant., but I believe the >> above was the primary reason.) > > Iam sorry for rehashing this specific point; i did that mainly to > provide a context > for the ARP/ND resolution (point #2 below). But there is still confusion even > if we ignored the ARP/ND issue which i think could be cleared with at least > some example text (maybe an appendix) what the massaging constitutes. > [I had someone who had done an L3 ASIC in the past (the combined approach) > and he was confused as to how he would fit without a huge amount of scrapping.] The quesiton I guess is whether he understood the basic idea that he can mapp the tables together in the FE processor, or whether the ability to build intermediate structures there had not occurred to him. WIthout those, it would be hard. With those, I think it is easy. Doing it the other way appears somewhat harder no matter what. And trying to do it both ways will, I fear, create confused and complicated CEs. > >> 2) The structure proposed does not require ARP/ND protocol processing to be >> on the FE. The most likely CE implementation of ARP/ND that is relevant is >> taht for any routing next hop, the CE does the ARP/ND resolution first, so >> it can fill in the table on the FE. (Yes, the ARP/ND tables are needed, but >> the protocol processing isn't.) > > Thats my feeling as well. That is not the proposal in this document. > The approach discussed considers that an LPM entry can exist > without a resolved corresponding NH entry. i.e, the LPM points to the > neighbors IP address and further downstream, the packet processing > assumes it needs to resolve an ARP/ND for that neighbors IP address > and does that while buffering the packet (whose LPM is already resolved) > somewhere. > I actually like this scheme (it is the approach Linux kernel uses) > but i think we need to allow for the model you described; besided > that one could argue that in a dynamic routing environment > the approach described is susceptible to a race condition where > the NH for the destination may change while we are waiting for the > neighbor to be resolved via ARP/ND. I think my description works with the structure in the document. It can use some extra descriptive words. Even if the logic is ostensibly set up so that one can take a miss on the ARP/ND table, the CE can still prepopulate everything. The piece we are missing probably is that there ought to be a hook so that the CE can tell that it needs to provide the ARP/ND and prepopulation functionality. If we have done things right, taht could be represented simply by the FE not supporting certain LFBs. But we still need a place for the table. Yours, Joel > > Again apologies for the long email - i dont have a TL;DR version. > > cheers, > jamal > From hadi@mojatatu.com Tue Mar 15 06:20:25 2011 Return-Path: X-Original-To: forces@core3.amsl.com Delivered-To: forces@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 288353A6BC3 for ; Tue, 15 Mar 2011 06:20:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.918 X-Spam-Level: X-Spam-Status: No, score=-101.918 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HU21OWqnZfE3 for ; Tue, 15 Mar 2011 06:20:24 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 26A123A694E for ; Tue, 15 Mar 2011 06:20:23 -0700 (PDT) Received: by vxg33 with SMTP id 33so637601vxg.31 for ; Tue, 15 Mar 2011 06:21:48 -0700 (PDT) Received: by 10.52.160.38 with SMTP id xh6mr337662vdb.186.1300195120117; Tue, 15 Mar 2011 06:18:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.195.73 with HTTP; Tue, 15 Mar 2011 06:14:50 -0700 (PDT) In-Reply-To: <4D7EC79F.9060604@stevecrocker.com> References: <4D7A6FD9.3070703@stevecrocker.com> <4D7CEA60.5000403@stevecrocker.com> <4D7EC79F.9060604@stevecrocker.com> From: Jamal Hadi Salim Date: Tue, 15 Mar 2011 09:14:50 -0400 Message-ID: To: "Joel M. Halpern" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: forces@ietf.org Subject: Re: [forces] LFBLib v3: comment #2 LPM/NH X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 13:20:25 -0000 On Mon, Mar 14, 2011 at 9:57 PM, Joel M. Halpern wr= ote: > The quesiton I guess is whether he understood the basic idea that he can > mapp the tables together in the FE processor, or whether the ability to > build intermediate structures there had not occurred to him. =A0WIthout t= hose, > it would be hard. =A0With those, I think it is easy. My take was he thought it was too much work. But probably would have been easier if it was explained sufficiently well in the doc. I am going to try = and use him as the guinea-pig to see what kind of info we need to provide. > Doing it the other way appears somewhat harder no matter what. > And trying to do it both ways will, I fear, create confused and complicat= ed > CEs. No need to change the current approach (Like you said we resolved that at least 2 years back). We just need to have better explanation for issues like above. > I think my description works with the structure in the document. =A0It ca= n use > some extra descriptive words. =A0Even if the logic is ostensibly set up s= o > that one can take a miss on the ARP/ND table, the CE can still prepopulat= e > everything. True. > The piece we are missing probably is that there ought to be a hook so tha= t > the CE can tell that it needs to provide the ARP/ND and prepopulation > functionality. =A0If we have done things right, taht could be represented > simply by the FE not supporting certain LFBs. =A0But we still need a plac= e for > the table. That would be a good start but i think we need to do more; not sure where to start maybe we need to review that whole path, here's one part that bothers me: Currently: 1) LPM feeding a NH applicator a NHID 2) NH applicator only finds one destination detail: the output port 3) NH applicator feeds etherencap an IP address and output portid 4) Somewhere within Etherencap we take the IP(4/6) address and do a lookup then we either ARP or find the dstMAC address. 5) We then find the src info (srcMAC and VLAN) I think the idea of an IP address passed in #4 is useful for the assumption that we are going to resolve the dst link address downstream (which i dont mind supporting) but an IP address implies content search which someone is going to have to scrape if they use an index to do the src info. What most common (ASIC, ignoring ECMP) approaches do is something like: 1) LPM feeds into some form of NH applicator with a NHID 2) NHapplicator finds _all_ of the destination info (output port + dstMAC) 3) NH applicator feeds into some form etherencap a srcindex used to select a pre-populated table with srcMAC and VLAN. So #2 and #3 are very different from the current approach and whoever has a scheme like this will have to maintain a lot of scrapping/translation= . cheers, jamal From wmwang2001@hotmail.com Tue Mar 15 07:18:58 2011 Return-Path: X-Original-To: forces@core3.amsl.com Delivered-To: forces@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59A403A6D27 for ; Tue, 15 Mar 2011 07:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.218 X-Spam-Level: X-Spam-Status: No, score=-92.218 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FAKE_REPLY_C=2.012, FORGED_MUA_OUTLOOK=3.116, J_CHICKENPOX_21=0.6, J_CHICKENPOX_47=0.6, MANGLED_TOOL=2.3, MIME_BASE64_TEXT=1.753, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J4b9jaLThAlq for ; Tue, 15 Mar 2011 07:18:55 -0700 (PDT) Received: from blu0-omc4-s33.blu0.hotmail.com (blu0-omc4-s33.blu0.hotmail.com [65.55.111.172]) by core3.amsl.com (Postfix) with ESMTP id 514553A6D25 for ; Tue, 15 Mar 2011 07:18:55 -0700 (PDT) Received: from BLU0-SMTP130 ([65.55.111.136]) by blu0-omc4-s33.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Mar 2011 07:20:20 -0700 X-Originating-IP: [60.186.200.55] X-Originating-Email: [wmwang2001@hotmail.com] Message-ID: Received: from WmwangHome ([60.186.200.55]) by BLU0-SMTP130.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Mar 2011 07:20:18 -0700 From: "Wang,Weiming" To: Date: Tue, 15 Mar 2011 22:20:10 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 X-OriginalArrivalTime: 15 Mar 2011 14:20:18.0978 (UTC) FILETIME=[1CAB7820:01CBE31C] Subject: Re: [forces] I-D Action:draft-ietf-forces-interop-01.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 14:18:58 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIldlaW1pbmcgV2FuZyIgPHdt d2FuZ0BtYWlsLnpqZ3N1LmVkdS5jbj4NClRvOiAiSmFtYWwgSGFkaSBTYWxpbSIgPGhhZGlAbW9q YXRhdHUuY29tPg0KQ2M6IDxmb3JjZXNAaWV0Zi5vcmc+DQpTZW50OiBUdWVzZGF5LCBNYXJjaCAx NSwgMjAxMSA3OjUxIFBNDQpTdWJqZWN0OiBSZTogW2ZvcmNlc10gSS1EIEFjdGlvbjpkcmFmdC1p ZXRmLWZvcmNlcy1pbnRlcm9wLTAxLnR4dA0KDQoNCj4gWWVzLCBzaG91bGQgYmUgRmViIDI0LTI1 LiANCj4gDQo+IFNvcnJ5IGFnYWluLg0KPiANCj4gV2VpbWluZw0KPiANCj4gLS0tLS0gT3JpZ2lu YWwgTWVzc2FnZSAtLS0tLSANCj4gRnJvbTogIkphbWFsIEhhZGkgU2FsaW0iIDxoYWRpQG1vamF0 YXR1LmNvbT4NCj4gDQo+IFdlaW1pbmcsDQo+IFlvdSBtZWFuIEZlYiAyNC0yNSA7LT4NCj4gDQo+ IGNoZWVycywNCj4gamFtYWwNCj4gDQo+IE9uIE1vbiwgTWFyIDE0LCAyMDExIGF0IDU6MTEgQU0s IFdhbmcsV2VpbWluZyA8d213YW5nMjAwMUBob3RtYWlsLmNvbT4gd3JvdGU6DQo+PiBIaSwNCj4+ DQo+PiBXZSd2IGp1c3QgdXBkYXRlZCB0aGUgaW50ZXJvcCBkcmFmdCB0byAwMSB2ZXJzaW9uLCB3 aGVuIHdlIGNoZWNrZWQgYSBidWcgaW4gdGhlIHRleHQuIFRoZSBpbnRlcm9wZXJhYmlsaXR5IHRl c3QgbWVldGluZyB3YXMgYWN0dWFsbHkgaGVsZCBvbiBTZXAuIDI0LTI1IDIwMTEsIHJhdGhlciB0 aGFuIE1hci4gMjQtNDUgMjAxMSBhcyBtaXN0YWtlbiBpbiB0aGUgZHJhZnQuDQo+Pg0KPj4gU29y cnkgZm9yIHRoaXMuDQo+Pg0KPj4gdGhhbmtzLA0KPj4gV2VpbWluZw0KPj4NCj4+IC0tLS0tIE9y aWdpbmFsIE1lc3NhZ2UgLS0tLS0NCj4+IEZyb206IDxJbnRlcm5ldC1EcmFmdHNAaWV0Zi5vcmc+ DQo+Pg0KPj4+QSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxp bmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KPj4+IFRoaXMgZHJhZnQgaXMgYSB3b3Jr IGl0ZW0gb2YgdGhlIEZvcndhcmRpbmcgYW5kIENvbnRyb2wgRWxlbWVudCBTZXBhcmF0aW9uIFdv cmtpbmcgR3JvdXAgb2YgdGhlIElFVEYuDQo+Pj4NCj4+Pg0KPj4+IFRpdGxlIDogSW50ZXJvcGVy YWJpbGl0eSBSZXBvcnQgZm9yIEZvcndhcmRpbmcgYW5kIENvbnRyb2wgRWxlbWVudCBTZXBhcmF0 aW9uIChGb3JDRVMpDQo+Pj4gQXV0aG9yKHMpIDogVy4gV2FuZywgZXQgYWwuDQo+Pj4gRmlsZW5h bWUgOiBkcmFmdC1pZXRmLWZvcmNlcy1pbnRlcm9wLTAxLnR4dA0KPj4+IFBhZ2VzIDogMzcNCj4+ PiBEYXRlIDogMjAxMS0wMy0xMw0KPj4+DQo+Pj4gVGhpcyBkb2N1bWVudCBjYXB0dXJlcyB0ZXN0 IHJlc3VsdHMgZnJvbSB0aGUgc2Vjb25kIEZvcndhcmRpbmcgYW5kDQo+Pj4gY29udHJvbCBFbGVt ZW50IFNlcGFyYXRpb24gKEZvckNFUykgaW50ZXJvcCB0ZXN0aW5nIHdoaWNoIHRvb2sgcGxhY2UN Cj4+PiBvbiBNYXJjaCAyNC0yNSwgMjAxMSBhdCB0aGUgSW50ZXJuZXQgVGVjaG5vbG9neSBMYWIg KElUTCkgb2YgWmhlamlhbmcNCj4+PiBHb25nc2hhbmcgVW5pdmVyc2l0eSBpbiBDaGluYS4NCj4+ Pg0KPj4+IEEgVVJMIGZvciB0aGlzIEludGVybmV0LURyYWZ0IGlzOg0KPj4+IGh0dHA6Ly93d3cu aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtZm9yY2VzLWludGVyb3AtMDEudHh0 DQo+Pj4NCj4+PiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91 cyBGVFAgYXQ6DQo+Pj4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4+Pg0K Pj4+IEJlbG93IGlzIHRoZSBkYXRhIHdoaWNoIHdpbGwgZW5hYmxlIGEgTUlNRSBjb21wbGlhbnQg bWFpbCByZWFkZXINCj4+PiBpbXBsZW1lbnRhdGlvbiB0byBhdXRvbWF0aWNhbGx5IHJldHJpZXZl IHRoZSBBU0NJSSB2ZXJzaW9uIG9mIHRoZQ0KPj4+IEludGVybmV0LURyYWZ0Lg0KPj4+DQo+Pg0K Pj4NCj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pg0KPj4NCj4+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IGZvcmNlcyBtYWlsaW5nIGxp c3QNCj4+PiBmb3JjZXNAaWV0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2ZvcmNlcw0KPj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPj4gZm9yY2VzIG1haWxpbmcgbGlzdA0KPj4gZm9yY2VzQGlldGYu b3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ZvcmNlcw0KPj4N Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gZm9y Y2VzIG1haWxpbmcgbGlzdA0KPiBmb3JjZXNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9mb3JjZXM= From joel@stevecrocker.com Tue Mar 15 10:50:25 2011 Return-Path: X-Original-To: forces@core3.amsl.com Delivered-To: forces@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1DE03A6D28 for ; Tue, 15 Mar 2011 10:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nkfkJE2Zo+Ix for ; Tue, 15 Mar 2011 10:50:23 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id 864573A6971 for ; Tue, 15 Mar 2011 10:50:23 -0700 (PDT) Received: from [71.161.52.147] (helo=[10.10.10.101]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1PzYPM-0001J1-8U; Tue, 15 Mar 2011 13:51:48 -0400 Message-ID: <4D7FA730.8000901@stevecrocker.com> Date: Tue, 15 Mar 2011 13:51:44 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Jamal Hadi Salim References: <4D7A6FD9.3070703@stevecrocker.com> <4D7CEA60.5000403@stevecrocker.com> <4D7EC79F.9060604@stevecrocker.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 9f083ca8aeb2d326d5a073bfd238dd844d2b10475b5711208057c19c2d0a5a029bb4dd2f83228ff908a8bb3e8e732a70350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 71.161.52.147 Cc: forces@ietf.org Subject: Re: [forces] LFBLib v3: comment #2 LPM/NH X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 17:50:25 -0000 I think the NH applicator selects the NHOP IP address. I suspect that we have been sloppy, because this has to work with unnumbered point-to-point links too. The MAC lookup is based not on the original IP address, but rather on the next-hop IP address. Yours, Joel On 3/15/2011 9:14 AM, Jamal Hadi Salim wrote: ... > Currently: > 1) LPM feeding a NH applicator a NHID > 2) NH applicator only finds one destination detail: the output port > 3) NH applicator feeds etherencap an IP address and output portid > 4) Somewhere within Etherencap we take the IP(4/6) address and do a > lookup then we either ARP or find the dstMAC address. > 5) We then find the src info (srcMAC and VLAN) > > I think the idea of an IP address passed in #4 is useful for the assumption > that we are going to resolve the dst link address downstream (which i dont > mind supporting) but an IP address implies content search which someone > is going to have to scrape if they use an index to do the src info. ... > cheers, > jamal > From hadi@mojatatu.com Thu Mar 17 05:52:42 2011 Return-Path: X-Original-To: forces@core3.amsl.com Delivered-To: forces@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC9D43A6930 for ; Thu, 17 Mar 2011 05:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.923 X-Spam-Level: X-Spam-Status: No, score=-101.923 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HJmRunZBbVpV for ; Thu, 17 Mar 2011 05:52:42 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id E71513A691A for ; Thu, 17 Mar 2011 05:52:41 -0700 (PDT) Received: by vxg33 with SMTP id 33so3001431vxg.31 for ; Thu, 17 Mar 2011 05:54:09 -0700 (PDT) Received: by 10.52.73.193 with SMTP id n1mr1782435vdv.226.1300366449093; Thu, 17 Mar 2011 05:54:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.195.73 with HTTP; Thu, 17 Mar 2011 05:53:49 -0700 (PDT) In-Reply-To: <4D7FA730.8000901@stevecrocker.com> References: <4D7A6FD9.3070703@stevecrocker.com> <4D7CEA60.5000403@stevecrocker.com> <4D7EC79F.9060604@stevecrocker.com> <4D7FA730.8000901@stevecrocker.com> From: Jamal Hadi Salim Date: Thu, 17 Mar 2011 08:53:49 -0400 Message-ID: To: "Joel M. Halpern" Content-Type: text/plain; charset=ISO-8859-1 Cc: forces@ietf.org Subject: Re: [forces] LFBLib v3: comment #2 LPM/NH X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 12:52:44 -0000 On Tue, Mar 15, 2011 at 1:51 PM, Joel M. Halpern wrote: > I think the NH applicator selects the NHOP IP address. It is. > I suspect that we have been sloppy, because this has to work with unnumbered > point-to-point links too. Did not think of this but that may be a good reason to revisit. So we need further discussion at the meeting? I have other issues i want to raise.. cheers, jamal From hadi@mojatatu.com Thu Mar 17 05:55:17 2011 Return-Path: X-Original-To: forces@core3.amsl.com Delivered-To: forces@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE8E73A695F for ; Thu, 17 Mar 2011 05:55:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.927 X-Spam-Level: X-Spam-Status: No, score=-101.927 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TB6lYaU91BRm for ; Thu, 17 Mar 2011 05:55:17 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id F0F533A6930 for ; Thu, 17 Mar 2011 05:55:16 -0700 (PDT) Received: by vxg33 with SMTP id 33so3003936vxg.31 for ; Thu, 17 Mar 2011 05:56:44 -0700 (PDT) Received: by 10.52.73.193 with SMTP id n1mr1786525vdv.226.1300366604594; Thu, 17 Mar 2011 05:56:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.195.73 with HTTP; Thu, 17 Mar 2011 05:56:24 -0700 (PDT) From: Jamal Hadi Salim Date: Thu, 17 Mar 2011 08:56:24 -0400 Message-ID: To: forces@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [forces] preliminary agenda for IETF 80 posted X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 12:55:17 -0000 Refer to: http://www.ietf.org/proceedings/80/agenda/forces.txt cheers, jamal