From hadi@mojatatu.com Wed Apr 6 04:52:41 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 1E47F3A6922 for ; Wed, 6 Apr 2011 04:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.931 X-Spam-Level: X-Spam-Status: No, score=-101.931 tagged_above=-999 required=5 tests=[AWL=0.046, 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 cbnOez3PlnfA for ; Wed, 6 Apr 2011 04:52:39 -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 46CE33A690F for ; Wed, 6 Apr 2011 04:52:38 -0700 (PDT) Received: by vxg33 with SMTP id 33so1239930vxg.31 for ; Wed, 06 Apr 2011 04:54:22 -0700 (PDT) Received: by 10.220.95.143 with SMTP id d15mr90392vcn.157.1302090862328; Wed, 06 Apr 2011 04:54:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.181.8 with HTTP; Wed, 6 Apr 2011 04:54:02 -0700 (PDT) From: Jamal Hadi Salim Date: Wed, 6 Apr 2011 07:54:02 -0400 Message-ID: To: forces@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Zartash Uzmi Subject: [forces] preliminary minutes for ietf 80 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, 06 Apr 2011 11:52:41 -0000 Preliminary minutes uploaded. http://www.ietf.org/proceedings/80/minutes/forces.txt Thanks to Zartash Uzmi for taking the minutes and to Warren Kumari for jabber scribing. cheers, jamal From hadi@mojatatu.com Sun Apr 10 07:15: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 2E9C93A6A1C for ; Sun, 10 Apr 2011 07:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.934 X-Spam-Level: X-Spam-Status: No, score=-101.934 tagged_above=-999 required=5 tests=[AWL=0.043, 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 VTZQkVrMDtOb for ; Sun, 10 Apr 2011 07:15:25 -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 305913A69F1 for ; Sun, 10 Apr 2011 07:15:24 -0700 (PDT) Received: by vxg33 with SMTP id 33so4483858vxg.31 for ; Sun, 10 Apr 2011 07:17:11 -0700 (PDT) Received: by 10.52.65.69 with SMTP id v5mr2337760vds.200.1302445031116; Sun, 10 Apr 2011 07:17:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.181.8 with HTTP; Sun, 10 Apr 2011 07:16:51 -0700 (PDT) From: Jamal Hadi Salim Date: Sun, 10 Apr 2011 10:16:51 -0400 Message-ID: To: "Wang,Weiming" Content-Type: multipart/mixed; boundary=20cf307f344a6b4f9404a0911d10 Cc: forces@ietf.org, "Joel M. Halpern" Subject: [forces] LFB LPM issue 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, 10 Apr 2011 14:15:26 -0000 --20cf307f344a6b4f9404a0911d10 Content-Type: text/plain; charset=ISO-8859-1 Weiming, I have attached a couple of slides without going into the little details of the LFBs. Slide 2 demonstrates i think what we agreed on at the meeting. I hope you and the other authors can review and respond. I do have many other comments on the doc - mostly in regards to readability. cheers, jamal --20cf307f344a6b4f9404a0911d10 Content-Type: application/pdf; name="lfbissues.pdf" Content-Disposition: attachment; filename="lfbissues.pdf" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gmc20qre0 JVBERi0xLjQKJcOkw7zDtsOfCjIgMCBvYmoKPDwvTGVuZ3RoIDMgMCBSL0ZpbHRlci9GbGF0ZURl Y29kZT4+CnN0cmVhbQp4nLVYSW9bNxC+61fwHEAqZ7gDwgNkWy6QWxoBPQQ9uU2LQC7QXPz3OwvJ Ry2W5KaGYInz3nBm+M1K2xWYl8U/xpqlXTmTiltlE0qg9fc/zK8fzN8LMPz5/ufC8gvzvGCmJOu9 0TXtRSLsvNC3fy2+fmDhK7BQ4skvybzbLVwhCZ437n43Pz2SMm92X9cWpt23xXa3+HSDhLAKPyYC k6PdwcaVVxloPMv4QkIsWmfdBGvrLXHYZPO0JKoQvZl+231UFZaQ4z/BCuhU2WBOJPV5UXwn9kYI F4oQkE+pynggo2JpDX9++Vk89kJ/H0ndt3fR9vkG1ACBAsVBXJWGGmRB/s7e24eO/gE0SN5K3VgM tlN7o1Qz0PlTqpk7SrkMzvvouwUezMhwn8BDQbWdwto+vhI8PnIoN4s9hE7tjVLNxmBPqWbxKOUy Qu+j7xaEPPizAfRlDZYRitMyrAGsn+KakpDyjxYUdQ78jB1yCXLIpSlzIeDl3nyupyVF4rrKgKTJ YSGte1MJdjMlSmM6xgryvB09sEePFWDAxuAYmqagUaqhcR0rcC53Bd66cwoIp84Ag4JGqYLGNRde /qzCWCoDl3aHmbQI4K6HJNW5ackwM9b+1dB0pAZroOS6ZtW0jlDD4mjdePre/eJyOP5fOm4KQe9X 0Xhn58rfQjBQCEK09zMWPjJ83nLhfK6US2rG6C5lA3EYWQm0pdlXWFunGl91WZUYQTYyq0scEHuj Ymaq8bVgGp0UKUpjz+dQYqcILKFaBsd8SrV8HqVcrh/vo+8W50XHe840IEiQevuhpl2zJ4j0k/QK Ja18Z/GSjZpgjdIEm/kupFgQa5zNzaY5xYIkWJQEkzGCFmXItAZvzByTak8iV5+pCCnNDE5SWg1u lBrcuC6YG2V4OmvuhkpusYmtzKOdr4vBfKaw6CzAJz/uetfcm6g9Hwjt7s3zbNFAC9RLaGpzQXIz Bv5V6tDX1ncmdhUzcRCRd5Witg9SVXzfLuDFGAfpPC421kpVMTPfjQNwCCgViOfgowoUGTAPBTZw x8s8Fubrctk82k0YHo0fQTtqgXsA7qgPsJEOe7twKNp1T1xjt/YRtvB4+/QegEIPSz41k0RxCd7y FDCW4as1PUmZyfYI0WociTqJnqMWRNcXnxN7mpqJk3Wy5OOYSLCsPJonXVHYBKN8rtBVhvby79PC JebmNYVw5ZOV7JWVyFM+1tH0Ps31b5xkeYdY1Vb7s3xsFWt97qubJ9ZAEUPh1m5S3gB3lTdexzgy gGo7NPBRr2NpFEEfaO7i3jtsCLqBZxK+daHctty0xPVh+EOVMux/el7wleSlviHH0qWUupKh2Wup Xfr6AQoe2oPdnqQXP7YqTLhGyzTlDsqroK+gTL7RG6YlxZxsjfKtYjZypax7ReKyPeAvhPmVzsGb /gAKoYI8CSPxLqtOKGxQWOs7Lhj0BWtENWa01qllTtbT0o/alAOP7VVmXfr+ABCd2hzfkJ/IYRZ9 G7n+U5jREEFCAre9Qy+hWCcgVOC8HggPz7PhbwWlwsx89VTktPn5HbtDHB4b/sB4qQiFcnB64VId Bk0P6o9m1OxzTIz9+YBSt2SFPXbB+nKUjvJI5KsSOQbWs9ZQmtnLEEdV3xAG5XYvarFwqRXZHygW jjvghWJxOZok/U9E8ABPDRS4c9DB1FVbBulx6p6VQytgZYZxjBXJ6Ip5T3NstKaN7/hRYsbuwhph nP66TwJB05GeZ9mwOZCi6vX9HbF3C+7H5MNqUfPwsobPaLI7lKZ6tDzUo9dIr/vHWBqOJoGG95eH vwDlcBgYbpUy+PF/0Py1ARJfk8H/dPNvmkOdzy0arl9wP5l/AS60WJAKZW5kc3RyZWFtCmVuZG9i agoKMyAwIG9iagoxMzk1CmVuZG9iagoKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyL0Zs YXRlRGVjb2RlPj4Kc3RyZWFtCnicvVlLj9s2EL77V+gcwC5n+BAJGALsXW+B3NIs0EPQU9u0CHYL NJf8/c6DpGhb3oi7SLGII0rUzHDmm2+GlNnB8G3z72CGrdnZYUx2FwefPF1//XP49d3wzwYG/vv6 18bwg+F5w5NGuX4a9JreRRqY+UKf/r35/I6F78BAClf/k8zj48YmkuD4xcc/hp8eSJkbHj/vDUyP Xzanx82HFRL8zr9NBBokT3gTdk5l4OBYxqc93k9b2BuEO7gzDpKMgnEIZgTkEcBEP9b4POG3x/eq 1JAv+Z94D2idcbAhkWufN8nVwdMgA+dABhCvR3nimYzsXTPw3y8/Swy/0b/3pO7LD9H2cYUfAVmS TYm8mf0IUWJxNHfmvsbjzDVI8RursehNHT0NOioGWnc9Kua2Ul52zo/Rt8Y9GJFdeuWeT3tzmvze PNwAjwsM7mKxA19HT4OOio3eXI+Kxa2Ulz30Y/St8ZADtwigT3sw7KEwbT1lnHFT2BtrnPF0Qaiz 4GbfoRVKGUn78yYqOYzCTB/zikmZhK9Owl2ilQGl/9OgA8O/lC7ztEufQWxFIPkgLilCj/Mkyims ivIoa5rnXSqyNmZFwOEwdlkR+a4qcgYaRXmUFc3zZormv51vSdVzEXBg6BUJhK1QBUO8x+7nGDRu r/YSj1Zrw6jWOlrBmbUhOrntZRLjxxm2jq/ZVjKHR3XWC7Z6h7TMJVvBMFebkS2NpuHm22Js4rS7 WPKBsJb6xIxmFy7FKAmy7zTdqXS0ol6mVim1FNELYj2RmBM8rK+WHshNdvRXDET0Q7l14gwzd+sN ywK9K25rUpaKouZm2CPBzwTQ35PxCAIfPK3XhJ4gZcGqGjeARKqvV2AnWsJmKrai9grjahFUBdyC COFwYA4HlsaNwWFC6hz4R2nLtWN6nvI8ezbiWXQLOcG2Ls9tJKIpN/weo3GzPJFDfi3vl7vIs9fH M3IeNQsMdYEwubwAol6xwlc9pIIuY757cUPbJnnzIJdHvjwDGUgqUXwb9b8/b5gYvt20mMiGuk4i vAESc+RWKfH7i/RjovR8IxC4Z8Q4kt4MyMTSuvDok8iw1QjUzGG/wlHibxlQbtL4IseXgowcf8e3 6GHUJybBUa/gnqcfOUb0woMZrWHORgZZ0DcpRoIn6Wb1Dk6CQle1aIebn6gdqoitEQEcerLiiNiZ xRhgdttr8xh9KBxbkxA8BDbsjqCKijVOS5jTMqeVpFmSjCJHQ5uYBNeSvb4zebgL8IuGNWoxitcO Uk6mrc13YSkdWoEd6UDFwnVkg6DQ+mK0hMR2hmQMIqSWPaINW2iD1xgn+rkXJxwpJuxnfYC5keso heyNRhVWVSMrSSyW+ZTKzyFzqGU0W2Yfy5s1oUqGutN3dB5Rq8w7EXxgb8U8S6kGh/wCT8237Xp7 KRjkGeCO5tVEQT0vC6EGO15whaV+TsBNdfUg6TmaRBCTUtLQQNR2bYsldZU8JINNUirw9X3DbpBH dxNq6sg09moS+N4VEshaK08RkEWKirR5APPMA5cREpN1jyr2FgfhUZhLGDFMYhCXuYPhrodi1tGq CM65bYe34hxiPW6YwXfSXFaQ9bAGIBevRqavMgvLSli491QHWulExTPkM1ug3OELDEwRi+uQ/OlJ SIxwLmu2/05XcJ+ZWKoH9Ui5S7C8NsFuVHwpda9W7BB3uLyIIwqYMcvPa0JQT+GJj3Dm9Bdekqq6 Hkwx8v581t0SntQTqd5CbTMHyaVQoc/g56DaMv1gjr2BVDwGM4O6n12EoUC2fC25UMQoZWchpSg1 06Um4XdrEu+Nn6nRoffkel1d4uMkXLDr0/6SnZSTBGtoGkIS1svtUbhgOcgEVHgK9pV3Op1PldO9 1fnWlIZolfNl+v/h/Cu72PnKPOI4rQNaElBKChQI41lpCLxN5WZU+d/lIOgbTWMpd7SGcEKCXOVG N7dQoNWllrIsi4qWLV2tFEDSxbta10XGGlKopwCvD6kJ8ylWdh3e5y7zGnZdBcNzHBsFvu4czCRH 0ixQdgFSHWKvAsR4rqAJ/rzx8O1WwdUCT211yu3CfcWDxLKjabKjv7FEbgDcvPUUVhVwQGn9ZMv7 kPmW7HFSZcg12msDdxN9eIihsPyr4RBh5y/RoCUwKW+pHztAIBvQWeyMAdCDiLr+V2IA0rLZEsiS fN1mY4g3zA7MGKNEMFLSQupAC46ElkVbczvqSs9bdsop119ho1IKZDGpVIiORiQwQGb9oeoHPfTZ lkOTwlkPUyqEZyRIYI6arx0dCJ89LCya25nMnpcsaeu+nzY7qzWFMZGSq+VxpnXlAO36w1v3QLQV TtdboJTLgkQx1a3Q1aakhwKRv3OG5hjs5ZDq+d5pqkcMSQ9O1JKjtrZSJntYMC4v+Xy7VzKxAB21 ORobms5nPdBkg+3MXO8igXzBI6C9rC6dd/VQz4xqwe5g3OBuxFkWfXHC1bcLt284q1P4WbxqRvM3 4vCmih644M7CG9/mbZPVg60cufUwlg/sC1Zfsvi8Zwe30C+XRq3nJHnExRWN8gFPt67rGRbks8rS OgphL3b+N484+kneEyQXY9RH8iu+Hjm8+gR166vbh+E/qJgU4gplbmRzdHJlYW0KZW5kb2JqCgo2 IDAgb2JqCjE5NTYKZW5kb2JqCgo4IDAgb2JqCjw8L0xlbmd0aCA5IDAgUi9GaWx0ZXIvRmxhdGVE ZWNvZGUvTGVuZ3RoMSAyNDMyPj4Kc3RyZWFtCnic7VXdbxRVFD93Zr8KtN2WSpuswh0GENjdblsR bQKyiGxTClLbAju4iQzL3d2hO7PLfhDaBEv9Cq7RhMSYCCotYPRFc1dN9IGYoBJfrPErfdAYNfFB H0jUxBhjSj0ze7s0QOI/4Ozuvb9zzu/8zrmzc+eWCmUGy+AUyBBNmnq+jRDA6zMA0po8XqJV7wE0 yY84PJDKp83HP7zCACSKPp7OjqWebP/nJwD5C4y/l2H6kWb10gYA11Nob86g44m5A160L6O9JmOW ThyCxBK0bT1fNpfUN8JBhK5fcPCY+om8X1qBDbh+Q5tauska3nz7cwC3H31qPlcstcHReYCGTXY8 X2D5TPDTl9EeQTtoNwpO+7giIB7H/v96Ec7As/AW9MMF0CACmyAEPXAIHgEVHoIHQYErcBW+hI/h EjwDL8EknIMp4PAGRAGnEIflA3zjYJzvOq5xULd1cE8wvlVzfCc1+g0nyzs7wpyE6Ld8WTDMpdDA UHynqilhLoeMDsqjg3GFR7Uwd4XsVEVVxuPfB2a0APLic4FrWkBVuDsY57HjmhPQNNRzhxoTB8Pc E6quJqexOj2dSAQ4oIw3VF3juKJ1ly/U2kJ7I2HeEKIn7SKfoAzl8tp+lXLXul0cBuMVVtGpDe4P KIoWqDjWUM2yCy6pdecP+BVUXBqiXznLWRaiEe4NJuKU9qkx/SiN0yOHaxI2r9GujKVphfZVYrpa oRXVKafa4jyKTFyf7eBRZhuY0+RU2jrboSgBOlvB24BJ/djNPtGb4tCaQyqdFcVVGh8YDiicaPEK Lqhfrai00l9RdTuhlmJPYZDw/wN50pPCHe2FjfAOPgFB7prh3ggnM4T7Ihxmbdvlr7pJkMsz1QYS hK7ue1qUlrVKizIpw9yEBNfBk/r77KQ7BfYu+gH34IRrChphrVD0zizMhDdFuGuWL53Bb7XZEVPo 3ev8921WaPsKv9cjh6//fn5q6jxpJo0XL1y4OD0lrZyanp6e+3l6GqC2S8m9H515tPLXY81b/oRV PufBvfrHxV8XP8juCY/djQ/XWLswz7t/bmIR5eb9LrkAJj0Ju3+ovWpshgRNQkNy3hh+2y3Ni5zV 5LW6zsq6JoElaBGR5YX1AsvojwjsQtwrsBvfQTsE9qB/bw3j0IG7sIYJNMAxgSVogXGBZezoudpd cfjnBLb57woswSq4LLAMrfBdbWU4KHBNYOSTJoElaCftAsvQQjodLONwB9kmMAEfGREY+yEJgWVY TkwHu3C4k5wS2NZ/RWAJWsnrAsvIeR/vDHE1oL2FfC0wgTapWWD8DyRVYBn93QK7EO8U2A0dkiaw B/3H1ic30J6url46XLboHiNZyBXHiiVmFmm/lezcm2fW8Jh5OJcdYulyVi/ccNxA+1mhaOQs2t3Z 033Duz2bpSNj+Vy6oOczRpLGmF4qF1hxt5GuAUFg9ciOnGmiTJ0Qy1nJEgoXaamuc6y8SGEkVy6x Ik39F4/uK5ZZNuuUZAuklFFMZhiu+Ww6ayQzo8woMWshxXKY28vFcYYxq2yli3oB4w/nCqaOkTov VrbGsbRBRwyhiqK7WS06Ui6VGEX6AmshQPPGqxSXW7aMW1uio8wyWWH05m6QxOqhPmYyZiFdz+dZ 1jg6uqgn3EhJ2AAUj6Qu/PQiGoYyWDjvAQNjBchBEcbwVwIGJs4UjzILI524qfLoszBjDCOHkZmF IfSkUSELOubejnE73370FFDbQMuu3Y3qPTjejotPpHPNp6HtltMWrw/I/NOcPA8D3DcYrxLyglaN 2ScL9+Oh2TaE4JR2F54AibgG/wIyMPZnCmVuZHN0cmVhbQplbmRvYmoKCjkgMCBvYmoKMTM2NApl bmRvYmoKCjEwIDAgb2JqCjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5hbWUvRUFBQUFBK09w ZW5TeW1ib2wKL0ZsYWdzIDQKL0ZvbnRCQm94Wy0xNzkgLTMxMiAxMDgyIDkxNl0vSXRhbGljQW5n bGUgMAovQXNjZW50IDc5OQovRGVzY2VudCAtMjAwCi9DYXBIZWlnaHQgOTE2Ci9TdGVtViA4MAov Rm9udEZpbGUyIDggMCBSPj4KZW5kb2JqCgoxMSAwIG9iago8PC9MZW5ndGggMjIyL0ZpbHRlci9G bGF0ZURlY29kZT4+CnN0cmVhbQp4nF2QQWuEMBCF7/kVc9w9LFGhNxGKZcFDu6W2PyAmow3USRjj wX/fMWtb6CGBl/e+5E102z115JN+5WB7TDB6coxLWNkiDDh5UmUFztt0qLzb2USlhe23JeHc0Rjq Wuk38ZbEG5weXRjwrPSNHbKnCU4fbS+6X2P8whkpQaGaBhyOcs+ziS9mRp2pS+fE9mm7CPIXeN8i QpV1ea9ig8MlGotsaEJVF0UD9fXaKCT3zzuIYbSfhiVZSrJ6aO/Z43Sn9rF+2oBdmaVJnj1X2B/3 hL/fE0Pcqby+AYr0baMKZW5kc3RyZWFtCmVuZG9iagoKMTIgMCBvYmoKPDwvVHlwZS9Gb250L1N1 YnR5cGUvVHJ1ZVR5cGUvQmFzZUZvbnQvRUFBQUFBK09wZW5TeW1ib2wKL0ZpcnN0Q2hhciAwCi9M YXN0Q2hhciAxCi9XaWR0aHNbNTAwIDc5NCBdCi9Gb250RGVzY3JpcHRvciAxMCAwIFIKL1RvVW5p Y29kZSAxMSAwIFIKPj4KZW5kb2JqCgoxMyAwIG9iago8PC9MZW5ndGggMTQgMCBSL0ZpbHRlci9G bGF0ZURlY29kZS9MZW5ndGgxIDIxNTQwPj4Kc3RyZWFtCnic3bx7fFPHtSg8a2ZvPS1r62nLtizJ 8gNbQjKWbfyStcG2kEMAGWywDcY2+EkAG9tADGkwCRAwJHYoNUlJAj0laUjSIAhJoGmKm3KSpk0a mqY9tzc9F5+eNPe2DYXmJLlNgu1vZkvmkdD87nd/31+fjPaeWbNmzZo1M+sxM2Kgb3M7ikNDiCBx 7YbW3oc2ti5FCL2FEOjXbhmwXwn+3UHTEwhhY0dv54ZZvvf/hhD5BCE537l+sGNrzbpfI6S6hlDZ I13trW2f/WObC6EFhyiNwi4K2D11n5zmKT2U3rVh4O5F5i9fp/mrNP/f1vesbf304KYxhEI/p/mN G1rv7i2SVRGEqoto3r6xdUP7/acP1tJ8PW3v1709/QNjKGcaoRo3K+/ta+8tXP3zcpq/k/L3WwoD +sc+cTQpY3lMOF4mVyhV6jhNvFbQ6Q1Gkzkh0ZKUnGJNtdkdac70jMysWdk5Lvdsjzd3Tp4vvwD9 /+jDv8W/hb7F70QmNCg9b/lwJciItiI0/RHL3XhOrfj/lgtF9HUGvYpOomO3FO1F99Lnc7fAzqOf oWel1BH04DeQPYeeiaUOoUfRA/8Ubx26n9I5Ttu/8Wmh0EH0CG35LPoBnShp4KOt3hUrfR+9eXtS 8B/wJjqInqaYB9HL9HmEzrzt+GN0EC9FG/G/kZ3oPrSP9vEodKMRit+CjsNKtJpCo5/VqB31fIXo MBpFT6JtdBVe//A7p/8Laa79gHK+j9IZQ91o0001nobP2YvYKO/Poxcl2M6ZQnmIrMMvYTz5bZp5 GHXSbyv8nvL5IJmHKnmdWNVQX1e7bGlNeMniRXcuvKM6tCBYVVkxf54YKPeXlZYUF80tLJiT6/XM ds/KysxId6Y5bIlGnaCN16hVSoVcxnMEA3JXOYMt9khmS4TLdIZCs1ne2UoBrTcBWiJ2CgreihOx t0ho9lsxRYrZ8RVMMYopXscEwV6Gyma77VVOe+TtSqf9LDTW1NP0g5XOBnvkspReJKW5TCmjoRmH g9awVyV2Vdoj0GKvigS3dA1XtVRSeqfUqgpnRbtqthudUqlpUk1TkVnO3lMwqxykBJ5VVXIKI4WG NRshGVWtbZFwTX1VZbLD0TDbXR2Jd1ZKRahCIhmRVUTkEkl7N2Md7befco8PHzgroDUtrrg2Z1vr qvoIaaV1h0nV8PADEZ0rku2sjGRv+yCR9rw94nZWVkVcjOrCpdfbWXijSYjwGYLTPvwpot1xXv7o VkhrDCLLED5FLBmk4h0eDjrtweGW4daz00NrnHbBOXwqLm64t4pKGIXraa2z0z/anxwJHmiICC1d UBLrbHDpwoihZmV9BGcE7V2tFEL/BZyOomSHrmEGJ/zPihEVBBUHlanDwTq+/6yI1tBMZKimPpq3 ozXJp5HodTVEcAsrGZ8pMdWxkqGZkuvVW5x0NBcuqx+OcBnVbc4qKuP9rZGhNXQ+rWND4RQi8Z8l O5zDep292Nsg4dopV9Vt3fYIn0nFQmvdXIHOFFZlWJAy8Z9FX5eTaQOZOr292EnJMDpVzqqW2L8t XYmUgH22OxJyRYe+tj4iVtKE2Bobo6pTuV5ao7WFDlF3pTR8Ea+zN2J0zr8+noytqu5l9VKVWLWI sSKCWtbGakW8VZWsZXvVcEtllAVGy1lTfw75pidO5duTX/ChfNRQyZDNFXReZVYN17d1RGwtyW10 pXXY65MdEbGBDnCDs769gU00KqHsCdqcQ2oxgitq6xcucy6saawvijESLWDkuIyqr5Bx1idHydAp F1FkKOz1OJk0UESBAuxBmnDOL6PPiDxDQb8CFbgEZVN1fpm9HpLRDDZlI5Jtr2qvjOGx/C1EeTad KkIz1GQsS+lUhJIdDY7oZ7Yb02J7rGFaQ8GEGpopIhlUE1AYpmQkEJNlIpvz9npnu7PB2WWPiOF6 1jcmHknKMWFIMo+NVe0tuZuERcWEHLR4JsOEGQm6km8WbmSBlL+eDX2luHqm2D6scC5cNsyIO2ME EeW8OoLYFBaLdMnS6mfr2RlspYuYrmhpPQ+fEkW2lrvYsh12VrcNO5fVl0nYVIN8K3kba0uPFsLC 2vmz3VSZzT/lhL01p0TYu6yx/pxA3am9tfWnMeCKlvkNp9JpWf05O0KiBMUMyoAsY2cZRmkpzSgk /ORzIkJDUiknAaT82rOAJJhiBgZo7VkchQkzMExhXBQmSjD2oaOU2EVlTPV3lb2Njc89DV3DLQ1s jiMzlQj9BxFwllPpOMtPAZbFRVTO9vkRtXM+gwcYPBCFyxhcTmcGmGG2e9uwUOX8NHE2M5QYVdJH G19HvV858pwC5C07LecUl/NOyfg/lJ0mmCbRKcLAPAOflsuU18pOA4P7dA5dhkPnqMT2qXR4ZKqL r/vi2UrubeYkoK7pj/hBfgxloR+KSwbj98XjzZrdGrw9Y38GXpcJ96QfSMfr0mFdCtTJoZFAjnWd Fe9JgJyEdQmYV5gUmMcmjPmV4aSWJHwy6XwStieBNgmS0oSz0+NijlwTEoRsezYscYLTiZptHNIK WpyrFbW92iHtuPaiVqbVqppNBhS47PM2bZKe0KTzeV000dS06fKc3Cb2QU0UPPOGtHhsMqZiX145 npsQT5xp6Zm4IF9fmO7L4xLkHkIS7z73LbFq5yublz6wYbnjsczew+e3PDs1/cPlK08COv4f4Fnw orGyYx/3RfjQxR07fvNIrWvxXfMWL9nbVrzhZxB39ElQvdIe+WFZ3spgDpXT7umPyF+pF5qBBsWq MQJJjhxHiYNY4oOiVz2ixufVMKI+qp5WE3XWEAQvpV9JxyhdSM9Nv5rOKdIjWeNZF7NIJOtqFp7O gt4syGLS0RgSQhZZ2GY2mOKQFgXyAoHLeeCine7zrqY9TxL+QJNJl31zclmvdbEOF+h8LJng9JAC J+u7h4KgJCG/LiB2Vs86AxjDMzSiwCSpfOm6YON9tVlcyeTSJevmJc+u+1YN7r/2w7SFFbly3l1c avTeWWB1rxptx79m82EvnWd7ucXIhsrFWYIp14RNJkecLTjO4hUB5aIJdBXxCmSZZTCHLHF6Qa6l vnogEPC97QKJ5zw6ck1zcn26fA/O8qUSk6+c+PLMCSYPONmg6R6KskcIcAZXSbjYPEutz00tXzE3 iZSnLZhfkpBQWl5sLF9ZapWTJ3m+aO2+msm32BpYMf0Rl0h5S6GjcJfoaXSuc+LG1HWpuI600xVQ rVQmLxBtVhi1gjVrKAMtsOlAlxuVvCRuQ6ozpFDwKJyRwdvDZoEPx5vprAtc1hd7L+uKveDa5G26 nCdJPelynpfNPCZ3SeyF0WmGdfnlNJeKrZAV7ZEcjM7qvvDmBy1P6Pwdj66/+uWduyJte1/u8f5I O/rA7LW1JRz877qRzuLVodmzV1Z7IRWSHvnNrtL6I+9uSxx+9nHrHTvWoJjsyd9o/zLQhnMobXpC TJerQxlBMYzgKJqmAsgaQlJvJrK48SzQZsFQbB7Z2TyKC45rAGkETa5mQnNVwys0bGoJBq2GjVB0 akVHyNW0ic6qaC/n5LocbKiiY+O8ddRSKYgUf9O8ws/PzKrJB8myr86qh9smvVIwgmzTV3EO70Zm tF1cMSseuuOZsiGzNNCtGdTs05D9HHB2pSa0nruHe4x7juNoLi7UY95hxuY4jZkIQaVihAfEC7yd F3lOzg8lglYWjguoQKXUGsJEGsq3m3y0m02snz7f5YQ8NhWRq0laU02bMuLpiBXonAW+uT6Tz+TU Gc1sYHFOdl3Rf/vWroK7f/5zXyBpjlWh1nyK373/44/vn6xbHFDIon2Q0/H5nOoAAa8U5xZDNeBH AQpREOE9NO7BJdo7tPi7WujWDmr3aUkBqSL4OwRIJ9lKHiAkXtDoQtzZ6atiOU0AUiqxVhBcwnYB c4Ix+qgUaoVdwiHhgvCeoHhfgBt5PlkATgCFQDAjMa3GKzHOwWp9sl56LNSv1O/XH9H/Uv++XjGt hwv69/T4mB526Q/pcYseKvW1emzXA6c36vEbEzcQGIAVMkTZTIIVypJZIbzPUOEIowQrGR2Iwg9/ rdXoi1C8r7Y38XV+ZprlOm9mgGEp/lmLUXi0WXFttGHZ3JtZkAX08A1t3sLTVwtxWA9ePSC9oMdy LdYqgS4aX8AHq6nJaWZ2Z1Ps00c/q2/Or5bMU9OtOSk/gxrNM51e5POujmb6inz6Yr/XR3W7y0Vb 2CTN0KZNDif4DKkkoZzMNfhw+2+nto7/TW4w6mQyg9Gk+Ow81eSiOVAZMJkC8wNm/FrUP9hHJ6if f0vyD/pFDZEHEeIELpcjCk6yw6bEEMcplNNKmFDCJSVElONKfFQJvcohJbYp6XyEq1KBkqHr0jJC S5RA4byWM6FlVPnTxRWApk2uaK/YR0fVpms1W3Bzcg0FPhOhZmnfmTNnePtzz30xwZWwDTTK1vQk 292h6yaHnBLT/5QAJdl3ZONt2cPZ380mBUKVgDcLu4XvCKTQGrTiQqq82Qw300VSnFKdgotTIIUt HWmhIVakVNOcJqjBGpbz0Zy0GEFgqfjqeEzXmlIXiteYrSlyQM5ZTqh3glnudMrNRJudI+SwLlZ7 80LVOZCfA5k58HkOvJ7zYQ4+ngNjOTCYA4U5wZyOHGLJgU9y4CVWtCvnUA7uyNmSg4ulKsYckOWA IkfQSgtSqW3QspXPqbSvuz90f+Ymx90w5oZBN3S4odYNhe6gG1vc8IkbPnTDBTe85IZH3bDHDQMS SrEbjO50N5a54Refs6ovuRkhrjtWVem2uDGtec4Ny90d7j1uQmu4WCWgVT5ww+9mqP6LGw5JhPvc 0MawId9d6cZpM7iPfuaG19zvuvEZNzzlhl1u2MI4bHPj+QwVzO5MN+bc8Ef3x278nhtedwPty0EJ s8O9xY1nepPOcIFjfRJ/G+vVaQmZ8TfmJpXuWjcunGm3+zNGE96b6RwZcO9ixUHaHZLOUMxu/Anr wodufMh93I1pH7qlDlSy0kI3vt7NpygFvE/qIrQwHtJpU6TouPuC+z33J25uSBLrQjfkxsT6pVTt mCSa7VGJtLlJshuuSsL7JRPVLvch9xk3F3ADRm7BjRXys9QKz4rXhebLIV8OaXKQp2QTrdY5K04X mk3nlPQ2A5idJJ7qiwRfk6vJxV5NTS6qOZpvUgyxZbM6pk1u1Se3KIobRTcX34rxVbqrvw7fdJO6 uRXdRVVPAtU9Xu+mPp3PF/1H1VAzXd3SXxP7x/6oNiIeyMrMksnjQU4k1QQJ5oTCueVA1dMtGW7s 1z9U6BQqpVKlMChOX5z69emX5fFyuUKhVAiyCz99VS7QtEIh18rPR/CPksOZbu9sd+ZS2+QdVKc5 EirsGVmZ6TbRhP/npCVpvjXNSXMVSfgSs71PU3Xm5XciHhVRv5TqNczUm50TuRZuiDvGXeUUHGlk LqqIiBxR77IZ6ZnOYi7PZRpWMI+URkKmp8/jn/M7v0x+LKo3Gd2/ULrxKAFtFpedwPDtBDgiPCtg FUkiOYTwcaa4jDiCGkWtZUi0AP1nlDcihaAQFUQha7YZvcYlxmbjDiOvNb5jnDYSuVGk2sdolBua lUROmZD8SxfzvIC5l9TrEv7AHC8kDQsY47HTQT0vB3W35PmZNO3IK+T+4h98aXBqzXlc860f3VM+ fvz41G64/8kj5Perjm6unHyf3+nvebx1z/7J9w6imHxkmPbDjd1i3CPZcNgGcYI+MRRHldMLVHtK qjKZAqjHpWHqNMfuyKAPfQp9UHZT6Ux/gUKkNwWyN1VqtGJcenqye1VOOspH+D0E+9ERhDkECuTZ 74EBD5R64JceOOMBtQfeedYD+R6we8DoAeSBTzxw0QMXPBBhqLs8xz2kxQO1HhAlPMEDnAcOX2XV L3g+8JBjDO2QB4c9UOmBXFac7sGUygRDec+DRz2wywO9rHalp81Doi1Fm4k2cMHDtbDiWg+Oku9k FKP0+XCUYqWHGD1RCrs8jO4nHgWr+YmH7GcYrPaAh5srLvtA6hyrEaXC004ydPyKB1hlvJAxQH3m Lz1wPNqHIQ9g0RP29HpIgAnB7sGpyatQipiC5Skyk4nZHkFPZW+ykoXp1GFPJyl6SXUEfD6XzidN 2LyY03Grw3HTOv+aeviaAoi5KMIfpETe5RvOhvRpYt8m6voXzi2cK61ucIKH0KVuTkgFFgn4IOqF gE/HL8eYWlWtxqadOrRnakSm0WrlOoHGA/iZL2Gr3KjXEiKYjAro/ZQ851vn9uX68lytWddEMq6d NdubUFBcNNfbmXWtlt95zWsMzC8VhLL55Uby6y92oJn5S/36nciALpxDKjr3suJcoUJVUIWRnaay UTGqRkQtWB0hNZu0Y+qn1DhbDcDmNwUCm68FtOC7UoSSCWBYhZj7fEggE5RRJOQKotArjAsXBZkg mkA0jZsumiZMXHRAqI5XyVfFlrVcARLQ6grpQEnUIk2okYKOEh0h9o2OEdWRXua4+aS13NzEBOpy ATMBDrghxUwaJ7KInSq5eBY7PfM/8BeEYBrjRObkZq90Xqun+ig0Z07O2tnksa/KQ406Rau6UVSM oKPoJLqEOKQZEjUgasY1F2mcx2kYpxmUfTlVf1QlihyRc7g5LIeIfEKOtXJQyOVKnnBMHeYFfMXM IDBNFOsBCwPzmDaiaoexS5+U1dZJ2fnz+Ivz+MHJfn7n5HO4VmIsqoenJL4WvSgncoJUUvs0UFWp NLzyhga2a0DRvIMHnldyzUCUMXXMVCFtvUlqnu3x6IuLvV6mnB0mR+z7NDf72kGSd+1X5DC/87Gp su9OmR5jbT/E4mPq4zpYfKygzbL4WE3j4zg4Gjcdh+OcQ8g57rzonHBy407QOmHICc6Z+DglMThu AWQRLLmWCctVC6+wJCGL2oT0YV6grFHZBG4fH8NMKOy8OVD26Yws9venBmvbyrt2L7K+qMutD0px 8hk6zEB2zl2Ul1DUfqB20oufr+qqcnpq7144eR//1tS9jvlFWXJJniumPyK/oDF/FrU+NYMCDCbA 2gxYS8AetNkUwWPUH1dmowU2Axic4SSbfYd9xH7JztntSYJd0asYUlxUTCh4Nm9bpOw4BVAry3Y2 bNnQNLOnRh+CZH10vm95NyVSYGxX7Za9DQ8uyC/nWF8T5NG9DTAki92LWnZqX1KWdR5q3XG6Jy99 Xn1nX8nKhzpFzbn4vu5FnWIyTmt6bFN51/q4intWFy8//PbdG37wrTpfQt6KLZXxjet8nTFby/Zv +mlf89A89D0xb9C/z48H4/bFYTyLBv4qPonHrkRqcvgUUwrOyEgNih5lT9GOopEiUlQxZFwgrVSj KSVEQ58FNhpZ51aMV+BjFVAhjXGqM+SomWUurlEqk3zNRvAaR4zYaNSGkwSPL4zM0hhL4mCBC52K IC1gCnFJG215eWzPh4qFrl9qmvm0TCoNHICC2KDLs6SNLFNs08DE9hI8OMsZT7LyyrEf5PHEZDTD E98/XnP/0yv+K6VkRWl+bXmm7Meqos4jG9/6VU6pNjU+rSLTV+1JJDJr1arNzuU763L+df7WxoJm 43Njd+1bnIq50orVJcnarAqfTrxrseuVU1OecA1HehWK5Lk1hfm1pfYHAmsGCho40OU1Vte3MLnu mlrBWblFKBOVoEOi0F00WIS7cwZz8J70sXSczjSjQa4KVdsabLha3iDHe8gY1UMMHqBwtEA8lgVZ ZUNzUrRBJAhUU14VOIUQKYNAGfSWjZZhWxlMl8F42UQZTnGH0wSzVpusKAzzUZlKO0vM2PT1Scta 2kCTVg5zg2dcnLTMLGcquc0Wk3xmUcV2NznrrKZHewee9/BAP9Km0/PUnyOcRVzaHuh9tGnWq4ml a+4oW7fEk1m9PrhwbWkiTtt+cayuvg3bc0utUw28LCtUmqMk6b6SpPxqryn88Ns72x5bX5TWcuKB /qNrXCUbjzK5cVTHLqW6TI6MoBd/1YG34D2YdBi2GPYYSDcMwj4g3cZB4z4j6ZfdL8PtMriHP8Dj dTxsQ8MIF6MG1I3IZrKb4EKynHQQ0shBiGNb5QvkYMAEjMgky5AVyIhMBh/KPpPhJD6HL+GJkoc/ 85/zWMZrNFwSyqEjR5QI/ow+p3wJcrs8V07sNNqQm00kgxQQIiPwIfmMjtpJ7jyHubA5Ysa55hbz qHncfNXMe2kMgpuNBsMW6t7dUPZNxV5fdGy8TT46QGxrdhNLRJ0BmpDSxfRfbJP9po+DOJjDr2Re QTxV9Q5u5HuT9/7L6zjwe1w4+bxgNWsBxydYtWewFh6bauN3frGDw7OWVszmeU/l0llTc6L+Nd9F ZaxDqehdsfyEBoaN3zU+YySHrLDZutuKn0fwOIJ70AGE70CNaB0i5BhAH9wHB4HgtQAigA8gA4AI Z6d7xRW66l5hSBgVSK3QJuD51LY7BZ9Ao3/Bom9UqxHS5epEXYtuVHdMJ9OJ9lH7MTux3GQcBdzs tTRbeiwjFs5iQYnN1+XFjFNTdJeUemBUZFRN6It11GmSnDGXFLg1xwI4yXt3wIznbpKsAWFzmTnw dBofmDo4VX0eH7773L3zs2rvWwmj/3DX3n3nVCm8vfTuRRm4evJlfufcrrHVFfetXyxMfo98JK4O 2Cb/kR1aE9WXtdTWZvFjKANlo31i5eb03el4s3O3EzcmrUvCjSZojN8WPxxPGjXbNMMaUiK7Q4aV 1A5HssezcfZYZqYhOZiCgshgN4iGUUPEwBuYokzIdIcMBkezakSFVVmPZd6ZDMmJzQ6O2Yom7+Tr Tbpi8Lpo0CRti2+STAViRy+sx8AWs0zuLJdH1aIsqhVTMRT4TFxWRvmSpUsCWXASZ5UvDi8qy8hZ tKHiwPH4s+qKwRe29Z3eLk6O/IxTLFhfV1FWUrlsblVXOFBcHKwvLV0VsB/YFlf7nd55RZ2Hvnz8 zTejfpAwtQJ+QG2+HM0RbVwAwRW2Eft3EYcxHscX8QQ1tdynPIJPUbLkX1Ajt2nyberwSntSOmeB Qyf8+c9weGrFTln/zn/sp9WLqc19iVuI5qJXxToWNeAe0w7TiIncZYaMQshJBlM+SMda6tTkVJxe 7XSiEPUhcg141HCMypEYiofU1SrRkkql7Q4tsTZbsd0K1pbi8WI8VAzF0o5bVk4oUAxCMRjcfHbY jtJhNP0q1cfpdiE+zLeoe9V4SA1qNdOibF0Kl2MvuhqBKU66aDddt07XDySaboyFpFapMp2bCtKx EFOsHlKQX8jOW+QeatFlTKkmpPLkpdLe73evPty3SH80YXSopDWY5Vm6OThvqFP8zS9e+E3Kvyhz K+s82wZci9bPczXWLSxygOvOrTUuq9h9p21FjZA1L3dOIMdm0OVUdSw6dOTe/cacYqf2joXu4iyr oLY4vfPro3N2ObXxVmrj41EaGhBLB+377HggZVcK3mLeY8aD+n16PBb3VBzm4oxxWK1MVmI1n8xj DhsxllNLNKoFbfpQbjqkS8ae2vRL6WBZYFOAwhhWCamxbX7Jl2lybZqxNDeiHxAkmRQIjtuali/+ tun09nnwp3tf3lz0atbC9ZVVPYuz3Yu6y6t6F+fg1KkPpv5SeeA3Izg3eODdA/ceX5OVvfb49nuf XDMra81TbD4O00e5tM/aI+YTdix2ceZk7CriFGiCv8rjSzxE+HEeH+Whlx/isZa38fgqDxTOs24l s91VHqajxeP8RX6CpyhACbGzNHbKeWOflbmkfZej2xfDZ/i3vsiX5Dy1glyhc3gOqkK/F0Pb5gzP wVvke+S4vRzq4trjcGPJuhKcSQoJztRDtgOUCZaEwYR9CZzMarZuse6xckpvUMxLy42HHfGX4nH8 giFZUOKuJiElxPNlC7RJoEqyLxAX4HcWAFpgXzC6ILKAC19aAOMLYMkCGFpwbAHWLvAuwBcXXGUp UGRr0+aGbYJ2XthkVoYLZJApAxlbmDSevSy5X3kBtqG+KRbKsi2qGzM8T4pD0E2RLNw0u/3gvO6j YjbBffQ910edLp1RZvjKQOP0ptEOMf5F/fY2f1swExtL63pDnd+m4VnrkZ7+Ex5M3Qn8LHMtLrnn hDsLq9bOs9nENZWFnUvzplZkLlhTlrSwJm3h3cufz15Y4qwafvuB+y4+vKi71VI+dxZRusqqs679 63/+iby+6Xsdubmd3+vdfHRNjqftiega2MXWAJ0jNuRDB0Vl95zBOXjQCTbmcCVSh2tP6lgqrk5u SMbVXAOH98AYYLjZG7ODvWAohzcE2WlErv6qnlPoIwUQKIDegtECbCuA6QIYL5gowJaMsFXQozgT 7w3j/wNvjLljIDiYL8bslbOcSGfJMrlM7iunYtaTr62Yqb7t3/dReRHqhVF5nWFOGZf35La3f/pq SnlL1YIN1ZnMDZvfItpw2uQvGtYmFeWmcVRGoSzu8lRD6lyTxdzVOPXR1B97j3XmejqeunvgibUu T8f3Jf3+Kn3cQ/0DgraJQdKoRcBuxPoFZEcXEWlBvVSeUkgZRhHEy9FJdgR4jI/whJ0EinxYyozT Vaew86P0RdgcfqHIH5Les3Ol90saIQSEGfkAsH2PTX3SCSGdglRC0aX16nnmv8zsCfLtlKc4ZEFt YvBEImxPhOcSIDnBlVCasD2BOyFAsuASSoXtArddC48SGMSAGkUvdb6Sh8RkMDYimSATZUQuMzTL ibFZpo9pLdpeEx0QKbC8Mc2NmAYTzG3gzHr5DReCb1939suHJ/8O734fDK/3jC899KvtU3+Hkp5X hxfjdyJT//ViE7+z5sTUtTMjv7zP/+Wp0EPvMZlaaSfK+F/Qdfc9UU1UBpVPVaHiNCo2xdYp4kJJ WgHiBYsAQR5h0GOb1WtlNmyHdcR61CrXWgM0edJ63nrJesUqL22mKRwtI1ZxeVvIKma5Q3ZrrrXF Sk5KSES0gpZSwYYwHT4Stsi07Pgs4GNLPqrOXEzabL1TWB57sXPZ1U1A3SdngW9mTccuCVjBZ4Lu M488Yi7tqLFXJelm62f5rOrfkJevVZOX799W2r7QJZPtI7w5uyyr9f6o3SFXYmtuu7iiLq09DTfm rcvD0tGQtJGk5CzcILeP42Rys5zpSs4QFHPQiP6KHusLhuwLbFRZfW2BmfRI7Q0rBJQRNT2SDgtI C4yaoJm4cWYzt0k6YcY6an2YgvJA/s13NWDm/kZskZECaR3BQ9uP5+FYqPMcXWp48r9fX1p33CUt ree7GsEIibiwcY3K5c1Rwve/NGSFylxKVUZuQRL0Smur86m7WXgzs7Z4aiOucSXIht8RS79N4NsY HhVgDMGDwuMCfhA9jvA267D1u1bSbYXHUyFVoMvkoAH2GKDPAMsNHQZ8UA9Ez7aO02mRgBIV9E+X ahMetcEeGzTYIGgDiw1kNlDY9DoJUSdzgMyR6Sh0BB0dji2OPY6nHC85Xnd86PjMEfcGe2IHMzPT v/9z6IIDWCHedWsV2T+tL3OYaVHQsZwWsYIoWH34EwdMOOA1x7sOfMYBxxxwn+OgAw84oMUB8x1L HTjfAXYHYIfegT9wfOLAEupxxxkHljDbHAMOLCGmO/Id+JvxljOaICGaGU3olFB/xxgACXeMMQC3 R57BFZ+i2JTVCOv+IQducfQ6cKWj1oHtjlwH5hxGB55wXHXgC473HPib8ebSzsfQIIYEMRSIEfpa OUYORiDs4MKOIceoY9zBeR2AHIIDy+lII3uqThsX5iWvOnpEJB2Fb2q+/bZzdDe6+dYDq9udad1a LGVdkmq4cVbFTsZpgJrojR1LNcUs1/UrYA7mCWRmFTDPoDAANx+Yr8pcsubuxWkl1F3XLdnr000t G/9AZbMlYpJgTVW995M1j/eUcvIHCNmy08UVTD6T3NgYUqrnhZem4nVR/44jVI+o0Zdi7T0Ytilg ixyWKzuUe5RjSk46/WBR/yAiA6pdqkMqUqkCUKnUOQogCqUwwDbskFqoVQ+oD6kJe5xRv6f+QP2J WparBqxmU7+b2nm1nASjJ/RXOU7B2TQBDWaPZs20htNqoskdGr5YIy5bHmrRDGmOSVu+/CV2ySea 56K3fcRYIbv1o5RjkKs4hZZHnCl6MyuQUExHjgqeHUFFfQIvk+mmIh+NN4p8zX26aIwbjWqBfh0g l3Y4WfRPcqcO7jpzBt7/zVQ1/Ar+tmFqB//WtVasmfJOHpbsZev0R/y/0TjVgLLQevGOlRmQlAHK DFjqABOl5IBaGlElw8oEsCRAhw664gCtFLVGMGYP2bOHsnHqypOq8ypsV4FWZaNBqaVZyzmbecOM p990O6MZtZsy7pabfzHzeZMDw/9b85mpa08+P/XF8/WrTgN/4mngT6362bwdP95+7092BObteHX7 rvPbS/EbT059PN514+pfx4+nPvv+jouHwtHrgY/WLX/0vdj+98PUN1Ci7nMIM88iMYSxTMGGtUQe F1Io1MDfsP50yLnmKwBaCEAP7ICjcBLegUugUICYkBoC4BH1D/hbDwlv3hz3uubkgrQv7qRP6CT6 a387T/7M/Wnykycm/5Xf+Rj1nGbOMM3IgTzoiLj+SOKzifjbdthth2/Phs2zd8/G29KH07+bTni1 SZ2hJjJsxpmYPKuHo3q4S79dv19P9CmaxgRRowslJGRTX8aW5k3DJ9MgLXcoJftGh/SzmnekQEpK djLlO3vGr5E29Yuj+yaxYJWxfllXTEcpGrPefNZ5fb8klUDswLMcG27aOvlL7UM/7pq8gNHms0MV jor2irr76z1Tf3vs0NR5mFc7ELLXzFm1Mzz1GPRXb2/IgwfvOtzs5ndm1e5sLO2q82tVJY1b8fy+ NVPzHf7lkz+pWF2WMsUllrXRubqQnMXNMd+uQSzR2dW6EMceRpE9LGMaOUvI48ZUh4cQaKlDgRUo 4bDmaPLJZKxKeEyDkOaEzEhozP5BnleQLptdZmdsly/nuWjWxU7YoCAam4DJZ3LclIbDKoPVuG32 nPrJj1XGVOPg7LwGcvZg/vKF8+3zds372Y1U7D6gzElj6VL82jmUMz3xgkIdskvnsjSRVhqknHiC v/d+7sUveSHb2+Dd5yUyLzzlfcn7O++HXm6fF7Z4ocELMq/ZG/QSudcSF3xdAzKNWVOo+VDzGbsj +KUf3vT/3v9nP3nFD4/6Yb8fuv2DfrzSD9V+cPlL/fhzP/zVD7/3wy/98OoNJKAo2f5iP072g9IP v/ir/0s/7vbv8z/qP+d/08/T4kU3MKJEWFP4ekPf8gNtYaF/pf8uP2fzA8ea+Ksfn/Sf92NavsN/ S7HaD9+dZmTEabjkB0rmJCNzxI93MGbu8uMlfij1Q7qESlu7jnSE0Rrx4zY/LPRDgJEFrd/mx1Gk 7f79/mf9r/i5Hql+tKl1r/gZM0RqA6QWgNKnXfmSVbrC+vFLxiu0+Q+xLjJWCe3CJ6zCs/73/YRW ussP+VIlrR+KX6HAL/3kmB8GWJVo30i0OdYWLTvOkBl4u5+jhC76Abf4R/3H/ON+jrae6wevH5Bo 8IMirSA8S4hd8fRG73hKlzxZ/Bc1pM3XL6F97eC477bQr9vn68XNX73F8nXLvil6ehaz4gwg7SAW M0//Gy6ZUkf5NgdsBBm9d84tXjXP+cKNa6eJRQtbxe0jKSSxLNwmLt16Z/rpGaxvuoi65q4b11Gj eK7ae5dNPvgVfXDXOSTQVUaXv3Q2oqEJ82HNWKLyMBqTMQWvpRDZkBq0apsaK9TSbmoihRkCiZA4 oyASeV5/Qp14i4Jo8rmYishzTV4WJi9LGiIafkMBDX74m9K4WWVgemFO/WtTLyqNVuN2mvwZd7Vg RjE8XHBDRbCdp+mPcLG0H+UTkwbRPhrQJVIdno0BCwgL2I6HMCddmzvDsA0sAvYWvd1UJJ1zmdjW +pEnprqN/MQXdkZvx1Q9foLSM6P54uwHNPCAEuqNUI9BlxivC/HsIcgEQTYkwzL1xyw0t9O2hWQe SZSbLr/VVJQn3WikH8PMDs1MALQjp/FA6/Or99W7XPX7Vj/feqAxBxv3T/3lD93d//7Xqf37pz6i qT/8ZfKA1Lc4yotL4iUkavZqYK8SVhhhBeXl7PT/eoGxQ99nJI5Y5CHYZCOUK/TxiBrUAmKeK+No 8maOYGbXY2YGYtdtWBIOTDKW/vARY+mv/85Ymtof3Y9umv6I+wf1dQLoj+LGsXKoLIenSmFPIeya A4dnwQkHqB3JDpfjiINrsJ6w4v062C+HMQzSDueuEmgphG4TbNFBTmM2s7MRAxjmDSkbFaJgoN5D fiOyCTbRRuQ2g2Awh+427DU8YiClBshnffRS0Nb8B/IP55OSfDDk897mnhxoyIGF0m3EnHQuvrlF CUuVUEkdUeZBsatol6VnE9tYlvzo6P2FmX232MayZKLh5nUdNdf29Ky5qeTG/jJfELsAH91hjnpa Cak894+q0ffHpj6f+u+zzsWXrD3YUfdQR3Gg74mW0q0bWoKzakYv9N3/o6FFCT+OL1i+fdma3TXO wPqHwvN2bum80wW7G8Y2+M8+nzG3cV66tax5ftXyokyzxuYqqbkr2DayKid76WDY4QsXpjjLaryB msJ0vZYW1vZJY5KAEPkLjXPV+Hdi6BCGPRgeVDyuwIMKuE92UIa3yEAKdgcRzFVtVeEUFWzjwMAB SYS7YS88AlyC/AH5YTmRKVQg5zilUuCZtEt5Ja8k1JvPVherMac20hbUH6o/U5MLamA3UF5Sk11q kKkz1UF1h3qPmsFepxhKBfPzX0y0hdTsnPWqqFYSUJJiglVEc3Z6SBy49OfQFg20aWC5Bio1UKiB dA2YNcBpgBlm/K4GxjVwWgO7NIc0xzXknyG/8ZkGPtDA7zRwQQMvaeA4M+9BzXLNHs2Y5inN65rf UUOvHKMJLN0UeeXl8dAuRqhDs0VDKLFM6gpgSugwSzDgU5qXKDZjQvkhax62sEZrNW0acnPDX293 i9QmaYs6GJkSF3znDW6ivCge1fxeg2/bl99JrZILjADjJqjh5nZI/Ei+isR/oX9+qFgDaRqQfuqA P2FyYhdhyBkNDGlGaSBEBjTQooFadkkG8jVg14BUNU2fGDqmoXEvrRfW9GoYtozGSpwcCFbItAhH b3zrE4pp4MMub7pusorN0TD169e+vw5yNd3OSl7HctHF10eDXebsSwZVCne93qIi2nJe7Kc+zTfX dCjBqWSxGAvHHFP/PvX+a7Bz6uE3IB7i3px6GPbAj6cqsRvHT62EJyc/mXw3qqvOTn0BO9H71LYt Poe46YmXqalSUVsmZ9IwK6mXOxQ3GofFuHBcJI6Mxh2Lw3GsKD4zOxQnaoRQnPxpdESNvJMfgFfa NfW5JOuVYbphsWDnjJV6/+mCFVHT9L60Dz79q6kVsTvpCeATD8sT44SQfBb1XQkXNMXFIWQSTHaT aOLkJlOiZdQCgej9HPy+RXz3t6GLlgkLHmE3LsMWrLXYpDPbaQs/ajkmXeDhljB0OBawnLSct7xj 4a5YIGIZt1y0kIBlCcUmdguMSEWE4vXQ4ousjRELZme/R2k1Ss3Cely7ZGnokgUY5YiFeC2sPqvj t4gFRaFeyxDlLmLhGBN42gIW0ZkZovxSBmiOFbNWJyy8zQJmrRBWJs/cmL8cPczZ5KLD7JKmg2vm 6GNmvkgXclmC3UpZ3URjcoFdqKcuE7tTr4tdnSiIHfHpfPvOmAqbQmnzUjTpmsw5KarodfvG8nWL Z3P8fswZXRUe7kk2/kqE+EXUtxHQX8UX74hvjF8XT6q4Oq6dIwe0UKJt1K7TbtNy9xMoIOwnVJsJ N4B2IaxEcABgO4AMIAlyoASIEuDP8DnQFZKBChCRIfgQfUZ9DfYrliRtjrZES4hCC/9L+w8t1uYL tdTxEKgHIkCu0CKMCuPCVYEXvnaVAZ/HGNv1YT3O1bfoR/Xj+qt63qsHLSaD1HwBu3DXFPDduL/g lbaffOx58w2GW3YF2O8n4Ma9ZPCR+Ncnf/om7NGmxsVr4uLjrDrY9Sa/85p9doMzOysj21mfSybY PoaXxtFzqbxU0l3g8He18KgM9sqA/TgBbxEg0QzsFHPMTMy8GGcK8StVd6m2q4hKAT0JMhuGXjyB MfO6cnGYJnkFRly/wmwGtUwGiWw/XB+9kCEdPvjYTniT1+VrinUASbvhjgLw6WioGE/k7Osgm56Z 7MK7X319ahQLRpNi6jBvMBpl8DEEpn4KgQPkpWt3PkS28tb0jLjJjxRJyUly2pcu6qdYqJ+SjorQ STH3gAm2mYfNuEHeLceNZB3ZRkgtbsO41tnmHHCS2rS2tIE0UpBalYp350Ees1mzVZrQriTISCpI qkranMSZk8DUYzSijaI342gGHs2AjJIhr3WjoLKrsHQNMDE1M6Sy5my22/MT+y2mR03YpJXn9/MW aQ+xSYoG8qS7Bbf+xo6pzOjWHrrudqR5gO3qsEOpG9fRTNHs1451LaX9z/RsP7vNX3XfK1tC93Yu TnguZXvNHXfXzp5zur/lsR7/y+mhdcE5bTW+WQvXzZ/XGcqEt9ed2rFg9SmA4z+GlJ+0pFZsDNtW 1gT3v3tgZXP55h/0Vm9ZNts6b92dix9oK5ldt42tpyemP+Kz6fywoL2ivyGhOwE3kG6CG3A3xlUC VKnA1CiKdDof05NcOp2v6smI/qj+pJ7opVMhMXk8+WLyRDKXzISVTh1XReMSvpnv4ckIf5TH70R/ 3ibyRM4bZETTjKQdMOlGMDsDjt3WZD8InTlv4KWffvpu+WFoPMbvD1x8fNX54o79y5Ye3Bj4SdOx fzOW3//mMNl5beSu76x2uVuO9JC2aw8/+M7e+bRfK+EiXoJ7qZ52iEaERdxLYy2EXjkK7wD2ArW0 XunGKPstnaHAYVoJn8DFY8ei8QcCPpU/t/pYs7bsU2SL/v8pb9Q9+/LM//HBrIDMybP/V0fBzvJQ 1DYhefnUYlRx/f8JAXTrpxB/hCr5N1AX149242fQXvpeQb97cTGy0S+7vCWHN9A+/o3pSQp/ml+O npY9Q99vxL40T+EPUbwVsbq7KIxjZTRdS2kItKyYppdTOsPszXAo/FWGQ99WCUaVKP0Oy4pRK/ef UbqUn4W0rb3szXih7x30G0fLmihuAoWdhTemf0XzSkrDS79dlOYTFGcl7ZsbjUM+3Acf4xb8Gn6N E7jVNJ56Ti4oehX/UFYq71N+pFqjjlc/E7cq7gvNPZqn4mvjL2gV2t8J64WXdGbdqD7JcMa42HjB FG86bvoi4bnEuMT8xG2JFywPJSclN6YkpZy2JlpfS/Wk3hmTLPvtFEHR02mB6rlG6jE/wY9TGCtN geXX5S9eHwtAWiTG0hjJ0ZJYmqAkNIPPUZzeWJqnfsaOWFqG4tH+WFqOtqFHY2kFMoIhllaieMiK pdWUh4Lr/yOSB2piaQ3aATM045ELphjHHLVraAhnx9KAUvGJWBqjePxGLE1QPv5tLM2hVKKMpXmU SLJiaRlKIYFYWo4+IStjaQWaxS2JpZUohdsaS6tREfftWDoOreJ+GUtr0BQ/QzMeLZdlVHZ3dg90 b2tvs7e1DrTaT9jzcnPn2uf1r23f2NbeZ6/o6evt6Wsd6O7Z6LHPW7/e3tfd2TXQb+9r72/v29Le 5rmze017tNy+rHVj/9L2zs3rW/uu159t/wrCV7LL2/v6WXqOJzfvRtFXELv77a32gb7WtvYNrX13 2Xs67Espv6HWAbe9euNaD2Wms7t/oL2PArs32us8yzz2cOtA+8YBe+vGNnvt9YpLOjq617ZLwLXt fQOtFLlnoItyuW5zX3d/W/da1lq/53adXzbQvqXdvqh1YKC9v2dj18BAb4nXu3XrVk9rDHktxfWs 7dng/aaygcHe9rb2/u7OjbTbnq6BDevr+ttZfwa6aB9v6nFHD2W+v6djYGtrXzvrf//mNeva1w7Y B3oobrt9Pe3HRlq1tbOvvX0D6+lmieOtXd1ru+yDPZvtrWvXtvcOUIkw9H9G2fNNzK6/XkniFFWi btRJvwP0uw21ozZkp99Wmm+lqRP0m4dy6d9cmpqH+tFairORYrSjPgqpQD303Ss9WyUaPbTUI+Gu p392Cmf0u2hZv5Rrp29Wd4vUlgfdScvXSJAb9e1oGc1tpJhLaUkn2kwptVKMr7c/m36/mcI3ly6X Svqvw+dQjnJpj29X65spdkv9YzIbkEoYhxskru+isB7UQZ9LY/INSTXdNFVN666V5NUn9ZRRGZBo RzG7Jdp1FGOZhBWWajIJDEitbZSwam/T4hLaYgetz+R1A3OtRJuNbZRyD013xWS5jsq5T+KgTao3 07d+2vL/6cgvk7jbIrW5SIIPSCPOyrqkXC8qoQbAi7ZKfx6KcyvltTG6Him1gWL+39YbQIM03y6V 90uzcGNstD0SzQ10VtVJs3FmfJgsouN4+zHukN5M8v1SjQHKSas0VjPj309luIZKsl2SH6PYE6PL cNbHxmNjrNVWyhOrzcZtZkw33yTjrRI/a+nTTvvSQ8tYnbUSjV5Jsm03Uf9/y7Pn/1qy62/T0g2Z SjY66ntloTF0m88ppfgTkLP/lUF6HgVOfAjGJ+HkJKBJUC35EuxfwqfhWbaPg7Nsfw/m2K4GXbbm KzuuYO2VJVear4xcOXmFV//pg1Tbf/4xaNP+EcQ/Bs22/5gI2t6ZuDRxZYKIE77C4EQw0fbv/kt1 /8NP6i4BqfsDmbZpf2v7LZYe4i8Sk4PvvAavjpfZfhrOtP34J7Ns0+cgfLb37NBZIl0QOavPC9pe Dry85OWel3e8fPTlky/Le08fOx05TbSnYfRFiLwI2hdBoX0h8MKVF8hQZDSCI5HxyMUI8Z4MnMTH fhj5IR7/4cUfYu9zgefw0Wdh/JmLz+AlJ0ZOYO+JnhPnT0yf4B47km4LH4GeMTg/BmNBq+07hxJs Ow6NHJo+RHIfFh/GQw9D78jQCB4dgfGRiyN4yYHmAz0HyJ7gtO3obth1/xzbQH/A1k970LOxzLYx WGBLgsQ6iy+xTu4jdTLa5xZa1ky/q4JzbCsbQ7ZG+jbk6et4KhMuj9T1ENCSAMFXaqZrsFhTUBQU azJmBd8Ra8NQHbTbQpTmAvo9GYRLwStBPBQEc56pTgfaOiFPW0eD8DpAYLNpA9pm7Q4tp9V6tUu0 PdoR7SXttFYeoLArWtKDYMgMPJyF0VO1y1yuhWfl00sXRuThlRHYG8lYxp5iTWNEtjeC6hpX1tPI 6KGG3Q8+iOZbF0byltVHWqwNCyNtNCGyxBBNCNZTZjS/YaB/YLP0k0KIJtCAy9Xfz1Lsrh2K/twQ pBS4+mkxResf6KeZgc2o39U/AP391DoNUHg/rKbp/n4G7gdag377XVHylAIlvJoSoI+BKOn+forf T+v3J66m8/r/AXyqonEKZW5kc3RyZWFtCmVuZG9iagoKMTQgMCBvYmoKMTQ1MTUKZW5kb2JqCgox NSAwIG9iago8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL0NBQUFBQStMaWJlcmF0aW9u U2FucwovRmxhZ3MgNAovRm9udEJCb3hbLTIwMyAtMzAzIDEwNDkgOTEwXS9JdGFsaWNBbmdsZSAw Ci9Bc2NlbnQgOTA1Ci9EZXNjZW50IC0yMTEKL0NhcEhlaWdodCA5MTAKL1N0ZW1WIDgwCi9Gb250 RmlsZTIgMTMgMCBSPj4KZW5kb2JqCgoxNiAwIG9iago8PC9MZW5ndGggNDYwL0ZpbHRlci9GbGF0 ZURlY29kZT4+CnN0cmVhbQp4nF2TzY7aMBRG93kKL6eLUWI7cQYJRWJgkFj0R2X6ACExTKTBiUxY 8Pb1d7+0lbogOr6+1z421/n2sDuEYc5/xLE7+lmdh9BHfxvvsfPq5C9DyLRR/dDNy0i+3bWdsjzV Hh+32V8P4Tyu11n+M83d5vhQT5t+PPkvWf499j4O4aKefm2PaXy8T9Onv/owqyJrGtX7c1rnazt9 a68+l6rnQ5+mh/nxnEr+Jbw/Jq+MjDVVurH3t6ntfGzDxWfromjUer9vMh/6/+Yqy5LTuftoY0rV KbUoStskNsJ1BbZkAy6FncQr8hvYMacE18KmAL8w7sAr5q/AG8Zr8Cv33YK3wpXU7hjfgd/Istee /JJYF2T4aPo7idPf4Sya/k6D6V9jfU3/UuL0r3BGTX+7B9O/goOmfy1r0t9JDv0d/DX9Hc6l6e9k zcUfZ9eLP+7K0N/hfsziL/Hl/pFvFv9XMP1L7GsWf6mlf4m9DPxNoeFj6O/gb1aMC9PfyDr0N7g3 Q38j+9K/wnkN/WvJob/B+nbx34DpX8HH0t/iLJb+VuL0r/B/WfqnbdCcSxeiTfGO/rS/6u4xptaX xyY9j24fgv/7HqdxQpX8fgM/Ced5CmVuZHN0cmVhbQplbmRvYmoKCjE3IDAgb2JqCjw8L1R5cGUv Rm9udC9TdWJ0eXBlL1RydWVUeXBlL0Jhc2VGb250L0NBQUFBQStMaWJlcmF0aW9uU2FucwovRmly c3RDaGFyIDAKL0xhc3RDaGFyIDUzCi9XaWR0aHNbMzY1IDcyMiA1NTYgMzMzIDU1NiA1NTYgMjc3 IDI3NyA1MDAgMjIyIDcyMiA1NTYgNjY2IDgzMyA3MjIgNzIyCjY2NiA1NTYgNTAwIDU1NiA1NTYg NjY2IDcyMiA1NTYgMjc3IDUwMCA1NTYgMjIyIDU1NiA1NTYgMjc3IDcyMgoyNzcgNTU2IDUwMCA1 MDAgNzc3IDYxMCA2NjYgMzMzIDgzMyAzMzMgMjc3IDMzMyAzMzMgNjY2IDUwMCAyNzcKMjIyIDY2 NiA1NTYgNTU2IDcyMiAzMzMgXQovRm9udERlc2NyaXB0b3IgMTUgMCBSCi9Ub1VuaWNvZGUgMTYg MCBSCj4+CmVuZG9iagoKMTggMCBvYmoKPDwvTGVuZ3RoIDE5IDAgUi9GaWx0ZXIvRmxhdGVEZWNv ZGUvTGVuZ3RoMSAxMzA0MD4+CnN0cmVhbQp4nOV6a3gT17Xo3ntm9JZmZMuy8UsjS37KtmyJl41t jS1bCARYfmEb8EPYMjbgB5YgIY9iEgKJCSEkxEmTtNB3SU+KDGnr9J4G2ub2dZJCe5ue09tzi09f p/0ulHw9SU7bBPuuPZIfEJJ7zvnuvzuaPbP22muvvfZaa6+99nyKju8PIx2aQAyS+oZDY23VjX6E 0BsI4aS+A1GRb/3TKoBnESJFA2O7hgvcv/wTQqwOISW3a+/BgWfe7KlGSGtCKP2BwXCo/72/HHEg lPsk8Fg9CIgfzT2rhPoPoG4fHI7ee10ZaIf6daj37h3tC+k2PB9AKG8T1F3DoXvH6pVvsVCfgLo4 EhoO85+rH4P6WYRU+rHRSHQKW+YQKo3R9rHx8NiM51wU6ldBJhFwGH70AvmwgtYJw3IKpUqt0er0 Bl4wJiWbUsyp6P+bi3uD+xV6kDuMUtBB+XnbxVYiE7oHoXlqj2XPufb/t1Ko4q9X0LfQeXQW/RxN o0+hL6MpdAw9ij4BmL9bkheL6BL6LvoKVP4evYBOfMS8DuMk9CpwG0cX0Dl0Gn0SfPij6HajU+ir MPp2tAlFUT/+BT4MuBkY9Rk0icPoPazCOdiNbqA/wshfAJl+ia6gHwJcgRy388P/gn+IngLZ98Dz G/B8gWLJn9EkeQqNkJ8zh2GMx2BG3YD+R7nL5/F2qD0EI9OrG4XR6B1CPgqz/AK6b2kGc7/jDs// G9J/8CX0sNw6hYbQvmU9Pkvq6IuxwNwR+pqMO7zQqPQzu8nXCbn1NFROoV1QQvgXIOUJphZ9Gbfg Bvws+g06iB4nu0HSI+hpVM8ZEZIaOjvaWluam4KNWzZvCmzc4F/va6j31tVKnprqqnWVFWvXrF5V XuYsLSkuyM/LtdtyrJY0k1HgDXqtRq1SKjiWIRgVN9h8vWIsrzfG5tn8/hJat4UAEVqG6I2JgPLd ThMTe2Uy8XZKCSgH7qCU4pTSIiUWxCpUVVIsNtjE2Jv1NnEGb2vqAPhEva1TjN2Q4c0yzObJFT1U rFboITakDdaLMdwrNsR8BwYnG3rrgd+0VuO1ecOakmI0rdECqAUoVmAbm8YFNVgGSEFD5TSByESH jTG5DaH+WLCpo6E+w2rtLCneEDPY6uUm5JVZxhTemFJmKQ5R0dFxcbr48uTjMwLa2evQ9dv6Qzs6 YkwI+k4yDZOTx2JGR6zQVh8rvO+3aTDzcKzYVt8Qc1CugebFcQJLQ+IYlyvYxMl3EUzHduP67ZhQ AqPIFd5FFPSBeicnfTbRN9k7GZqZn9hpEwXb5LRONznWABpGwQ7oNTP/zeMZMd/jnTGhdxBXJibr aw7Ekpu2d8RIrk8cDAEGbo/NujbDauxcoAl+VDMCRYA6QKdWK5348RkJ7YRKbKKpI14X0c6MC0hy OjpjpJe2XF5oSWmjLRMLLYvde21gzUBLx2SMzd3Qb2sAHR8PxSZ2gj/tpqawCTHDexlW22SSUaxw dsq0Iki1oX9IjHF5oBbotbwDeArtMinIFcN78deNDBggz5gkVtiADeXTYGvoTdwHBtOAgVhSHPM7 4qZv7YhJ9QBIoYSNGqbLnNAj1AsmGqqXzRdz2sZiJlvdoj2pWA1DLR1yl0S3mMkbQ719iV4xZ0M9 HVlsmOytj4tAedmaOl5F7vnZ6ZVixkU3Wok66ymx2Qt+ldcw2dE/ELP0ZvTDShsQOzKsMakTDNxp 6wh3UkcDDRXOwnBWecQY8bZ2BFpsgaZtHWsTgsQbKDs2t+EONraOjDgbcLmYKlcldpAMphMIBUCI PgBsdVXwjClzVVAEULiMpa5aVyV24Ay0QA1ixArFhnB9go7Wb2PKUXfy+he4KWgV+Hj9GdZOa/wq KSbQLCYGhh4qqlT/QhOTC5EAcATYyCiqyzTq82KHLWzrtA2KMSnYQedG1SNrOaEMWecJW7XeVlum LFATskLzQoUqM+ZzZCxXbmy9XF+s+u9o3rDQLE6qbIGWScrclmCIQPINMURdWFprzJBXP13PNl8I FjGsaHk9T05LEl3Lg3TZTto29E/aWjqqZGqIIA9m3EfHSkIBHGitKymGYFY3bcOPNk1L+NGWbR2v CpBmPdracYFg4u2t65y2Q1vHqyLsFTKWUCxF0opIK5RTM1RUMn3GqxJCE3IrKyPket8MRjJOtYDD qG+GxHHCAo4Ajo3jJBlHL7BS2iDoGOJ3g9hP7fNA5+Bkbyf1cWQGjcCNY9hWA9qx1UxjotDFNLZw XUxrq6N4D8V74ngFxSvBM7AZlxTfNyk02N5NK5G3c1QPj36uDbJiJSqdxshZdUHJJt9wTSu4f666 wBAA0TRD0RxFX1AqTB9UXcAU7zZajblWo7WeiHN2/NzcINf2t6/Us2/S5AF5ICMZgjxMiz4hBccU E4onFYyowRqFRqF2gpKJnlOpWVaNm9XdCJsQxgIUJKl5P1L1WDjcyB3iznM3OfY8d40jHKdmezCj 7kFJe4c7HMhzw3MjqcLZtW/8BnY63E6no+qYwyG8fuzyZSN2pzm7kiogYnV1lZe5sVVpZeLFg43s iuwPvtjBZGd/8Ose5uFs7vCLc1XPz6W8SGXOgTzRzG5G+ejUqyhnflbq0PL+FTzWshksycvHzfmB JVGdCDeiM+gaaA4Vpuv0Oj1u1gcMvMnA8wIUg6Qx+w06nMenc0gZFIUUE6835DMopaOTTiDV5XHD HFIr7pA/Lv6+JVR5Ge7qcliTa/CqlXm2HANRMrbkGmaN2wSgu4Zxu8wpJoWSIW9+QqVp7ZH27agV DrzyRaVeq8QvKdRqlsnxtw95Tz+jVx0ij+Q3ZTd2uLsebrr1WaYlJ+AtU3LFFetMzk2rMp+atG/L uxWRkz/knb/O/JHdgpxoQhIfy8fHc/B+Bg+pH1OTvNTVqYTLTMkkGkO6gSg2cDPzl6VVoCuOs/iR iBFkN7Pi2yIriuUlPkHS8H4hN5g+KmJRTBeCXC8X4xiOQ0GtGQzpdnZ5oAjUkDeMAO0DlONGeVkX 6pKvXFcNWZNqYGw5pWTVytVraji3K5ukKksZWRsGnGIy47fWbvOtTn4xs2n0ifZdz4acSrW5oa1v aHhV57HuVdw0k+neWN4w0l6Totbsus9a1bayPHBPa0nN6HPbCrpLRj+/f5PDWNq6f/2Kko2rsgu2 nRoq25136HFYH6Xz19kS0IOEWtApqYstN5XbyxltKtYmZSQ5kpg96+9ff3w9c3/e8TxS4CssNGXW Ktw+nk610vekAs8rMFJghaJtw3qTpEnxm+qaMjK2qEv5sQLsLMAFBbZgqSBVbwkyPCjDfcPlkjXS ZUyqMFY4F3UiK6ULXL4CvB50A6rBVDUGbMvJo0qxLeinhvWQJVfJp/6RTWQHkRXldq1eg5UGLsWU TdxUsawlyyt2tbFYYQtsH9u4ZX+wwNk0fP8Rzx+UnHJ3d3mb1y1cSK7b+8Lezsnucq1qI6fIL+It hrkPvl+wtSWw1ppSXFvc/tCOVWqFUr15E28zrGpdZ3G17K1oOtC6KluHGfuKUtP2dj7f686q2bWx sHjL3lpLe/7cUXOpKdfOMvizMHayuGbLGrHamVXVsQsOImT+zbl2thz0XgiR5B8kbacOb9UOaA9o Gc3M/D9d1Av+ghlYoLu1Br89H7OiSbSLTM76smrcWH2l+lo1g6pxdXVtXvlA+YHyo+VsOaNJParB qRrcrAlodSatVge3zqJ1aj3aS9or2mtahVbKtvu1THkqg4qCWUKSkdfxGm3G6iAyx5fsDVixS4u2 y+1Evm9IBTpBq5U0DqEKcFUOwX+ME+iyxV0Qi3CXka5msB64c5fD0dXF5eTl20x3WcRxIxmYZGo2 xaJ5VoMlSdH9L4gcq9Iqmi/+VaVTc/hLhFOwrD3QtrMq+EBrsVqX0fHAWbsU2RlITc7xdK6u6W+q Mad2mwa7iW1lTdZcJxjNv65IrbKXuMzO+pIU146Hm1z3eJ74h4eqmX/M6/r0vTsbpT5vTu72T0YP tt3/QHxvGJ2/rkDcFFqB3GhcanK4jruIowjbc4/kEnsWPpiGj6fi42bcaR4yk3U8PqDFRzT4iBpv VQ+oyUqCuW2Nzh4ncTpX5Wzjk5xJJEkypfmT8nv0yek9iJWjONWk7OKyipZfmOrEAM5K2MWlT+yp C2s+oSDq66WEeenJX32yEas12U/8ZO7fPjU1+0wA4Md/gg1TD7/x7M50tWrtnhd2Hnlzqm+FWlm5 93luqu35n02UD5U9/+9f7W7/1P98uLS3fOq98z3Pb3z8RxOO9vw9n9mzKnDihw8WbcsDcHU8Jm6d v8FuZCtRPs6TzDuy9maRmuwt2cTJe/hG/hB/kuc46pTPaY1+xGE7aKCeRMkRwq3IwXm6A7qjOmaF DqM8DNvHCvBauIGrHSMWp2sNPG7mA1o9uKYebr1Hi69psUfbKDsnq5X4JL9WW4gY3MwE7Pkmuz0f 7vx5O+btFrvTztilbJvfLiWZ/XY7n86IjJZuO+aUFINen4/4uAu7XE7w4RtGiCOyEzu6xmU3LijI F+z2gg+7sbwdOWCfTZDpwdvvTna7+Rw0eOOFmAN2SnYzBkYJ3kjisUqOWsn4zP9902Irb92/uG2R 7g9evsu2RU6AJrvmr5MJrhhlobNSKydCKpGVZTTrNRaj09ho7DGeN14yKowxy2UL0QrJZp4342al hteYA0qNSanUwK3VHFJiixIrzenJmia9khH0BoOeTw8ySzHAaXQnVQg3XEmgQNioZcVkF2gEpTL7 DsUI6NvHuHhWgiEMOCEaQFx3lpc5lgJ3sm2Ne41b6VbalgXoy7kdZW0hDfeJB9MPDd3r/EH6Dx5k VUVl6SVZrJofaBU3rCAnH/7znx++db+p0lhUqlTK/tkEizYHci4GtX8txl2GrAk25ot5RX55gy5I s/k9HBY4TKgP3Z516fyIYIZZyK4gN4FpuBZzECwHL5pMuXETTro09yfu8N8O0RjRMP+/2XPcG5Az VaOvStKBFUdXkN25uI0P8/t5pqJ4QzEp0uIiyPyYdKaIYQRnTlo2bs4O5KSacnJS4U7lcyw5zpzR nEs5XA4V1J6a5c/J8axbz0kag5+zZKekpaIcp8CglUG9ULAsHNNIDAHZndglHftkW9QUpAo5OTUf dlLh8mU5mYILwfbJLQQVmkKlQhBe9FF5O81PhN9SYkuEZDM+tRRt+2hMJiq1Cje/8q5Kr1Hgv9Nq OHugdadqKQ5Xh5uqU1O75XBb8oAcbge7NaXuUjX+3PvJ+f4qh9rUsZIG5OPxIFy787YgTPV7nc2H fTAXYvBhKSPKHmHJ/eXHy8n9juMOUpSGc1dgRRbWbdBS1a0GhWm1ou9KIS4rxI2FVwqvFTKoEBcW rnIzPsmMzVSlZq1WgYJut6I0mCEogkbzQjoNccEJKhu/4YrnHOOJTEzONuQFDeE4sZ4XE7KkGhzf veR0Ay8qDCOOwY8cXbsjUJE8ucK/Z2qw/9PDFW3PvnnvyGf3rmIUasUZQux1O9aW7Q4FU/G/Z1Zk PvJEVnmt3VPS6S+pGP50+NOYfL2vcvBUewqsiRWTJpuxLuTJztp4aKccj+e/Cvl6FcRjLc6SfHma oxqi1mAVhl2AqJWMSqFVYAKRRMUhTgMQUQIM5gJoE6MyMYwK4WYg2swhE2SjWkEtcN+cfxsYvy0V a5QYTic8HEKIVstpOSaoxrzaonaqGZ1arUd6QX9Wf1U/q+f0eqr56hKXHzFBhqQykt7kZ9QqDYtZ KgXHEwZicYqox4IeIz2ueFuPZ/X4qh5f1uOYHp/V43H56qaOGQ/RbndqBdiAenZ3F9wAQ6t8qIFK asVauI4JjmOO14+lxV+Gy5eF+EN1WZV4grdTnlYG29TYnYzdaky+85O5I9/H1+f+8q1v4+4fzznw Cvz3c/WkmBjmtuMv3Hrn1k/RwlkoBda1DX1e0qky0zKJ2ojVaqykO1w7hFatDjfrAnqDCQIkDZJO PW7Un9Sf0V/Ts3p97gqUlY7as3B6Fm7OCmRmmDIzMzKFDHjSc1FGViZaYdDaWE6fnsHoUkxBTlhY 1KlueVUvHosS2RSqOMZdvuvpyEEdc+kcZLvtpITlJY0PLW0nX1u241zE4isBBW/QEObwsiPQbcck 7o25T1jr1hQoF/RCbsJ6tKKItPGoArer8Xkr7rGOWolVKnD4rVKyGR6wyqxWmxnCAz3hBjRak0ar FaBo6PQ1Kq2ZUTPBTEHgNerEgZDuyx9xHHQ4HPvG6f6KS/HyEyDMLJE7ppIfG53p0sBml3bklc8q dVoN8xKj1sAJ21JdFyjRpmekKZmXONXG8cdqbr3B1Nh8devM5qqaClPN9nVZDMsRmNsMnNl3wP6h RHukeqQQFGRWgS8p8ITirII4FT0KouhhR1nSyF5jCatgoQ9uxt2EMYGHC1DowZ5BbA/HEJzYSSBd drlgn1yaE8xItqGTxuF9YD+YjHWNVclse+e1d+Yys9mj2ezv3s9gf/fiixD/siD+rQQ/pOeAT0oD fa6I62EXU6Tdpt2tZVKYXIZw6y9X4zsTf2etp7axlrGXC+bsbNjmzYHULFNqVpYAJVXKzvGnUjuk ZmehVHOKkFluZ9HqoN5cFETCXTaX2z8wLGX14/FTKo6nqnL6bqP5Pd1EEtsJViqojVLvktX/Yflm 8rzIcAa9mrzMaPSC8t1XWjg9p+DkFF/1obye3bIsfx/sTl+3MpdVO6r8+eyNuc6slcnmpGVbyp15 PQbfRfhd0CmDxqTAVoaGzF4OT3BXOdLIYQvn5M5w57lL3DynoKkCwpAaLPvy0YvwBLqKSA+wolqE 1+JXDZcH1LVv33gidVhIgHDXvrgD0wTCCotu7hr3xt9Wgn0hZ8H/CjGcfn+ySclkCiHFFEsTEpZ7 kUUvYh5sET8Hu+nBNxlyJQzl/cLvFs49DQ9mz5UrHzxz5QpIUTl/nZPgvLIO/XfpsT2V2L4muoaM rcbr3Hh7CT6ag/tzojmkPzOaSdal4XUpOJqM6w2tBlKvalWRg8xjDNnD4NwddnvFdsG5bSx9Ip2k p3OjAr4qYIvgFDzCSYEVhGrFDkhNjH7uiBNvdeINTnyvgAMCdgqoqNeSm2thtT1IUgRhvShQMiiF ft2AvFGg5/f40WbxWE8/Yt2AZDJxqL/toglK/ppshroM3VbzSxk435PlXz+oR6VmMykmlgw+9N1H m4Rp/druye6dLw5X5rSe3NvxQrS+58ybIwe/dmgT/zK/unX/lsGTnQWFrYc72r8wsXnuRybn9kfa c2t2VGdneMIBt7/CnZ22rv2BbUNPdzuKG0dq3WUQFW2edvfq9a7CtLTKziN9P/4V9SFu/jrzczYA un5JKmUrTZX9lczKCty/FoPCW1dhrTXD6rAyjqw9WYQlJkIeWoWRP8Xlt6TQ7dILBk6xpFg0hRtQ 0dki0ls0W/R2EVNUVK3dMKo5ryFOjUfTqGE0Em/ya1JcXEmTXSx6sogUFdkFoYmDPZl+LnHKeu2S FUsPkvsSH5DkjdIhgGKpVvHiiRJyFNvHKhUvUypzvP7BC6Ndj4e9yU/zzoYej7RnsyOvoa+6dn/n qvUHP7Ot+dGBOt3nzPftWtXlK8xrCFVV7O+uwtVth1oLxert69YWeBzmlFK/u6DCkZuc4vL1SM0R vzWzOtSwotEn2CsLC9cUWZOTytaH0cLeogiwm1Et0/MqcszPXtTyfhvdb+e1Bn+FETNSLW6uXbYS EapzlZXj5vKAy21yud0CFLUL/9WFj7rwkOugi7hc3ikvHvLiVi/O8/q8RO3FW71HvV/3/tz7e+97 XoXaW+glf/Xi33vxJ70/9JIDXtzpxau92OS1e4nCi5WZBj5+NhWMJsFoFGihy15YFywScjMNEnaX GTOVSB3MEcx8uYsXagVXPCD80Yt/4cXf8+Kve/EXvfi0Fx/1YhhhpyxPvRe7vNjuxWYvJl78jhf/ 1ot/7sWve/ErXvx5L37Ki4/I9NJ8PxUb+2TJ4j1AtB/d0QWGgMk+5MVRLx5YGAI6iF6c5MWsF7+3 QP+9hSGmFoaID1CfmPptxHFJQPLxZWQrqT6pHED5/Huy/n4m8/2iTDog062WieK8Xpe1sDgeqAAH ZU4wnbfloV6Xhzoii9+60KT14t3ve6VePOvFV2WamEw2IZP1y2Qg76w8fJzDcRnp8GIkKzXe66ys /vvlpjLQtyg3V96U2y95cTz97FlYKfsS1/jS1b0UmKCh52MJlrP4MOHdqD9EL38id7qdibTI6Pbc +aUfdy91lVnGd+Xl2aExCVekOW/LFnu6kIN+TWc+8mt66m255BIdOf0Aq1Zym7ZW7GquMhy4uPxr Rba0qWvdwScMYn1LWDp2CtLMC7cRk/tMZWUOPtDo7nqk6dbn7/z0fs8+V6vHtpB9LtC6dhxpuvWZ eGwYg3x8J+yTApqSagcAIUBMgPMLr+Y3C8gk0HDQDDllgGAItlirzlATtajj/Wo1EYReAQtCkpgk JQWTJpJYMgNHnGwiFRb7yyBlo9+MiFpSG/wCD6cchvAIp9DUze2G7cntoFu6Yy09g3StTaqohji7 cOiIv+Qc3Gpj3MnZDChvDezx77/19f8WZpQKOD1lW606PPE6W3lLMnvqPSkpnjqPmXxH/v8S5rJ/ +sj79/bwVe8iS/y/M99v+8o3Fv7fMf/VuXZFADIVglRQEn9MQUhZM7cFeRf/I9J/x7990sh1VM9t RR42gnJYhLzwLmUj828qKtAowFtJBeqC0gRwg1xgJEpLXgL636AZgLPw95EVaBClA16VwIdTvCTz A1ugYnQU6/CTcJI0MFPsAPt7TuSuKrqVOuVzKoUqqPob6FNSD2gyNd/T/UxfE5cbpaHWxDwIWNKJ toFVNytfg+yHtmbirYl/dSEkJXrQJ4+kBEyQAjUmYAbyuLYEzCIzOpCAOaRDjydgBWjmuQSsRPeh lxOwCplwfgJWIwNel4C1IMOGxX+WleJwAtajQ/jpBGxADpJEJWbVUJsg1QkYo2zyrQRMkI78MgEz qI78awJmUTFTmIA5lMa0JWAFKmKGE7ASvcM8m4BVqIA9noDVKJO9mIC1aC17JQHr0A5OmYD1aI7r S8AGtFURqh/aNRQdui/cL/aHoiHxnOgqK1sj1kb6wiP94XHROzo+Njoeig6NjpSKtXv3iuNDuwaj EXE8HAmPHwj3l24a2hmOt4stoZHIhmho71DfYvcS8Y52MU5wd+zW8HiEospLy1xLFJSg5EPdhiJi SIyOh/rDw6HxPeLogNgMc/CHosXihpG+UhBw11AkGh4H5NCI2FbaUioGQ9HwSFQMjfSLrYsdGwcG hvrCMrIvPB4NAfFodBBE371/fCjSP9RHR4uU3k0hLdHwgbC4ORSNhiOjI4PR6Fil03nPPfeUhhLE fUBb2jc67Py4tujBsXB/ODK0awRmXzoYHd7bFgnT+UQHYY7LZjwwCsJHRgei94TGw3T+kf07d4f7 omJ0FGjDIugnPAJdQ7vGw+FhOtP9ssT3DA71DYoHR/eLob6+8FgUNELJP4pz6ccJu3exkywpqkdD aBeUKJT7UBgCjQglBPUQQOeguFAZ/NYAVIsiqA9oRoAijMYB40Wj8B6TnyGZxyi0lsq0e+EnAp7y H4S2iFwLw5v2PSCPVYo2QftOGbPUX0QtUBsByg2yHHsB33eX0UugfHx/8TYO/xnarTJdZJGqHGQt A13cjccCh5L/wGhD8khUt1G5hc5lGN7jaA/gRtEAPJsTdvDLPYtlyUaAY2lCg7tkLlGZd5xySObd BhQtMlVQ7kl1FZVHG5GpWu8yYiOMOCDLG15G2SfzpnOJcx4FeDCh9d1ov2zVCFDSfgtzgw3oP+wh LbJ0B+QxN8v4qOwZtG1Qro2hStg8nOge+VcKNLdz7kvwLZWhYaD8r/aLooNQD8vtEdlbRxK2L5V5 DoM922SvXbAP1UXcjne38YD8ppqPyD2iIElIttWC/SOgw52gybCsP8pxNMGX0uxN2GMkMWoIZKK9 qd0WbLp/mY7vkeXpg6cIcxmFNtqnT+YxJmu2fxn3/6zMpf9lze69y0hLOpX3dzT/DpR8NIXucl1C QayETdcpP89jVnoGX72FL93Cwi08+j6W3sfvBgssf/YVWN72OSyHbp65SZw3R28eunn+5pWbHLou XJeuB6+PXZ+4rlD/7rfZlt/82mfhf42lX/vMln+Z9VkuzV6ZvTbLSLPu1b5ZX5rlf1Vfa/tVNdN2 DTNt/8zMW/i3MP/W/Ftk/i185mf4f/y0ynLpO/jbwTxL72tjr028xkgzvTNjMww97atnklw+/hue b5AZnHThFZtlBvNS3ddcFv6i5+LNi4y6NzYWI0/GzsZiMWbi5SdfJmdfjr1MDn0Fn30p9hJxnhs9 R/hzjefOnLt2jtWePeOwSGfURh/6JpyCIbO9QCqlWj3AQSgExeB5GcpVKMw8QJJFtPs+/YLd8iko L0IJvoCf2+a3PDtlt1ydmp0iVMb2Kb3Rd+gZ3HN69PSV09dOs/xpy+lDp0+enj/NPf1UlUV6KjXL Jz2l1vn4U7jn1JlT509dOnXz1PwphXQqM9d39mTsJLl88urJ2ZPMEyd8lrIT0gkycQKPvoZ1YJ9Z +gRZdFK+wegTJ8smySNHfJbDw/OWCdDllf3X9t/cz9zcj6MRjyUCSrw6gw1SDR73rbLsgyKN5RX7 xLGyMTIKtREo6TitbYU7rU3pZtoUwOJLw7hwGO8FqBe690AJ1KqxCm3HNHV+AZ4YiVh1sXy1T5zB Kqk8r8jXvc1l2eErt2wHZWyDd7IrqY0D87Iupm2UgZOAhyFTnTjWfLn5ajO15MXmkpU+qq3nmkGl N5vmm4jUtGqtT2rKLfBdCWJxS6HTp9piyfGpN6/YTPybOzb/0+Y/bP7LZu65zThtk73El7YpS/Q9 t+nLm0jAt8aywSda/DCZ9VDO+/A1300fmfBhsyulzYj5NsHFtxGM2jDCFgvv4Xv4QzzL806+kR/l T/LX+Hle6QHcTZ4ZRXjCjDk8g5+cbm1xOAIzyvnmQEwZ3B7Dj8ZyW+hTatoWUzwaQ23btndMY/xE 5yMnTqC6rEDM1dIR683qDMT6AZAoMAGAkDVtRnWd0Uh0v4NeOA4gR8ThkMGoQwZxBEVoA5YbaRt9 RBxxVJTiInEsBiACm33UEb8pNkKRDiSTR/Z3Q9WBuiNRHAGuMHQcEZFHcVBalBBHZu3ojgB73E2x WBaNXtA3kvZ/AHfeqZUKZW5kc3RyZWFtCmVuZG9iagoKMTkgMCBvYmoKODQyNAplbmRvYmoKCjIw IDAgb2JqCjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5hbWUvR0FBQUFBK0xpYmVyYXRpb25T YW5zLUl0YWxpYwovRmxhZ3MgNjgKL0ZvbnRCQm94Wy0yNzEgLTMwMyAxMDYxIDEwMTRdL0l0YWxp Y0FuZ2xlIC0zMAovQXNjZW50IDkwNQovRGVzY2VudCAtMjExCi9DYXBIZWlnaHQgMTAxNAovU3Rl bVYgODAKL0ZvbnRGaWxlMiAxOCAwIFI+PgplbmRvYmoKCjIxIDAgb2JqCjw8L0xlbmd0aCAzMjYv RmlsdGVyL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnicXZJNboMwEIX3nMLLdBGBIZBEQkgpCRKL/qi0 ByD2kCIVYxmy4Pb1zNBW6gL0efze6NnjsKzPtenn8NWNqoFZdL3RDqbx7hSIK9x6E8hY6F7N64r+ amhtEHpvs0wzDLXpxjwPwje/N81uEZuTHq/wEIQvToPrzU1sPsrGr5u7tV8wgJlFFBSF0ND5Pk+t fW4HCMm1rbXf7udl6y1/gvfFgohpLTmKGjVMtlXgWnODII+iQuRVVQRg9L+9OGHLtVOfrfNS6aVR tEsLzzFxdkFOmBPkHbNETon3EXLG3gp5z3Xqc2DeIR9Zc0Q+cR+qPzKTvmT9AfnMdeIL12PkijhF r4xYg3XJ+bMSmfPHmE1y/uSEzPlTPItc8xNz/uyMvObP6NLW28Hrw/n+jEWou3N+JPQIaBY4hd7A 7zuxo0UXfd9l9KDtCmVuZHN0cmVhbQplbmRvYmoKCjIyIDAgb2JqCjw8L1R5cGUvRm9udC9TdWJ0 eXBlL1RydWVUeXBlL0Jhc2VGb250L0dBQUFBQStMaWJlcmF0aW9uU2Fucy1JdGFsaWMKL0ZpcnN0 Q2hhciAwCi9MYXN0Q2hhciAyMwovV2lkdGhzWzM2NSA2NjYgNTU2IDUwMCA1NTYgNTU2IDc3NyA1 NTYgMjc3IDI3NyA1NTYgNTU2IDUwMCA1NTYgMzMzIDYxMAo1NTYgMjIyIDI3NyAyNzcgNjY2IDUw MCA4MzMgNTAwIF0KL0ZvbnREZXNjcmlwdG9yIDIwIDAgUgovVG9Vbmljb2RlIDIxIDAgUgo+Pgpl bmRvYmoKCjIzIDAgb2JqCjw8L0xlbmd0aCAyNCAwIFIvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0 aDEgMTAzMDA+PgpzdHJlYW0KeJzlen1cG9eV6L13ZiQQII0ADWBhZoT4FiCQ+DRgxoAELrYBA7bA xiCDMDg2Ekj4K05tp04cE7u28+F4N22c3aZf6Us8OLGN2/wSp7+m3V83Tp022+xutolf6jTtbqj9 +uI2L4nFO3ckMM663X37e//toDtzzrnnnHvuueece0ciNDHpQ/FoP2KQPLjdG5DzsyWE0OsI4cTB HSHp0KaKSoCvIkRahgNbtuc53/k9QmweQlpuy7bdwwfHjv8QobgShPj0EZ936OYnuYUImVeBjooR IHjD92sBPwh41sj20K6EOF0z4N8BvGWbf9D7kvR3mYDfADxnu3dXIFXzOYtQeirg0ph3u2/gtXfX AF4F490M+IOht1HBHKgqof2BCV/gLP+nWcDbEWJ+BzQMf/SKB1BDccKwnEYbE6uLi0/QG3gj+m92 ca9zr6P7uAPIhHar9zsudhlKRjsRmvuIYrfv4fX/f62IUe84DWejm+jfFnW8in6Bvo8U9LPF3DgX 59PVw4noGvoY/fjPaQV9Il6lgu+hN9Fr6Nyf4SPou/gW+kecBnF+ASBKq0fv4D6w51mgTaKj+HO8 G1vQ05hXe0tBtx6zd9FVh+fQVbDuMXQVPYab0FUuyKRBxz+S19DXmAPkMvp7sHkNOQq0OfQ2eh2X YBcKohfRt1QFQRjv6GKNDEJ/i06hr9ymcs+HX+IOkPPIOPdHdB69pHpgH5pCAwtCN/Dv8XHIyTQc g+fX9OX5Tm0Ls5WcJ+TWo4CcQFugefE/AfdRZsUXpvNs2B8ewRx6FCx4H3egY6Dl+fDF8DNoEzpD /gF1oz+A3U2cUXb1eLq7Otd2tLetWb2q9UsrW5rdrqbGhhVy/fK62ppl1VWVFeWlJfbiosK83Jzs LGumRUxNNvIGPWR8bIxWw7EMwajQZXUPSErOgMLmWFtaiihu9QLBu4gwoEhAct/Jo0gDKpt0J6cM nMNf4JQjnPICJ+alWlRbVCi5rJJyuckqzeDeDg/AR5usPZIyq8KrVZjNUZEEQCwWkJBcqSNNkoIH JJfi3jEy5RpoAn3TcbpGa6NPV1SIpnVxAMYBpORZA9M4bzlWAZLnWjZNUEwCHVZhsl3eIaW9w+Nq MlssPUWFKxW9tUntQo2qSkXTqGhVldIoNR09LE0XXpo6MsOjzQO2+CHrkHejR2G8IDvFuKamDilG m5JvbVLy91xLhZn7lEJrk0uxUa2taxfGab09JFa4bN4qTd1EMB3r7Ed3UrxRiiabv4ko6Ab3Tk25 rZJ7amDKOzO3f7NV4q1T0/HxUwEXeBi1e0BqZu77D5sV95EehR8Ywcuik3WvbVWSOjZ4FJLtlka8 QIFPvdVSZbYYe+Z52v9cNwJHgDvApxYLnfjDMzLaDIiyv8MTwSW02XwWyXZbj0IGaM+l+R5TN+3Z P9+zID5ghdVs7fRMKWz2yiGrC3z8sFfZvxniaStdCiuv6P9otlinEo1Stb1H5ZXAqpVDo5LC5YBb QGqxAEQKFZniVUT/x8hj1gwD5BgTpWorqKF6XFbXQPSzYyQVFEhFhUqLLbL0XR5FbgJA9kbXyDVd YgcJ7wAs0WiTunyK3RpQkq0NC+tJzXKNdnpUkaiYktyooIHBqJRidzXRkSXX1EBTxASqy9rhuYic c1enyyTzC05UhnqaKLPQCHGV45ryDA0r4oB5CDJtWPKYLYrcAwvcY/X4emiggYfyr8JwFnVEhTR2 eVo7ra0dvZ6qqCGRDqqOzXZ9QY3VY46ogZBTYrJjJA8xMz3AyANBcgNgbaiFu6LNjoHGg8NVKg3V hlrJg81onhvMUPIll68pykfxO5RyNJwaW+a1aSgKehpbzJYeS+QqKiTQLUUHBokY6tSW+S4mGyoB 0AioUUnUl6k05iWP1WftsY5IitzuoXOj7lG9HHWG6vPoWnXdgS1yFrgJWaB7HqHOVNw282LnKs0q voC2fKF75Xy3NBVjbe2cosqtUYUILF+pIBrCcpXRrGY/zWer2wtJDBmt5vPUtCzTXB6haTtlXTk0 Ze301KrcUEHuM++hYyWiVtza1VBUCMWsYdqKH+qYlvFDnb2ei7BTSg91ec4STBoHGnqms6DPc1FC SFaphFIpkSISRaimtYDEqPzmizJC+9VeViWo+OAMRiotZp6G0eAMidD4eRoBGhuhySqNXrBKqSPg Y6jfLmmIrs/enpGpgR4a40gAj8AHK9i6HLxjXT6NiSZe0Vl9DUqctYHS6ym9PkLXULoWIgMLuKhw zxTvst5MLaI7JkFNcBviumHj1qLiaYzstWe1bOasY1rD/UvtWYYAiKYZSuYo+axWY/289iymdKfR Ysy2GC1NRApn4VPhEa770+81sZdVvYfC69ljbAfKQhWo7yLKnLsqp8eg1YwEt+zmn8EZh6CqQBUu Sje6ryTixJm5Sy9k5bXQp5wYE9+SmNeWLvGCwWh2tOk4AdU7Z+vr4YbtNlvfrMMxzr87Pltagmw2 nKwn1sxikmvNYExgUllOrgUg53LsdGQQrizHmqknpuQM4nQsJ+yx0uGv31PSv27lEg0mBIc/5Bhs JBxDWOfZyS0nvfbwOwF/QeeK/LwVawsquqozSOa9V052JxetrODyymvSwl72Xzvvz9LmlVWZ7tnY 9djlPRdfsHYf2771aJfVtuGr6tzb5z5iH2XXoCRkRVlycnIzyh7IDmSTJc26lDYDL7bR+czWw1xm YRowi/kplJctJwtGaxZsftQ19cbhgz897G586I2pR974Sl34n7+8a+9Bq9xbsdzbkEky9r7xeOfa x3523+7LJ7u6Hr+859XnlVe8R3pttt4j9C3iEBgVZtvQUrTpIjLM/fbFWB1aZaKeTo+NbzGZxH3i aZFcEbFd7BfPiEz8UvcVEIsuCX3KCcCI0trjE3mtAc7di5eir2/c6LTb6Fo4jWWwDhHvM06HkGIq xnQixmOYAWfHE5ZlWFNBdXtNWmmCuTJndJKpta5prk6Ir3G7TDV9K6yxmn/TxD777Vuz1O60ud+T E1wVSkFdspPkUavj4/uTcXKyTu9mtAzHtTH9jJ9hGDmnsOVpBjMJXJtGp4mJ0RiMbUh1stNudPKz Dmzvs41HYYe9z2kvLbFxmTnlRmu5s9JpcpqsxmTB6aioNOkxfmbvg4ef8CiXL9fWLylYUhZKPHSY fPnlcPjlW2+0tcZonjcaI7nTBeu8Ed5IslA5apILRC7b/Z4FW2RwmqUyUIntzZf0V/SkRI/1Iipo S03iS9u4WEH1H4QzfMCscRoDakiXlliKmXKrHi8OhRRnWU4Z2GkB+1IwuFeNZp7GBbOKcBzDlp7Z M/y41w5xva18c1dTKsEYp2lI+Nd5KzptFZ3VS39V0NWQH5NfVmEa3dB18vLue994vEsobnHqch0V afjhz6S2ezOJ9Z6jnZaC3iOD4eNZ606oLweoBeYnQtzUoFMX0bK538q6WLTawtN1IDNzN1TU4RYL 3PkijRF3mtQi5ov5OpNbze82UFHXXodL6pQ6Itdhex2Oc+scJs7ekfXzAhwowGKBvYAUFGTxfAfH x0lxJC5OTXV7H09Xrq8PnonV1ZAnEGQT/LvgLEDtdhs/y0Pa2BYlf2UGQ31STgMQvDjvPW0xE82k lAyGFVfsfTG45Vv3dZn+FF+wvLO8pLMus7Q7uKLp4IhcG/qe33NqVwf/f7RZ5e6CoaH81i11rSfG Xbh2zd719gzXWEd2UVWGLs5cml1QKqYYDAUt/u7Vu7uLLM1ja5bkOjPinLXZhUtNBt7WugNF807z FPivGn3nIsqbu6HmHbjqqtxNIanajVBCkfta4ceFpLCmq+ZgzVs112rYmhr8ZM0Pat6pYbpqMCD2 GkzEGoxqsFJzpeZqDXO6Bg/U7K8h0JEW70YJUkJJwpUENoEuQhIEX4JT055myWGW8kmGogQabg5H fX2Kk6ZBJGPBneP943BNUK/OGqvtsw61mFqM8yFmtCxKZkyTWc3pjPkeyqQ1MvHG3Poim9uZHv5w UY6XPblt7xNLNEsbO/qreu5dbQ3/jrIVuJzphPTXj7YWFHUGXbdeYlqsX2osT4gvl2Vhb2B3sLG3 MlUOnPLc6ohw2drGGm+dUXOtFmJxP9RUyDR0+Hxpamy86sobcjYEoZaHG5MaG4dWVTji3JmX8q/k k/z8TPcrbtzmxkJzCnVNvim1JSWltpmTE/gWrnKtTpdeLwp2YZ9wTGAFwdiRzufWtznstHA4HLOO +lkIQWMi+AbcBrBttm+cf91Bg5MmK0QflJBIptbj8nmXZM97Sa3eUE8gAHNyIauTtHrGRIsMRCk+ vObedcWNoa95fmfKq8mxVualceF34uXxb/p9T40t0yZZ06WMtLy8ooytPp2m6sxPjxd11GU111R4 6jKTbZ171gx8pSMbs5U1bQ6T3lpTpG+eXGd3DB7vD+/Iqc03aU5BFWRHfL4AiSUETgTVq1uLWzc7 ISbp3lQJfpRQpZzBuw0Gs7stHadnCs1cUpuO53W8bMZmc2qkfIIDIA95ulPROHHaIeu4xdWJixR4 npZOTs+QtQde3S+7D7567+g3dqzUhz+IH/CMj/yqfVsCXqJr3v0/ktsfubz30C9OrKryHlyl7xz8 /nR4yjeU0Hp4tB5sq5n7iNNwJ1Ed2n4RkN/KDZF6g1YX9OY7emltEXVJvag+rtegE3Vtun6dX8fp khxcUX8WlBGW71fLSEkcUxInq9UkSa0m42o5idaSPphKpIzMV5GFIpJNi0hFpIZwd84xcoRIyeA4 jfvRD5468su/6jfhpfHFHbvXnTwtb51qrd21fZMrt+vxN/ZMvfbA6sTw+8KhL6/ZUrfE0Xtfa8P9 O4ZbbfjkwNcDdY7NJzbZ7WuqxQ3eZV8qkQz6jIJl3ROrR0/2F9o8D/TkbthoLq7LLGssEnm9WFC7 flekFgfD62EvfB1OaTY5TcPDMZVwN0SEJVQC2cHexIi7iczRYwXUSZj1j0pLkowWE5zQTEGSEf4I J4fXaydf/jTmFdCnR4hr4Q4gHn3jnIHXQfrQZDLQuoQlQHEquB22/hsv6NTnb+VSIFxKxKcT8UAi tidijGJjiYHn7Xw/TwL807zCX+VZni/hB/hLADDqHmGpJ36yj5wmZ8gr5DqZIzEGIgLKkNhYbCAM TqSbISQZtbqKrtVEFaBGp5NWqUiW2Wz5GFtwBk4RUioql+NKbGEawv9w60+4DGfql8TFx+nidGY9 sJRyBz7fWbQpt7ggvyin384cVn0Hd/YZmCuHMuUkVtuuxUxvxG+YYfpRIvUajYs+/o3SEnqqtZgO 41zyMXfgs8FrwOUEX50AeS1KJu/LbUmE4fBaJoHZxHLJLOzAyRhp8FqUgDZpNclaTQKrlZOEFq02 RUvitMJPhLcFckrADwpYK6QIucJ6YafAPSF8W7ggfAiFh5amuZ9ebokR8N9R3g8FJsK9U8B5ERny J+gT8AUBf0vATwh4l4CbKfqhQB4STglkC2gkVQL4B2sEfOqPAn5LuCaQ1wR8XsCPCt8QyEEB+4RJ gXQJuFHAWUKZQEwq88cC/oCy43PCawJ5RsCPq2MPCSGBNAqdAikTcLaABQETAf/vuyqeFPCwgEGz 67ZmVsAjHwg3BQKagfsFAaOnBfyIgEPCQYFsFnC7gB1Cg0CyVN3y26D9hoDfF/CPhLcEclbAYMpx Ad9PJfBaYbNAmgRcQQfAvGrLNeFjgfyS8uO/Fc4K5DEB7xAeFMgQZcdlQpNAcgScrE6y6g+UHwP3 DwX8ourFg5QdjB6ibG6BJAoQ0FQbaH1aUKiekPCYwLRTHVQbcxDQF4Ufwfy5gICbqCS1BIRiFPYS ewW2PS0m/clpCTiBS0rSQGDQ0HLUO6vtidV9sPvSGN/U1x/Zfunm2z9x+9rUt+gav+Na4On/d4x9 d2e8zXZHz6Y+m0rgfwmQsfqQ7ZDtR/ylSzx69RCXGkXgFMrAH7bE4mImVw/HbAu7/b5bH94X/ifY 3jcSdOuR+BRjHMY6Y0r8w/hxPBI+xR34dB/zjrW5JocwOcuareF75vOOq4O8SUIBOQulxhpbUJxx 48/gbc8km9pNAyYmYNpvIpKpxPS06ZKJ1dEyowc2HdZulGJKYkhMHD0tJUeqknqPw3HGWCZm3rP0 MGijuetw2NQj4jiFYA5YSMnA9KhiwTm5xZgeoJlf3/prjmW58Ke4g/gphDVsXWFhjifv81ch179f UJy72cE4P90HOU9tHwfb41Ea8lxEqXNX1dNbqloJ4R3WQIukoQpqoiEV0IQNyHzcjEvMspkk9yJN iUbWMDGapH4tk9yvSYzW5U199AjxbuS9VT29Ejjtg40OVkjkYNuxYSM9H3DjW2c+O3Hrxzj8DE78 8Vj47cZd3/a9+WnPE/568vdK+OaLG7kDa58Nf/rivcp4xefNy+89r/o7DfaISnWPyJdTWZH+eqS9 IZESIkO5ZW9yCC/aIiAc1R2iHIaHloaF8L/CLrH+Fe6Tlz95WNUHjctQvvbC1X5D7U0kRn73+En3 987f/so9vF7zFIyIUQz4LPqjAoy6PLwGNd7+meEL39Mnko9QE/trdAhaO7MUHSLPojSAu9ggatEC Ds9aaO3cOlQDfUF46qH/MPcT5IRGn4epDOgqRM+iP+A1+CmiJ88zXcwnrJt9i/2cm+Ae0RZrj2h/ E6OPWpCIXFEbCex6dtQLu8Iezd8gRu1Nx+sW7JQXbMbIgOQoDLssaovCDBJRZxRmUTKaiMIcxMuD UVgDcf9IFNaiPeibUTgGJWMxCsciPXZG4TiwYcXCL37FuC8KJ6B9+OEorEc2oqMWs7GA7SflURij DHIuChMUQ34RhRm0nLwThVmUx6RFYQ6lMiuisAblMD1RWIs+ZvZF4RiUB2sQgWNROvtkFI5DVeyF KByPNrLXo3ACCnOtUViP1mlWNo1uGQ2N7vENSUPekFf6ruQoKamUVgQHfWNDvgmp0T8R8E94Q6P+ sWJpxbZt0sTolpFQUJrwBX0TO3xDxatGN/si/VKndyzY4N82tCBcJH2hV6Ldd6Ot800EKaG0uMRx u592F31BZDQoeaXQhHfIt907cY/kH5bWgu0t3lChtHJssBgM2zIaDPkmgDg6JnUXdxZL7d6Qbywk eceGpK4Fwbbh4dFBn0oc9E2EvMDsD42A0VsnJ0aDQ6ODdLRg8d0c0Rny7fBJq72hkC/oHxsJhQLL 7PadO3cWe6PMg8BbPOjfbv9LfaHdAd+QLzi6ZQzmXjwS2r6tO+ij8wmNwBwXzXjYD8YH/cOhnd4J H51/cHLzVt9gSAr5gdcnbYN5jIGod8uEz7edznRStXjnyOjgiLTbPyl5Bwd9gRB4hLL/Oc3Ff8nY bQtCqqXwejeKtkALQduDfGgIXlWGkBdwL0DfheaAo1sJqgRoBQqiQeAZAw4fJKEERccPz4B696o6 /NBbrPJugz8J6FT/CPQFVcwHTyq7Qx2rGK2C/s0q5ba8BMnuhWcQNQC+Dfj+/chF0P6yrLQg/Z/l W6fyBBc4SsG+Epj/3eTnpYv+g1FG1RGoL0NqD7V/Ozwn0D1A86NhuK+N+r1FlSwEaCXIDqp+pB7b omoJqbojnKOq7m7g6FS52lVJ6p+QOtqYytV1lxHbYMRhkKfevM05qOqmax7R7Ad4JOrprWhSXcUg cFK5+bkFYeT/bER0qtbtUMdcrdJDaiTQvhEVC6BlsEnY0U71rxh47tQ8GNVbrELbgfO/KhdCuwH3 qf1BNTrHouterOrcDqvZrUbp/PpQX0TW8e5rPKw+qeeDqkQILPGqazW//kHw4WbwpE/1H9Xoj+ql PNui6zEWHdULNlFpum7zazq5yMc7VXsG4S7BXPzQR2UGVR0B1bNDi7T/v9pc/F/27La7jHTbp+o+ rl5zuehtdJfrFdSOtbC52tX7GczKzfjKLfzKLczfwv7PsPwZ3n/z+M2nbzL/60a5aL9x+gbpv47t 1/uv+6+fvv7ede431yTxg2t14vtXc8X/ebVOfK/uV93v1jHdv5rBGWdrRfuKOJwBmnm4S9BkaMzc JZwh56Wlu/+FmRPRO/if2VrxrZ+ni7/4eY448ObxNy+9ydCHAsDVNzn6Jf2baUvd8HzxTV2C2zCD BdmAX3k5R5R/kL/CLf8gM9c9gy2y9XydiGbwzAWdiC5gdEG6IF8YuBC4wNHH8QtXLty4wM1gSU5o Ab5zA+fI0+eunCP05VR/Lk7vNpztP0ummYjNaageWhumx4ljcMdgeZqcl5PvFs/Yz9SfOX2GNZzB 8hm94EbPBZ7b/xxz9bkbz5HvPVsuPtueI17EZrwEpg/mLDmPDd/Fhu/gl3AKTkK1SMQm+VB7rfjU k7ni16F9Ddr+J/Epd554+okzT5CT7nLR8Jj4GHn0eI74yIkc8diROPGrR3JEw1HxKOk/6j+67+jc UVY+mpTiNhzB8pE4g9twWDxMHnzAIPY/gCvud99PdoARk9BC0ILQ8gPYHMBMAH8cwL8M/CZARgK4 J4Dp9xehADjVP9Yijrkd4hKc2p3mTO3WOpluDayOF2QH+h1iPzw39baIG9254obeXWKvu1RMciR2 c5jpZh1Mt5/BBqaeIf2dWO7MK3TLnRmZcEtKda/tyBM72tLFdmhpbfltpKdttI3M4EQ5350trnSn iS1ui9gMk/7EDU7AgsPUbcSGbt5h6CYYdWM0J85g41lzLDx4uQ6ePH0H4c2SucQcMLOiod7Qb9hn YA0Gu6HN4DccM7xnmDNoI9TrBtaPcD/C+wXM4Rl8fLqr02ZrndHOrW1VtO0bFPyQkt1J73JHr6J5 SEHdvRs80xh/teeBo0dRw9JWxdHpUQaW9rQqQwDIFNgPAL90WkANPcFQMDQZDEW+xLHhCITmCcHg JKVSkm2eRSUHg6FQCEVEgrYgsgVtoUlVAgOIglHpIGWn2qIfTO+AT9pCqirKGAxRHhuFooMhlUjV qBeMEKT/oPd/AR4KiwsKZW5kc3RyZWFtCmVuZG9iagoKMjQgMCBvYmoKNjcyMgplbmRvYmoKCjI1 IDAgb2JqCjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5hbWUvREFBQUFBK0xpYmVyYXRpb25T YW5zLUJvbGQKL0ZsYWdzIDQKL0ZvbnRCQm94Wy0xODQgLTMwMyAxMDYxIDEwMzNdL0l0YWxpY0Fu Z2xlIDAKL0FzY2VudCA5MDUKL0Rlc2NlbnQgLTIxMQovQ2FwSGVpZ2h0IDEwMzMKL1N0ZW1WIDgw Ci9Gb250RmlsZTIgMjMgMCBSPj4KZW5kb2JqCgoyNiAwIG9iago8PC9MZW5ndGggMjk4L0ZpbHRl ci9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nF3RzW7DIAwA4DtPwXE7VIH0b5OiSG3SSDnsR8v2ACk4 HdJCEKGHvP3A7jZph0QfxkbYZFVbt9aE7NVPqoPAB2O1h3m6egX8DBdjmcy5NircVvhXY+9YFmu7 ZQ4wtnaYioJlb3FvDn7hdwc9neGeZS9egzf2wu8+qi6uu6tzXzCCDVywsuQahnjOU++e+xEyrFq1 Om6bsKxiyV/C++KA57iWdBU1aZhdr8D39gKsEKLkRdOUDKz+tyf3VHIe1GfvY6qMqULsRRmdo3dN 8priefKGvEneUg56R/F18p7idfIDWSY/kjHngN6ij+RjckXeJdfoTZV8IuM5DfkULQU53UHS/bc1 NnvrKrWd3uVnnFxdvY+jxMfDGabpGQu/7+sml6rw+wZzHZMjCmVuZHN0cmVhbQplbmRvYmoKCjI3 IDAgb2JqCjw8L1R5cGUvRm9udC9TdWJ0eXBlL1RydWVUeXBlL0Jhc2VGb250L0RBQUFBQStMaWJl cmF0aW9uU2Fucy1Cb2xkCi9GaXJzdENoYXIgMAovTGFzdENoYXIgMTcKL1dpZHRoc1szNjUgNjEw IDYxMCAzODkgMzMzIDYxMCA1NTYgODg5IDU1NiA1NTYgNjY2IDMzMyA2NjYgNjEwIDcyMiA3MjIK NzIyIDMzMyBdCi9Gb250RGVzY3JpcHRvciAyNSAwIFIKL1RvVW5pY29kZSAyNiAwIFIKPj4KZW5k b2JqCgoyOCAwIG9iago8PC9MZW5ndGggMjkgMCBSL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGgx IDEzMDM2Pj4Kc3RyZWFtCnic5XppeBvHlWC9PnATaIAgAB4gGgQJHiAIkCBFUqSIJsVTlARQJGVS Eg+IBEVKFC9AkmXHQyoZRzZtRUriHF/kxI7X40zisQXJjkd28kXK2utkJ85aWXsyyU5mpEwUJ55Y jnZj5/vWtsB91QB0Wcnu5tt/20B3v3r16lXVu+pVAfGlA1GiIyuEJdLE/sjC3GComxDyGiFgmjgY Fy9FvfUIXyKEaZla2LO/LPDP7xLCiYQo+T2zh6cub//CWUK0ZYTkvTYdjUze/8EHHkJK3kMe66YR 8aPkl5SEuCuxXDy9P373T7SfjmA5jOWp2fmJyFvb8wawfJbS74/cvWDif8ti+SqWxbnI/ugjO8pz CCkVCFF1LszH4v8EjiQhviFav7AUXfjONcMbWL6bEHYRcYAfeukQVNAyw3K8QqlSa7S6LL1BMJqy zTkWqy2X/H9y8a/xr5H7+CMkhxyWn7dc3HpiJocIWXtn7Qx9Uhx9Ju/6fzsKVfoNpWAkvyRrkAN2 UJK3yffJG+QlkiCv3xgviEhXCUXgBT25TN4jr5LfAXxsXkfAhHRG8nMwk/3kIvkJ+U/k2+QL5G/J Wx+je4A8CQy0kRfJCvZ7TR5JkPwzjEAJ+Rba/gFyDD5C3K5MK6iGXNADB/l3nM4ltK1HyCXyCLST S3yMzSXPkn9kfkO+xB4hX8UR/4hslel+cr3FAnmenEpDy+Shj3F8Iv0+dmPczAvEuPZHcoZ8F3kS bLVKxq/To3+wjtt4fC8DKLvZvcwLDHPt81j4LNmDdwR+jh58jG29vePkfHJaBr5MXib/g/lH8jTT T+5jXkdu7byREKljeGhwoH9bXzi0dcvm3k093V2dHe0b21qlYMuG5qb1jQ316+qq/b4qb2VZqbuk 2FXkdNjMRsGgz9Jq1CqlgudYBkhlh6tzXEy4xxOc29Xd7aVlVwQRkZsQ4wkRUZ230iTEcZlMvJVS Qsqp2yilFKV0nRIEsZk0eyvFDpeY+HG7SzwLO/qGED7W7hoWE1dkeIsMc265kIUFpxNbiB226XYx AeNiR6Lz4PRqx3g78jut1Wx0bYxqvJXktEaLoBahRJlr4TSUtYAMMGUd608zRJVFu02wJR2RyUS4 b6ijPd/pHPZW9iT0rna5imyUWSYUGxNKmaU4Q4dOHhJPV55fffisQHaPe3STrsnIrqEEG8G2q2zH 6urRhNGTKHe1J8rvuWzDmUcTla72joSHcu3ddr2f3htdQoIvEVzi6vsEp+O68s6tmEgaoygR3icU 7ETxrq52usTO1fHVyNm1ld0uUXCtntbpVhc6UMIkPIStzq699FB+ovPh4YQwPg3r05Pt3NabyO7b OZRgSjrF6Qhi8Bt0ORvyncbhDE34T1UTFASKA2XqdNKJP3RWIruxkFjpG0qVRbI7/wyRfJ7hBDNO a85nanIGac1KpuZ683EXarO3f2g1wZX0TLo6UMYPRRIru9Ge9lJVuISE/o/5TteqySg2+oZlWhFH 1TM5IyZ4N4oFW93cAC2FNlkV5IL+j6nXlXzswG00iY0uZEP5dLg6xtPfg9M2ZCB6KxPdnpTqB4YS UjsCUiSto47Tfh+2iIyjimbaZfUlfK6FhNnVdl2fdFgdM/1DcpN0s4R5Y4KMT6RbJXwd7bRnsWN1 vD01BMrL1Tf0IgmsXTpdK+Y/FyC1ZLidEls2ol25O1aHJqcSjvH8SfS0KXEo35mQhlHBw66h6DA1 NJRQ+SXszin3mGA2Dgz19rt6+3YMNaQHkqqg7LiSjtvYuIbyU2zQ5BKqEpU4xOSzw0goIELsRMDV 1ozPhLJEhbeAApex1FTbmsUhjMAZahxGolzsiLan6Wj5FqY8NaeN3RluClpEPhu7853DztTlrWSw Wkx3jC1UVKjdmSq2BCMB4hhkI6OoLG3U5sUhV9Q17JoWE1J4iM6NikeWcloYsszTuhq4pXSTsFBM xInVmQIVZqLTk3+zcBNdcvl6sfu26p5MtbiqcvX2r1LmrjRDgiPvSRBqwlKDMV/2furPrs4IOjF6 tOzPq6clifryNHXbVVfP5Kqrf6hZpsYIcl/+PbQvE+mF3oE2byUGs7bTLnig77QED/TvGHoRczHx gYGhMwwwG8fbhk8XY93QiyKuFTKWoViKpAWRFiinbVhQyfT5L0qErMi1nIyQyxNngcg4VQYHZOIs k8IJGRyDOC6Fk2QcvVBLtmmUMcbvDnGS6ucTw9Or48PUxokFJYJfSICrBaXjajkNjEKX0LiibQmt q43igxQfTOEVFK9EywALeCvvWRU6XO/bvHR9ZEg7Pib5QcyUlaTqNBBf8xklZ79Sc1rB/6L5DMsg SE6zFM1T9BmlovCj5jNA8QGj01jiNDrbGTFZDF9OTvODHzzdzv0Y+bKkGFf7ezE3sxAXqSKPSlEF Z+EYFbERRmsVdlYodp6ww7wdDHaw+61VxS5XcfFOCzFbCBEsfotkCVtYg2XZcsrCWoi2asxqJcVj FpNrjLCz+4dEP1z1w3k/PO6HBT/4/SD54YIfRpZG6LXoIcErwSvGRt+Vxmo/+Hwjiz5P81HPfcIr R8+fB5vw5sjiyJU3kaDaPzICzppCJsesZ5SFLH25nIhpYepqqxBkU6AbkeuY7k+d+6sNVYN393TN 9pREn768fC0I/wDuu+7d4nIGR5qSb3wXusce3ul94CvJF/gjlQOHt/TEBhsNuoa+aON9T02Usz0W f29tZZNL/1GduWZA2kFzH0AJEWYXZrQsWZWGVWADRk14OM7DOA8GHrQ012AJ0wvEDIQBEIhAwpg3 PY45Jm8g5wiThVsEIDlDw0NXebjEwwUeHufhBA/IJxfvjQkelkZHRmXpjKB0giiUUVkqAvn+Ud4j P1E8QEkWq/2jIwFwggtEyE1e5F/7oJaOc3DtCncOs2sP+YP0oM0D6uLcYsZmADtuQXAbYjD26g1m vd5AvyE9c07/uv6ifk3PhfVwXg9BxB3Xs0Qv6EU9q/cSL4jeBe/j3gte7qqXJsO9ngqzp4J4Kio8 hgp4vWKtgglVLFccR4ATKsQKpsJQYbSzRXoweAzqcJHFSmdMZ3MlGGhsNFkbqapHFpd8pPPvK8s8 QkVFpcYjNANO0yN0p2ZKJ4kkNuEVOtPFJZnUIOj1N5Me5YXrIhHOowkhLbB6NA9LAO2hPtuJBaWz FkGXnnUVuesomM2Qg5xaxW/e7Bvra9YdhLynlFkaJSTf45Uqji3s3rHQ8eWv4M6NXebWX3smu6qq TB9sK9s0IzGjHz1T1LvRr+QrG5vMFZsaxM+tmqq8FVnMMfTR4No73HpuK9qJj8xLW5V2UJuh2Ada ndh1vBSEUiCl4dLx0hOlj5deKFWUVvvYrhOWC5ZLFtZnCVpC1IX6fD5FxbZ8QdG3XTulZTitWVus ZbVGCwkGRkbQWUzoLIDSu1Ije8e112pGZOfQQ2bSVjrTKoZONSB7jEJZ2gLUN4rQd2CKY0d2VrTV lurfL9w895V9c9+MNd118qfLC0/O1mZp32FgIly0uavRCL+wVFr3LuZ5W4o3STObylqWnph8Mnlq Z/P+L+30Hqj7jpCn37fb0hQNyb5B48iDGEe0JCaZZN/gVWpOrdBoiICx+uzaeananNfNZHFq9S6C 2ybqHn4ioYOwBtxfnCIsENUYz6u5MWDVY8SE4SMVHlIzvik2YGB41TOCUSMgYJigWkcnUGIIkO9i MHIDlR+90cFcrbwmdLPbvfyRy8mvXU4eu5zyYe4YtwV941Fpl6rUVsqoFDYFU+GBbQQqwNMrj82D g7tId/PnUa1e0Yuug84C29B/jIZewWgWjAajIBhDwrJwXFgTOAH9Ai1dMAoWg0DS5l4TNDXS6EYH 78PB3/BgDw1wsEiNe/H2CtmKndktbEZjLC3UO2ngC7SwgRqLHANZ5t8yRjzat0F3MPlWyohBlzLi nh3zGSNm+tGEy7NSJnztCbb/DiZcrr8Wo3qkNjyINuxFPYatxaAoBpsONDrwsGBjgeU8hVBI7II9 bB+3c3bfgg88XSf0F/SX9KxPT2MHq3cUgg6pnCGbILDAYSsSUlsSPhhBfdaMjMgP2YZHhJ+O1Iz8 FyxSGx4ZKalZV89nzHddfQtPDdjKV4EsCNmvGVv/rAgGW/+935yP/91ig1Kbu2VsLn6ocd+jM/WK 5GW+r6+hXwpYOZWS2/HMzJ6a0Cd31bQsPjpaNuqd/w+xnnLD+olP9Vh3REv6lofNXm+58fAiKlmD 867HeUskRN6QxrVW0JryTUxJXV1dRx2raQ3V1tX1hgrMoVBBKHQxBMuh4yGGhISQGGJDfb4+KCgr 7+jymYPmkHnZfNx8yqwwG8ocZb6ysbL5Mr6srMDVVxXapDE80vpkK9N6du2SZC8Qu1vragsKDFXC ppCheRuLKylaDumDS30gL44B3xXhClqRr7Hxx9TijY0CXS2p8K68UuMbocFxESNjuKxACIXCt0VG OSieB1m2JXqQw9+6VCCUwwMXZG7EhZK0aaHB0FBSiLFjXT24MjDGFa68Yrt3cpZhFUWdg3u7tsY2 u71bZ+7+ZPAc7rTbm+wt9V5d8n8K3fGv7339+4Kqi+XNeXlKfa41eeKJA0dtZXV2e1dHs1EnKAY6 DE6hbqDJUdM/29h3cKCuUAdscaHX3Naisjf6HRtnt1R87guO7WXJx4ylgi1PxzI8hJldA6WNxUbr up0b5Zxo7Y3kXdzXUWdWEiQvSQGFaBGZoq6LORDOOZHzeA6b07o+yFfVVFfX1OwK1JoDgdpAYC0A Acle3C0G/AEmIIclvaXbiNjaqmCFnc8itYFGErJnhSosjYZAvl1AjYitsNIKC61woRXCraiaVOqC F6rHaGpMfdMpjAc/qBKprFYIBKSPq+Toef15PpPdXEHdgGzbN+Qs60RWRyp4ywtXKWri5kjA/Kx2 PBw0q9T2uk3eQH9bwKTWbEl+37Vp+2Rz318NejXagqH7vj5536Miw5vU4eRv/6BU4weyOYWKZx9y hh+YrtzsbBhcbxe33j8ZGHbv3aeo7vJZanZ9qq8ptv4zP/rkhunRismqZIT7d1d1QKpRlAXqsuXj KfJZjPUxjPVKslnyvqCEFxQ0rdnFsGaGZQXmFAMig+oCzIdMhB3jaSa4oAZRDYtyxlcTTCd7I5mI Lsc8wOk5650YsN5K/vytZGMl90Il99UPJ7ivXr4s58Au9NG/xfzLTVrISWm3qt5Wz9gKwcICj9+u i80gNoPQfL6ZCTefaH68OdHMNUuiBFZjZbFDdIi2Qkeh2GsrNNsKxULBVhiyLduO29ZsHDKx5VSW 1oaMxURvKQ0RqvQLEqTyU9QsOh1NxW6L4qk09bwcyFGXS7I2aQaCirPDTZrDFAT1RpMRcAVawHon hbN33aY2hcGgYZL/ndVkCco/Qu5Algm4hufgZrX3tQZytNoubivVmt6/kFZbXlNtCaf2NHeXcleS g21bB2Zevknfji33T6G+Z2ZlXW5fu8pc5RuIg3xGcmGk1yryFUyOyWK0GHRGi6VXqzNrtTqtNqRd 1h7HRIR6jEtt6NZpjYLBUpCj1RWE2BxdyGAysBaDAeW24oSLTkhlr8aAgHnKFdk9hB/XoNJl3xDL dIJWK94pXGVW9FTASi0D2a76QH1AGVC6UIDWQqCRifGXjNY1jbeXaPmpR0qeeDDh/wfXj6c5FTA+ t63apdJmFTQMNngH8xn995LJ711729xorihXKkgmB0A7KiVflcZTOUCBrYCxGcGcA9ssVrM1pxef FqtVsFy0ALGctzCWcrEcF8MSQkpgW0mvu9TsLi0V3KUh97L7uHvNzbmtpBQUbp07x1pcUmLJyXGE dUIqD8CsN2BsbDQGUArBQCYbOOrxpLY519OAo7fmAHIme8uSf2tWAMxwiNNoNbcu9sm35bRgS28m LYBC/rXkvpxqf5XpltX+tqwA5ZGWDXsPxlQHmZFa0YQNBiVsU/aq9GaVXi+o9CHVsuq4ak3FqcKO cceK44SDczgVrFmZpzcoc9hwHp3zKSf4nDBGrWBEnn+QRkgaH4VXR26ePY2EiKXruyIT3TJzxoWf 3WytLb33pCua/M3XlTqtmgUdq1SpWa5oY09/jc5uz1Wxg7zm2eevJdkWV2dbk8XS3NJobtnZZGc5 nqExY/3a73iFrOsNqO0pbXV+NaOy2+yMRpWnYjS5eblMrp8U2Z1FBfYCZ29RgbmowFkgFF0sAlIE RUExCAvBlSBT0NR1QnNBc0nD+jRBTUizrDmu4TVFOQXgLwuESC5vEspCPF2+w0EYuT1ujFzBaPex ZC+1PqcXaDT4G3lPavoYKlJBI7WDKb0eK1yZAGJhrhRvHpxsDt83WKnWFUSOfG24Z1+vT8czOt0A 5Lyr1XPJ3wCn4N6tGwu3YNgYHfVt715vUqs3P+5r9+Y0TK72eaeDNGw41nWXm8Mt8MSH+Rvi61Ri ZU2eztn34HTlFufd+8XQ/dFAv3tvTLYRK8ZhL9dLGnHV/bS5ARQllhIm1wEaB+TmgTYPbEqwMMAz kN1FKsogvwzKQqXnShlSKuAGiC1tEprCTYzYJDUx/q7X7Rftv7ez9hx1iZpRU+s6pWJVFj9s90/5 mZxsGMyOZjPZfr2nr6xI0PepeYvUBP4mEJvgQhMkmiDcBHQ3ubSECRP6GoabRlxbFlHugZGfYpK5 hFkmppkj/5qOz/IF9AQBo3N9IRtInyKUVrGZTZNVmco5aYy2FrLsbzce+c7d//m35R9qitf3N1T3 NTnz6wcbQ/ePr+v9VGJq5AuzHVkfGncPenrrRXf7aH3n4R0B2Dp8/1DlZ75QXFznMhqctcViud2q M9Vs2b95x32hYnv7XJ+9o0VbUOUSPQ5rllDVszflf4of4v5EAiI9rgqCKgtUVlCvq6/vbWg0NzQ2 Cg2NDQ1Kj4LnFYpepcqsVKkE5YoSVEqlxe7KMZtz0sErB6OXYBFTBzRByznL7y1clsXKq8xso8Hj WsfWl9kLDEpLfQOnyCGGsL+Muu7VNhhvg9fbYL4NQm0gtoEBv4k28LcBPh9vA9IGZr/8Co6OyEcV i4upAwt5dQ/g8m4NBDHWWRuNqa3+6A27Ty2ZRgjYfL6bznpSiJuyAcoQim7EvDtvhKw3clZatQHc fIW3r9WXdSj59r2sgmf/qirc5stK7Y20uDcSFGo1xzpat4w1f+KEXuwc2NO6+vks1Ury7XtYhYJl 2U+U9c60Xvs6c69Q4nbqDpf37mu99uTNGybf5rqCQ4s1A0HX51aLd7gxjMYMJSXFev5wKjfKXXuH b+W/iNFml9RsXQf8OlCxIOxqzC2BEn8xCMVQjPEEvLvyLApQGHgfH+RD/DLP84KXlEUcnHaMZJMg LKX3vo0pM76yiEa8WJOxYR4jRWnJnU2Xv9l0ebpyMENHXzvWpwenpnLT3u7NyzsD7t75TaN/c2/3 jpM/OXTk5dVthuQly+cPtk1sLPKG5toC+yaH2tzhJ/5o9kdOjFevC9fl4cQbfG1+d3Zuy9iDk2Of nwxUD9+3eeOOfXlVktu7obLIpHd6NwzO98w8udScOg9gdmGOyJKfSTnyeQA7ycf5R3hW4oFJ8MDT TKLdXdk9xj/GMwI9CLvEX+XZZR4kPsyP8yzDEsAkMnVagDIkME4WyAnCZg4OEoS/hF1RRo1ub/cy AXraxhgIqLGBfIKQyBywrfCwQDmDnwdBPm9rTtUtLY1ejwmpAzda9tDTqduDNaRsfHFsaanaPyaf vBWDEUqT7/JHPliW9b/2FOYWZ7n1RAs+aVGtydUwCqVFyaROVakYlEqVRqPWKrQcboyBITzRaLQA hFFjlYLjeFbF7lVBXAVmVbGKeUUF9ypOKph8hUfBKESxpLtYAVEG7mUgn/EwzI8YiJNHCGNGiTOE bivHkaac/hdhm0Kr2MITM88TFWxD/ltZ9H0VH2RD7Cm09QUtaENqwK+gHsfQm4U6YkmOAhdY3hDO AikL/FkgZsG4/CRy8UQWyKGWBlxCHd1aAzS8LtKF/dWjnqOeV47aBPrCVXBxiWbFmXe1XziqOq86 //EnFeyIkwWnGpzZ9Mm8+VLyxeQb8FHybSh+BsqgNmkHNywnjzA1jCr5N7Dz2h+uvUH97Wnci/wa 7Uwg35C02Rg+A4R1yUbxs+dc7m76lkZMOd0oDoPaMCoQs4CGBNtYNTvCgJlBSaofUjMeNXBqMwpB bWB8TJAJMcsMz5wTQBAuCJcEVjChSZkEhg2ZQDRB0ASCCc6ZYMxElx60Cgx8mOWlMhyURGMuPeBM SyL9wkoP2lU53ecUgtVixYUe6sHJ/DL5zK+geolXsRxjMhu9NvgJ1PJHPjrkHS2tqij3usd87IMp n+L24Vx5MiStk42JU4pKuMVP7nCqBiybOk4LK9OZyY3TtOumjUnoqxhZ0KZTR2hQ+mvmPS9/5MMJ ee+19lOUc0De85nJt6VDf8d/l3+NZzfxO/i9PMvbTPbuCn49z5jRTEg2w2axCtiG4IhSYUaz5lHg WewEx5vRwB/JAm1WfpYni83KEjjgBCUoLcxYdjbPEVMWzy5YQLKAaIGrFgjJMLHABQucs8jLPPVB Wdw19GAwk1PKAr9V3nQrkdlOoNxxYpgzo31hqMQck3Vyhvprv3k5+d/YbNj1brKXUaD35eSL+jfh IZhOfpn6NKcxeH3lGl11s5SfXMqcc/47yiGbXJW+qBJsAqPR5mkZhcaiYVRqmzr10wlLcHuk22bU gFKh26Y0ZWeP0kNDgZ4Z3is8JJwUfid8KPCi4BcYRhAkNDL2ggAhtLcchVI5qlJjrqYWVH6VpAqr WAMm3TQpUldqwQWAmzSBU6lVymwMchqjCW0ZtbuSAxI9+oCRJboOy65JF2B61Hbr4Sk9NBpbXKSn 7+YyHJJgvsNOzHP0ldQDxTcmR0cn4I6WHkJg3JNNN9sJbDy5qlDweuWzyQ/ABKNwGEsG9bOgSL7L 7fNUFPe7PvprtKKHSj0lO6vYAxgm6b9pQPlsY+d3Xx0zNL9PHKn/5/xg8OkXMv8LWXsqeZfih/Iv LSqMaqkL2ylbklvJxut/H5m87R9Fucw7pJ3/ASlmGomL+xUZ5GIkyG8nxQi7KIy3hvvV2htY/izF IR1hvkW2U5i1y23WI41ViTC2y8X6Yi629hTCT2NdMf8D9INiua9K8h/BAv+VCTNPsrVsglvlO/lP Kirx85SyVvmoqlP1nvpNzZDmTe3DOkYn6V7JmkrNgeRR5ySpX/UE4iM7cMc1wuOyJtcWwHaS+b+R lG5BnwYipWGGaEkoDbPEje1TMEfyyUoa5omOnEzDCpJLvpGGleQecj4Nq4gZ1qdhNdHD1jSsxTHs uv5Ptiq4Ow1nkWV4Kg3riYcpoSPm1FhaYcJpGEghcyENM8TCvJuGWbKZ5dIwR9axGXqe2NhPp2EF qWG/loaV5D02w0dFyrhX0rCaFHDvpGEtaeBVaVhHdvFSGs4iSf7RNKwn2xVfaZ/ZMxOfuSc6KU5G 4hHxm2KN318vtsYmonOT0SVx4/zSwvxSJD4zP1clts7Oiksze6bjMXEpGosuHYxOVm2e2R1N1Yv9 kblY2/zspNgTj8zOTFzn4RVvIxJvovozVdujSzGKr67yB26QUSovpfpY+5mYGBHjS5HJ6P7I0j5x fkrchtPqjsQrxZ65iSoc856ZWDy6hMiZOXGwqr9KDEfi0bm4GJmbFAeuNwxNTc1MRGXkRHQpHkHi +fg0TmTvgaWZ2OTMBO0tVnUnGfXHowej4pZIPB6Nzc9Nx+ML632+Q4cOVUXSxBNIWzUxv9/35+ri hxeik9HYzJ45lEDVdHz/7GAsSucTn8Y53jTjqXkcfGx+Kn4oshSl848d2L03OhEX4/NIGxVRPtE5 bBrZsxSN7qczPSCP+ND0zMS0eHj+gBiZmIguxFEilPxPca76c4Odvd5IHilpJzNkD95xvO8hUYxD It4RLEcQ+ibeNbgI+0k9Qq0kRiaQZg4pomQJMRvJPL4X5GdE5jGPtVUy7Sx+RMRT/tNYF5NLUXzT tgflvqrIZqzfLWNutBdJP5bmkLINy7PymHrkEc0ixcQdxuHF+89zEv8Er7+s1Xa5Rew6fTXOxI/p 2p24ZXh5r/P63/c/I/dNNRCXa+g89+N7iexD3DyZwue2tLa65ZaV8gjnkGNVWs57ZC5xmXeKckbm PYgU/TJVWG5J5RiXe5uTqQbu0GMIe5ySxxu9iXJC5k3nkuI8j/B0WiN7yQFZ9zGkpO0yc4thz/+n dtQvj+6g3OcWGR+X7YfWTculBbIeVx0fOSR/qpDmVs4Tab5VMrQfKf/SdnFyGMtRuT4m2/Rc2gaq ZJ77UZ+Dsm1n9ENlkdLjnXU8Jb+p5GNyiziOJCLrKqP/GMpwN0oyKsuPcpxP86U0s2l9zKV7jeCY aGuqt4xOD9wk40PyeCbwKeJc5rGOtpmQeSzIkp28ifv/7Zir/mLJzt6hpxsypXkBWXsP71LyT+QO 1zkSBiUu1j75eQo4qQYuXINz10C4BvMfgvQhrLwP5ApIv4O3LouOX1/e4Pi3SzmOX17a4Li44V8G /3UDO/gvZ8F6ptnha9WCFZkI+BTxlvBm186DVXLkFnT+gl1z/PDlNYf/Zfhel8nxUmjS8eL4muPs 8xaHcBbypXwQ/x6Eb4vflr7Njj+/8PzK86zhzNgZ5jTb7DgLZmnt2RpH4ltrDt9zwedCz7HHnwPp OXd5p+OU71Tw1GOnOMMpkE7pLZ2PPQvPINnT36pzfCvsdnztZKnjqydLHI/iTU6On2RWTl49yTzW u+YwPOJ4hDE86HiQ+fwJt+Nzn3U7jj/sdnwGb8MxxzFm7Nj8seVja8c46Vi2tdPwMNzfVeN47FNw ZP+aYwXnchCZH8A7jncMb9/h4OHQYXZx3uFY6DI45rsKHXlgG8wN2AaVAXZQgU2+sR/K98MsQhFs MD5W4xjD90RXgSN399u7GXG3KaezfHfj7p7d7GhXvmNk55pj186AYyd2bAap1TSYXWMa5IEd5GrY wXkWDGyQZb44DGP9IPWXVXZK/YVF+Mi2dW7rK3P0hQocYbxzQ+UhZjg0E2LOguU5HNaBlyCH3A85 0gYmvBUe35LYcn4Lu6XL7NiMHfXivanL4VjrgR6cRjcWSRdYanIGjWAYFGoMgwyQQSCoOTCeyc/F lyBtwLeAKmSEfDHfn7+QzzkMQcOYYdnAGQw+Q8gwbzhuuGhYMyhT2N8buHkCYwRWLMDDWThxeqDf 4+k9q1zb1ptQhncm4IFEST99Sn07EooHEmRwx86h0wCfGb7/2DHSZu9N1PQPJcbtw72JSQQkCqwg INhPW0jbcCweix+IxT2pCxCIewhC8VjMk0HHIEZiB+R6uS7mSVUgiYxDZCzdPuYhWHsgXSszkOvj FJaLyAy5xeSKuMztQIbIQ/tJXUgUs6HP/S+gWEFXCmVuZHN0cmVhbQplbmRvYmoKCjI5IDAgb2Jq Cjg1NjQKZW5kb2JqCgozMCAwIG9iago8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL0ZB QUFBQStMaWJlcmF0aW9uU2Fucy1Cb2xkSXRhbGljCi9GbGFncyA2OAovRm9udEJCb3hbLTIwOCAt MzAzIDExMjcgMTAyOV0vSXRhbGljQW5nbGUgLTMwCi9Bc2NlbnQgOTA1Ci9EZXNjZW50IC0yMTEK L0NhcEhlaWdodCAxMDI5Ci9TdGVtViA4MAovRm9udEZpbGUyIDI4IDAgUj4+CmVuZG9iagoKMzEg MCBvYmoKPDwvTGVuZ3RoIDMzNy9GaWx0ZXIvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJxdks9ugzAM xu88RY7doYJQKK2EkDraShz2R2N7AJqYLtIIUaAH3n6x3W3SDkS/2J+TDztx3Rwba+b41Y+qhVn0 xmoP03jzCsQFrsZGMhXaqPm+o1UNnYviUNsu0wxDY/uxLKP4LeSm2S9iddDjBR6i+MVr8MZexeqj bsO+vTn3BQPYWSRRVQkNfTjnqXPP3QAxVa0bHdJmXtah5E/wvjgQKe0lW1Gjhsl1CnxnrxCVSVKJ 8nyuIrD6Xy7NueTSq8/OB6kM0iTJ0ipwSrytkTfERY6ccZw4Zz3xluMn5IJ5g7xjlsh7PidBPhDn GfIja+jemjglzZH1pDmxZod85jjqZcJx1Ej2X+C98u7/iMz+c4qz/2yPzP4LPFOy/3yLzP4z/HfJ /jP0L9l/dqJm3ruGbcW5/4xLqJv3YVT0OGhGOB1j4ff9uNFhFX3fjDqliQplbmRzdHJlYW0KZW5k b2JqCgozMiAwIG9iago8PC9UeXBlL0ZvbnQvU3VidHlwZS9UcnVlVHlwZS9CYXNlRm9udC9GQUFB QUErTGliZXJhdGlvblNhbnMtQm9sZEl0YWxpYwovRmlyc3RDaGFyIDAKL0xhc3RDaGFyIDI1Ci9X aWR0aHNbMzY1IDcyMiAyNzcgNjEwIDU1NiA2NjYgNjEwIDU1NiA1NTYgNjEwIDYxMCA2MTAgMjc3 IDMzMyA2MTAgMzg5CjYxMCA1NTYgODg5IDY2NiAyNzcgNTU2IDY2NiA2MTAgNzIyIDcyMiBdCi9G b250RGVzY3JpcHRvciAzMCAwIFIKL1RvVW5pY29kZSAzMSAwIFIKPj4KZW5kb2JqCgozMyAwIG9i ago8PC9MZW5ndGggMzQgMCBSL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGgxIDU3MTY+PgpzdHJl YW0KeJzlV31sU9cVP/c9f5FA7FDKUrnF13uEJnNiB9IPYGkxie0kBBbnw8wOHfjFfolNE9vyewmF DZG1aosMtKzTaFmZ2F9bu3biGbYpTKyk2qZq0qpuf0xT12aNtP43MhgrldYWsnOvn0PCQrtV+2/P fte/8zsf95xz77OvtfyYAsthAkTwJ0bl3CpCAK/fApCViXGNzm096kI8AyCsGsoNj9Y1v/M3APED AKt5eGT/0C//8MN6gIpP0CeaUuRk3T8v1QFU9qP8QAqJjhv7rSgfRXltalR7LACXTCjrKNtGsgm5 ARoQVk7iYBmVH8uploNMP4Uyzcijime97TmUcX7rdC6raklYOwdwB9fn8kru2sDzNpRZfhpyBHj6 WBEQC5f/zy/zMbgTOswPgR1yfFx0ia/CXexz7tLi8cb2uY/+l1nYSh8vwA/gJ3AM3oavGYoQhCEN Y8gsvF6H3yPLrjAMwI+gcJuwr8Ik6kt2cXgWTt7GLgzPwzl4Y9EsYRiFr2MuP4W3yXr4DW6VLFwl Nvgm/BqjXkVux1KhhCochjgcWsC+Ay8KR2Cb8D4KJ5lG8AkO+BWcIrsxsoZ1HpuvuOXfgj4NB3Hs gxSMI+aX+aFP/gTL5v6BVR2EbfA4bIWRBR4XyGmxAtevH05jT1/nnK+stHaIe4WfCcL1b6PwLRjG WyZYu3BM3AoBc7U/GItG+vt6e8LdX9mxvWtbZ0d7KBhoa93q3/LwQy1f3rxp44MP3L++yedtbKi7 d13tWumLblfNqmqHvWpFZcUym9ViNokCgYagFIpTfV1cN62TOjoamSzJSMgLiLhOkQotttFpnJvR xZZ+tBy6xdJfsvTPWxIHbYGWxgYalKj+ZkCik2SgJ4r4WECKUX2W4x0cm9ZxYQUKbjd60GBNKkB1 EqdBPTSeKgTjAYxXrKxok9qUisYGKFZUIqxEpNdJuSKpe5hwINQFNxcFsK1g0+pibVBO6uGeaDDg dLtjjQ2depUU4Cpo4yF1S5tu5SFpmqUOR2ixYapwdNIBg3HP8qSUlB+J6qKMvgUxWCg8rVd79Hop oNcfeL8GK1f0BikQ1D0salfv/DxdN6ckurnWIdHCNcBypNlLixnZYCy1jmvAYAjbWyiEJBoqxAvy 5NzEoEQdUqG4fHkhF8QOQziKXpNzPz/i1ENHY7ojniKbjWJDvV36HT27orpQG6IpGRl8b5HcG53u 6ljZJnw7NWAjsB3YU7ebFX5k0g+DKOgTPdGSTGHQeRb8Pk9MF+JMM1XW3BlhmomyZt49LuFqdvVF C7qptjMpBbHHR2R9YhD30162FJJDr/rQ6ZYKK6vpJl+M21LMqjOZprp5HbYFvRY64E5hLgUHF6o+ LH3MOnGCddUr6SYJw7A4QSkYN97jqRoMQBsb9A5Paen7o7o/gMAvG2sULDb50EOO4xKlA3z5dJ+U 01dJrfPrydIKpvui3MVw01e16RBPGF66LxhgM9NgIR4opcBiST3R89A8N1O8jzrPNcN9EAsw49Vt uK/WBQvR5JDuijuT+KQN0ajTrftjuMAxKarE2EbDDtXP4HRuPqMutPVHu/qkrp6B6EYjkZKChTPV Bm8JI0WdpTC45XRbrY1GBacYQ0MHEjSEQGptwVG31trwdmDDOcu2amsLjRInlK0xDb2eBpWAYcfk RUHNbDu1dZSjWZiIcdo6nO6Yu3Q1NgiopsbE6GFjTe0oq8Ra/CZATsAwnGK9rGF7nkYlRYpJKar7 w1FWG2sP77LRDN5zY636F0kLmoVtAjeqywJrph7yOBc2V2/n8rzYcYu6s6ymBZvU1VdgwSUjIGDm nTqwLezfWO3kTz97nqWQjA8xPtH8eS4U/X72LKfYY1uQOpMFqS/awq3xG+Sg8wCbayV0ka7+1sYG /DJrLUrkcE/RTw73DUTPO/A4dbg/elYgQlu8NVZci7roeQrg56zAWEYygTKBRepFwcbtnef9ABNc a+IElxOTBDhnK3MEEpNCiXOUOQE5U4nzc45duEo1Kewxfn8HaZKtzzdiqUI8xvY4rMaO4JvoRHoY uyM9XCSCZbleISmteqXUyvgtjN9S4i2Mt+LOIKtJY8OBgiMoXatp5D/bEMAhaY7g6dcK3iIBX8tZ q8k2u6FoMb/bclYUEEJRZLSZ0WetlmWftJwljG+udlfXuqvdAYHeWEteuJEyRz56JWB6E0qnTmJe 0/7hY/v32Fuugat0/nkj8srkorMEm5kdjgSDQD+r+0YQvjpvcuv5VRAuQcAwLx2dCa+jHEMAB54D 8ExkqrRswqqY9m6ycz6Ofz4mQUu/gQWsPmxgEZw4fwmb0CZvYDOeqR83sAXPkc8Y2AoH4HsGtsEq 8gUDL4Mq4jFwJeawaf5k7iURA6+AQ+QJA1eBRxBYxqZlKE0IjQYmQIUfG1iAKuFNA4vwAJ66StgE VKw2sBlqxPUGtsAasdPAVvhAHDawDepMuwy8DO42PWHgSthoOm3g5fCI6Y8GXgE3zM0GroKdlvWB 9HBaSx9QkjQpazJ9mW5oanqQblUTSiap5GlbNp/L5mUtnc146daREZpPD6c0leYVVcmPK0nv9vSg UtLTPiWfHupVhsdG5Px8gEZ6q8Wt8k4lrzJhvbdpw03draZpFU9fWl5OKqNy/lGaHaK9mHOHrDXQ zkzCiwkNp1VNySOZztCIt89Lw7KmZDQqZ5K0f96xe2gonVA4mVDymozGWS2Fie4dy6fVZDrBZlO9 SzWgT1PGFbpD1jRFzWZSmpbb7PPt27fPKxvGCbT1JrKjvk/TaftzSlJR08MZrNub0kZHIqrC6tFS WOOCioeymLyaHdL2yXmF1a+ODe5VEhrVsmir0BGsI4Ou8nBeUUZZpWM8432pdCJF92fHqJxIKDkN O8LMbxfZ+2nJjsw78UzxSyaNh/A0aHgfAAWSQPGWUZYRvYz3BmjC14OItoIKCbTJoIWCDx+FNsji Z46PMo+RRa2X247giyLP4qdQp3JJwU/mO87n8sJ21A9y5qY/xb8bCvccgl5Ew/gnbAT1+SUyaMT7 s2J8ln4nR+q8Zj3m1YR1L+X3WVHTvE7WO41rWJ6jPPdHkcuiH+U1sT53cM8GRJ3om+B9y/N6WRSN xy5ZpnnsCFr0casw92R90PhsGW7Vv8SM3TjjEPqzrt20TPDYbI1LkbOIU0ZH92K38zyDJPcr16bi zP/pDujj2Y3zOXdwXuMrz3QpLuVgM/4Y+GAff3nRZnHkhBHXy9EoWn5ePw32o6xwvcp3Y8ZYby+P OYp7K8J3ZXl9WC9K67j0Gg/xT9Z5lXtomInM16q8/ir2cBA7qfD+sYhZIy6zGTHWI2PMKmNOzJut W3lNxxb0eB/PJ4EjxVqyqGM+CR4jxzubXBD9v83Z+7k7O7LETDd7yn+v+TXnxhBLXMVl8deIFX9F t/DxIjH5Y2TmOnnrOqHXyaGPSfhjMnH1+FXh71fqXWeuXLwidF/ec/nMZbHpMrFfJjaYdcyGZ+Oz udnvz1oq7JfIcvgrqf7LzEbXe83TkT83vxuBadISnp6Y1qfFybkp/8C0rTI0TcTIu+Jql2OKTjVN 5aYmpn43NTN1Zco28drx14RfXPC57BdcFwTXue5zh86J8ZeI/SXXS0L4xfiLwvFTxH7Kdcp3Svzu Sa/rZPsa1/Mn7nXNnLhyQmDh7z+xojq05zvk0HPPPifknpp46vhT4sSTx58UzoxfHBfUcL0rm/G4 Mu1fct3VXBOxNosRizjnYp6Bwdq6UHyP37UHjXYNNLkG2utddzSvjJgxWRMa2kWXuEXsFrPis+JF 0WrrDa9x9eA9E74SFuzdrm5fN1Y445e73BhoW27bxDaxM1Tv6mjf6LK3u9p97W+1v9d+ud2yp52c xnfoTOhiSPSH6n0hf2iNO3R3hzOyuvnOiKPZHhEIREgzRHz2Obtgt++xH7KLdtgCwsRqYiaT5Hix v8/j6Zq0zuG/b1t4l04O67V9bPT3DOiWwzpEBnZFi4Q8E3vy2DFovadL39AX1eP3xLr0JAI/AxMI HPcUV0NrTFU1D7uIx4NwDEfwjCG1Wy2R4CmrwaMSVQVVJR6m4xAZUD2MZgzzIei5WwU2MK2HWzGk qjW7/wV9RBAnCmVuZHN0cmVhbQplbmRvYmoKCjM0IDAgb2JqCjMwODQKZW5kb2JqCgozNSAwIG9i ago8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL0JBQUFBQStMaWJlcmF0aW9uU2VyaWYK L0ZsYWdzIDQKL0ZvbnRCQm94Wy0xNzYgLTMwMyAxMDA1IDk4MV0vSXRhbGljQW5nbGUgMAovQXNj ZW50IDg5MQovRGVzY2VudCAtMjE2Ci9DYXBIZWlnaHQgOTgxCi9TdGVtViA4MAovRm9udEZpbGUy IDMzIDAgUj4+CmVuZG9iagoKMzYgMCBvYmoKPDwvTGVuZ3RoIDIyMS9GaWx0ZXIvRmxhdGVEZWNv ZGU+PgpzdHJlYW0KeJxdkEFPxCAQhe/8ijnuHjbQnpsmZs0mPegaqz+AwrSS2IFM6aH/3ilWTTxA 8njvgzfoa/fYUcj6haPrMcMYyDMucWWHMOAUSFU1+ODyocruZpuUFrbfloxzR2NsGqVfxVsyb3B6 8HHAs9J39siBJji9X3vR/ZrSJ85IGYxqW/A4yj1PNj3bGXWhLp0XO+TtIshf4G1LCHXR1XcVFz0u yTpkSxOqxpgWmtutVUj+n3cQw+g+LEuykqQxtSnZ43Sn9rF+2oBbmaVJmb1U2B8PhL/fk2LaqbK+ AH1ZbXUKZW5kc3RyZWFtCmVuZG9iagoKMzcgMCBvYmoKPDwvVHlwZS9Gb250L1N1YnR5cGUvVHJ1 ZVR5cGUvQmFzZUZvbnQvQkFBQUFBK0xpYmVyYXRpb25TZXJpZgovRmlyc3RDaGFyIDAKL0xhc3RD aGFyIDEKL1dpZHRoc1szNjUgMjUwIF0KL0ZvbnREZXNjcmlwdG9yIDM1IDAgUgovVG9Vbmljb2Rl IDM2IDAgUgo+PgplbmRvYmoKCjM4IDAgb2JqCjw8L0YxIDM3IDAgUi9GMiAxNyAwIFIvRjMgMjcg MCBSL0Y0IDEyIDAgUi9GNSAzMiAwIFIvRjYgMjIgMCBSCj4+CmVuZG9iagoKMzkgMCBvYmoKPDwv Rm9udCAzOCAwIFIKL1Byb2NTZXRbL1BERi9UZXh0XQo+PgplbmRvYmoKCjEgMCBvYmoKPDwvVHlw ZS9QYWdlL1BhcmVudCA3IDAgUi9SZXNvdXJjZXMgMzkgMCBSL01lZGlhQm94WzAgMCA3OTQgNTk1 XS9Hcm91cDw8L1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQi9JIHRydWU+Pi9Db250ZW50cyAy IDAgUj4+CmVuZG9iagoKNCAwIG9iago8PC9UeXBlL1BhZ2UvUGFyZW50IDcgMCBSL1Jlc291cmNl cyAzOSAwIFIvTWVkaWFCb3hbMCAwIDc5NCA1OTVdL0dyb3VwPDwvUy9UcmFuc3BhcmVuY3kvQ1Mv RGV2aWNlUkdCL0kgdHJ1ZT4+L0NvbnRlbnRzIDUgMCBSPj4KZW5kb2JqCgo0MCAwIG9iago8PC9D b3VudCAyL0ZpcnN0IDQxIDAgUi9MYXN0IDQyIDAgUgo+PgplbmRvYmoKCjQxIDAgb2JqCjw8L0Nv dW50IDAvVGl0bGU8RkVGRjAwNTMwMDZDMDA2OTAwNjQwMDY1MDAyMDAwMzE+Ci9EZXN0WzEgMCBS L1hZWiAwIDU5NSAwXS9QYXJlbnQgNDAgMCBSL05leHQgNDIgMCBSPj4KZW5kb2JqCgo0MiAwIG9i ago8PC9Db3VudCAwL1RpdGxlPEZFRkYwMDUzMDA2QzAwNjkwMDY0MDA2NTAwMjAwMDMyPgovRGVz dFs0IDAgUi9YWVogMCA1OTUgMF0vUGFyZW50IDQwIDAgUi9QcmV2IDQxIDAgUj4+CmVuZG9iagoK NyAwIG9iago8PC9UeXBlL1BhZ2VzCi9SZXNvdXJjZXMgMzkgMCBSCi9NZWRpYUJveFsgMCAwIDc5 NCA1OTUgXQovS2lkc1sgMSAwIFIgNCAwIFIgXQovQ291bnQgMj4+CmVuZG9iagoKNDMgMCBvYmoK PDwvVHlwZS9DYXRhbG9nL1BhZ2VzIDcgMCBSCi9PcGVuQWN0aW9uWzEgMCBSIC9GaXRIIDg0Ml0K L1ZpZXdlclByZWZlcmVuY2VzPDwvRml0V2luZG93IHRydWUKPj4KL091dGxpbmVzIDQwIDAgUgo+ PgplbmRvYmoKCjQ0IDAgb2JqCjw8L0F1dGhvcjxGRUZGMDA0QTAwNDgwMDUzMDAyMD4KL0NyZWF0 b3I8RkVGRjAwNDkwMDZEMDA3MDAwNzIwMDY1MDA3MzAwNzM+Ci9Qcm9kdWNlcjxGRUZGMDA0RjAw NzAwMDY1MDA2RTAwNEYwMDY2MDA2NjAwNjkwMDYzMDA2NTAwMkUwMDZGMDA3MjAwNjcwMDIwMDAz MzAwMkUwMDMyPgovQ3JlYXRpb25EYXRlKEQ6MjAxMTA0MTAxMDE2MDQtMDQnMDAnKT4+CmVuZG9i agoKeHJlZgowIDQ1CjAwMDAwMDAwMDAgNjU1MzUgZiAKMDAwMDA1MTk3MCAwMDAwMCBuIAowMDAw MDAwMDE5IDAwMDAwIG4gCjAwMDAwMDE0ODUgMDAwMDAgbiAKMDAwMDA1MjExMyAwMDAwMCBuIAow MDAwMDAxNTA2IDAwMDAwIG4gCjAwMDAwMDM1MzMgMDAwMDAgbiAKMDAwMDA1MjU1NCAwMDAwMCBu IAowMDAwMDAzNTU0IDAwMDAwIG4gCjAwMDAwMDUwMDIgMDAwMDAgbiAKMDAwMDAwNTAyMyAwMDAw MCBuIAowMDAwMDA1MjEzIDAwMDAwIG4gCjAwMDAwMDU1MDUgMDAwMDAgbiAKMDAwMDAwNTY2NiAw MDAwMCBuIAowMDAwMDIwMjY4IDAwMDAwIG4gCjAwMDAwMjAyOTEgMDAwMDAgbiAKMDAwMDAyMDQ4 NiAwMDAwMCBuIAowMDAwMDIxMDE2IDAwMDAwIG4gCjAwMDAwMjEzOTAgMDAwMDAgbiAKMDAwMDAy OTkwMSAwMDAwMCBuIAowMDAwMDI5OTIzIDAwMDAwIG4gCjAwMDAwMzAxMzAgMDAwMDAgbiAKMDAw MDAzMDUyNiAwMDAwMCBuIAowMDAwMDMwNzg3IDAwMDAwIG4gCjAwMDAwMzc1OTYgMDAwMDAgbiAK MDAwMDAzNzYxOCAwMDAwMCBuIAowMDAwMDM3ODIwIDAwMDAwIG4gCjAwMDAwMzgxODggMDAwMDAg biAKMDAwMDAzODQyMyAwMDAwMCBuIAowMDAwMDQ3MDc0IDAwMDAwIG4gCjAwMDAwNDcwOTYgMDAw MDAgbiAKMDAwMDA0NzMwNyAwMDAwMCBuIAowMDAwMDQ3NzE0IDAwMDAwIG4gCjAwMDAwNDc5ODcg MDAwMDAgbiAKMDAwMDA1MTE1NyAwMDAwMCBuIAowMDAwMDUxMTc5IDAwMDAwIG4gCjAwMDAwNTEz NzUgMDAwMDAgbiAKMDAwMDA1MTY2NiAwMDAwMCBuIAowMDAwMDUxODMyIDAwMDAwIG4gCjAwMDAw NTE5MTUgMDAwMDAgbiAKMDAwMDA1MjI1NiAwMDAwMCBuIAowMDAwMDUyMzEyIDAwMDAwIG4gCjAw MDAwNTI0MzMgMDAwMDAgbiAKMDAwMDA1MjY1OSAwMDAwMCBuIAowMDAwMDUyNzkyIDAwMDAwIG4g CnRyYWlsZXIKPDwvU2l6ZSA0NS9Sb290IDQzIDAgUgovSW5mbyA0NCAwIFIKL0lEIFsgPDJEQzdC QTE3MkQyRkVGMEIxQzlDQUE3MTBFMkM3MDZEPgo8MkRDN0JBMTcyRDJGRUYwQjFDOUNBQTcxMEUy QzcwNkQ+IF0KL0RvY0NoZWNrc3VtIC80QzQ1RjU3RkM1OUFBQjFGMThFQjc2MUU2RDRDMTMzNgo+ PgpzdGFydHhyZWYKNTMwMTMKJSVFT0YK --20cf307f344a6b4f9404a0911d10-- From wmwang2001@hotmail.com Mon Apr 11 06:02:06 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 1D5E428C122 for ; Mon, 11 Apr 2011 06:02:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.883 X-Spam-Level: X-Spam-Status: No, score=-98.883 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FORGED_MUA_OUTLOOK=3.116, J_CHICKENPOX_21=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 4OH-MQbymVX6 for ; Mon, 11 Apr 2011 06:02:05 -0700 (PDT) Received: from blu0-omc2-s29.blu0.hotmail.com (blu0-omc2-s29.blu0.hotmail.com [65.55.111.104]) by core3.amsl.com (Postfix) with ESMTP id 0D0F928C11D for ; Mon, 11 Apr 2011 06:02:01 -0700 (PDT) Received: from BLU0-SMTP102 ([65.55.111.73]) by blu0-omc2-s29.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 11 Apr 2011 06:02:02 -0700 X-Originating-IP: [220.184.140.181] X-Originating-Email: [wmwang2001@hotmail.com] Message-ID: Received: from WmwangHome ([220.184.140.181]) by BLU0-SMTP102.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 11 Apr 2011 06:02:00 -0700 From: "Wang,Weiming" To: "Jamal Hadi Salim" References: Date: Mon, 11 Apr 2011 21:02:06 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" 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: 11 Apr 2011 13:02:01.0042 (UTC) FILETIME=[A5A29320:01CBF848] Cc: forces@ietf.org, 'Chuanhuang Li' , "Joel M. Halpern" Subject: Re: [forces] LFB LPM issue 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, 11 Apr 2011 13:02:06 -0000 SGkgSmFtYWwsICANCg0KVGhhbmtzIGZvciB0aGUgY29tbWVudHMuIFBscyBzZWUgaW5saW5lIG9m IHRleHRzIGNvcGllZCBmcm9tIHlvdXIgc2xpZGVzIGZvciB0aGUgcmVwbHkuICANCg0KSm9lbCBh bmQgQ2h1YW5odWFuZywgbWF5IEkgYWxzbyBoYXZlIHlvdXIgc29tZSBhdHRlbnRpb24gb24gdGhl IHJlcGx5IG9mIHNvbWUgaXNzdWUgaW5zaWRlPw0KDQp0aGFua3MgYSBsb3QuDQpXZWltaW5nDQoN Ci0tLS0tDQril48gTkggb3V0cHV0cyBhcyBwYXJ0IG9mIG1ldGFkYXRhIEVuY2FwT3V0cHV0SW5k ZXgNCiAgICDil49BbHJlYWR5IGF2YWlsYWJsZSwganVzdCBub3QgdXNlZCBjdXJyZW50bHkNClJl OiBpbiBjdXJyZW50IHZlcnNpb24gb2YgTkggTEZCLCB0aGUgRW5jYXBPdXRwdXRJbmRleCBpcyB1 c2VkIGJ5IHRoaXMgTkggTEZCIGl0c2VsZiB0byBzZWxlY3QgdGhlIG91dHB1dCBmcm9tIHRoZSBv dXRwdXQgZ3JvdXAuIEZvciBpbnN0YW5jZSwgaWYgdGhlIGdyb3VwIG91dHB1dCAxIGlzIGNvbm5l Y3RlZCB0byBhIGRvd25zdHJlYW0gRXRoZXJFbmNhcCBMRkIsIHRoZW4gdGhlIHBhY2tldHMgd2l0 aCB0aGUgRW5jYXBPdXRwdXRJbmRleCBhc3NpZ25lZCB0byAxIG1lYW5zIHRvIG91dHB1dCB0byBh biBFdGhlciBlbmNhcHN1bGF0b3IuIA0KDQpJJ20gbm90IHN1cmUgaWYgeW91IG1lYW4gdG8gZGVm aW5lICB0aGlzIEVuY2FwT3V0cHV0SW5kZXggYXMgYSBtZXRhZGF0YSAgb3V0cHV0IHZpYSB0aGUg Tkggb3V0cHV0IHBvcnQ/IGlmIHNvLCBob3cgY2FuIHdlIGRpc3Rpbmd1aXNoIGRpZmZlcmVudCBl bmNhcHN1bGF0b3JzIGZvbGxvd2VkLCBzYXlpbmcgd2UgaGF2ZSBvdGhlciBlbmNhcHN1bGF0aW9u cyBvdGhlciB0aGFuIEV0aGVybmV0IGZvbGxvd2VkLg0KDQril49BUlAvTkQgcmVzb2x1dGlvbiBy ZW1vdmVkDQpSZTogbm90IHN1cmUgdGhlIGRldGFpbHMsIHlvdSBtZWFuIHRoZSBBUlAvTkQgZnVu Y3Rpb24gd2lsbCBiZSBpbmNsdWRlZCBpbiB0aGUgRXRoZXJFbmNhcCBMRkI/DQoNCiAgICDil48g RXRoZXJFbmNhcCBpcyBub3QgYXdhcmUgb2YgSVBWNCBvciBWNg0KUmU6IFllcywgY3VycmVudCB2 ZXJzaW9uIG9mIEV0aGVyRW5jYXAgaW5jbHVkZXMgSVB2NCBhbmQgdjYuDQoNCiAgICAgICAgIOKX jyBVcCB0byBpbXBsZW1lbnRhdGlvbiBpZiBJUCBpcyBpZ25vcmVkIG9yIGhvdyBpdCBpcyB1c2Vk IChBUlAvTkQpDQpSZTogY291bGQgdGhpcyBiZSBkZXNjcmliZWQgIG1vcmU/IEkganVzdCBjYW4g bm90IGNhdGNoIHVwIHdlbGwgd2l0aCB3aGF0IGl0IG1lYW5zIGJlaGluZC4NCg0KICAgIOKXjyBO ZXcgRW5jYXBUYWJsZSBpbiBFdGhlckVuY2FwIExGQiBpbmRleGVkIGJ5IEVuY2FwT3V0cHV0SW5k ZXgNClJlOiBJIGp1c3QgY2FuIG5vdCB1bmRlcnN0YW5kIHdlbGwgaG93IGNhbiBFbmNhcE91dHB1 dEluZGV4IGJlIHVzZWQgYXMgaW5kZXggZm9yIHBhY2tldHMgdG8gZmluZCBvdXQgZW5jYXAgaW5m b3JtYXRpb24gZm9yIHRoZSBwYWNrZXRzPyAgQ291bGQgeW91IHByb3ZpZGUgbW9yZSBvbiB0aGlz PyB0aGFua3MuDQogICAgICAgIOKXjyBObyBJUCBpbmZvcm1hdGlvbiBzdG9yZWQNCiAgICAgICAg 4pePIE5vIExvZ2ljYWxQb3J0SUQsIHdlIGFscmVhZHkgaGF2ZSBvbmUgZnJvbSBOSA0KUmU6IElu IGN1cnJlbnQgRXRoZXJFbmNhcCBMRkIsIHdlJ3YgZGVmaW5lZCBhIFZMQU4gb3V0cHV0IHRhYmxl LCB3aGljaCBpcyB1c2VkIGZvciBhIHBhY2tldCB0byBmaW5kIG91dCBhbiBvdXRwdXQgbG9naWNh bCBwb3J0IElEIGFuZCBhIFZsYW5JRCBieSBhbiBpbnB1dCBsb2dpY2FsIHBvcnQgSUQgd2hpY2gg aXMgZnJvbSB1cHN0cmVhbSBOSCBMRkIuICBUaGlzIG1lYW5zLCB0aGUgbG9naWNhbCBwb3J0IElE IGdlbmVyYXRlZCBieSBOZXh0SG9wIHRhYmxlIGluIE5IIGlzIGRpZmZlcmVudCBmcm9tIHRoZSBs b2dpY2FsIHBvcnQgSUQgZ2VuZXJhdGVkIGJ5IHRoaXMgRXRoZXJFbmNhcCBMRkIuIA0KV2UgZGVz aWduZWQgdGhpcyBhZnRlciBzb21lIGRpc2N1c3Npb25zIGJldHdlZW4gSm9lbCBhbmQgQ2h1YW5o dWFuZy4gSSBob3BlIHlvdSB0d28gdHV5cyBjYW4gcHJvdmlkZSBtb3JlIGluZm9ybWF0aW9uIG9u IHRoaXMgZGVzaWduLiBUaGFua3MuDQoNCiAgICAgICAg4pePIFN0b3JlIGRzdG1hYyBhbmQgcG9z c2libHkgYSBFbmNhcFNyY0luZGV4DQogICAgICAgIOKXjyBGaW5kIHNyY21hYyBhbmQgVkxBTiBk ZXRhaWxzIHdpdGhpbiBFbmNhcFRhYmxlIGJ5IG9uZS1vZjoNCiAgICAgICAgICAgIOKXjyBVc2Ug c3RvcmVkIEVuY2FwU3JjSW5kZXggdG8gaW5kZXggYW5vdGhlciBzcmNFbmNhcCB0YWJsZQ0KICAg ICAgICAgICAg4pePIFN0b3JlIHNyY21hYyBhbmQgb3B0aW9uYWwgdmxhbiBpbmZvcm1hdGlvbiBp biBFbmNhcFRhYmxlDQpSZTogSSdtIHNvcnJ5IHRoYXQgSSBzdGlsbCBjYW4gbm90IGNhdGNoIHVw IGhlcmUgd2VsbC4gV2h5IGRvbid0IHdlIGp1c3QgZGVmaW5lIGEgdGFibGUgaW4gd2hpY2ggZHN0 bWFjIGFuZCBzcmNtYWMgYXJlIGluY2x1ZGVkLCBqdXN0IGFzIHRoZSBBcnBUYWJsZSBkb2VzIGlu ICBjdXJyZW50IHZlcnNpb24gRXRoZXJFbmNhcCBMRkI/IA0KLS0tLQ0KDQotLS0tLSBPcmlnaW5h bCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkphbWFsIEhhZGkgU2FsaW0iIGhhZGlAbW9qYXRhdHUu Y29tDQoNCj4gV2VpbWluZywNCj4gDQo+IEkgaGF2ZSBhdHRhY2hlZCBhIGNvdXBsZSBvZiBzbGlk ZXMgd2l0aG91dCBnb2luZyBpbnRvDQo+IHRoZSBsaXR0bGUgZGV0YWlscyBvZiB0aGUgTEZCcy4g U2xpZGUgMiBkZW1vbnN0cmF0ZXMgaSB0aGluaw0KPiB3aGF0IHdlIGFncmVlZCBvbiBhdCB0aGUg bWVldGluZy4NCj4gSSBob3BlIHlvdSBhbmQgdGhlIG90aGVyIGF1dGhvcnMgY2FuIHJldmlldyBh bmQgcmVzcG9uZC4gSQ0KPiBkbyBoYXZlIG1hbnkgb3RoZXIgY29tbWVudHMgb24gdGhlIGRvYyAt IG1vc3RseSBpbiByZWdhcmRzDQo+IHRvIHJlYWRhYmlsaXR5Lg0KPiANCj4gY2hlZXJzLA0KPiBq YW1hbA0KPg0KDQoNCg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiBmb3JjZXMgbWFpbGluZyBsaXN0DQo+IGZvcmNlc0BpZXRmLm9yZw0KPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ZvcmNlcw0KPg== From hadi@mojatatu.com Mon Apr 11 07:03: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 F2AC528B56A for ; Mon, 11 Apr 2011 07:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.836 X-Spam-Level: X-Spam-Status: No, score=-101.836 tagged_above=-999 required=5 tests=[AWL=-0.059, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_21=0.6, 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 nmfMebaxjgWq for ; Mon, 11 Apr 2011 07:03:20 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id B0D8F28C0D9 for ; Mon, 11 Apr 2011 07:03:20 -0700 (PDT) Received: by vws12 with SMTP id 12so5174516vws.31 for ; Mon, 11 Apr 2011 07:03:20 -0700 (PDT) Received: by 10.52.67.167 with SMTP id o7mr3342003vdt.240.1302530555166; Mon, 11 Apr 2011 07:02:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.181.8 with HTTP; Mon, 11 Apr 2011 07:02:15 -0700 (PDT) In-Reply-To: References: From: Jamal Hadi Salim Date: Mon, 11 Apr 2011 10:02:15 -0400 Message-ID: To: "Wang,Weiming" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: forces@ietf.org, Chuanhuang Li , "Joel M. Halpern" Subject: Re: [forces] LFB LPM issue 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, 11 Apr 2011 14:03:22 -0000 Hi Weiming, Comments below: On Mon, Apr 11, 2011 at 9:02 AM, Wang,Weiming wrot= e: > ----- > =E2=97=8F NH outputs as part of metadata EncapOutputIndex > =C2=A0 =C2=A0=E2=97=8FAlready available, just not used currently > Re: in current version of NH LFB, the EncapOutputIndex is used by this NH= LFB >itself to select the output from the output group. For instance, if t= he group output 1 is >connected to a downstream EtherEncap LFB, then the pa= ckets with the >EncapOutputIndex assigned to 1 means to output to an Ether = encapsulator. > > I'm not sure if you mean to define =C2=A0this EncapOutputIndex as a metad= ata =C2=A0output via >the NH output port? if so, how can we distinguish dif= ferent encapsulators followed, >saying we have other encapsulations other t= han Ethernet followed. > I misunderstood the meaning of that index because I dont think what you just described above is in the text of the draft. Am i mistaken? If i am not, then please add to the TODO list such an explanation. Also, maybe somewhere we need to say that the design choices of the LFBs is so that we can have genericity in Link layers (although we currently only focus on Ethernet) as evidenced by the presence of EncapOutputIndex. Having said that: What i meant is we need some index which is output as metadata from NH. The value of this metadata will be used to index into a table in the Ether encapsulator. I called it EncapOutputIndex but change its name to something else. For example, lets call it NHEncapInfoIndex > =E2=97=8FARP/ND resolution removed > Re: not sure the details, you mean the ARP/ND function will be included i= n the EtherEncap LFB? > > =C2=A0 =C2=A0=E2=97=8F EtherEncap is not aware of IPV4 or V6 > Re: Yes, current version of EtherEncap includes IPv4 and v6. > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=97=8F Up to implementation if IP is ignor= ed or how it is used (ARP/ND) > Re: could this be described =C2=A0more? I just can not catch up well with= what it means behind. > I meant we have only the useful encapsulation information for the nexthop link layer details - not how such information is gathered. This information is indexed by what i called NHEncapInfoIndex above. This will allow someone to install all the details of dstmac, srcmac and VL= AN info without needing for FE to be aware of ARP. Or if they decide to use ARP when the packet gets to that point, then they can choose to do so (even though i think that is a bad idea). > =C2=A0 =C2=A0=E2=97=8F New EncapTable in EtherEncap LFB indexed by EncapO= utputIndex > Re: I just can not understand well how can EncapOutputIndex be used as in= dex for >packets to find out encap information for the packets? =C2=A0Could= you provide more on >this? thanks. Table name: NHEncapTable Table index: NHEncapInfoIndex Table entries option 1: dstmac, srcmac, optional vlan information or Table entries option 1: dstmac, EncapSrcIndex and then use EncapSrcIndex to find srcmac and optional VLAN information. I hope this makes sense. > =C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=97=8F No IP information stored As evidence from above, you can see no IP information needed by ethernet encapsulator. NHIP is still passed as metadata - so if your implementation wants to do ARP or ND to populate dsmac address, they can do that. > =C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=97=8F No LogicalPortID, we already have on= e from NH > Re: In current EtherEncap LFB, we'v defined a VLAN output table, which is= used for >a packet to find out an output logical port ID and a VlanID by a= n input logical port ID >which is from upstream NH LFB. =C2=A0This means, t= he logical port ID generated by >NextHop table in NH is different from the = logical port ID generated by this >EtherEncap LFB. > We designed this after some discussions between Joel and Chuanhuang. I ho= pe you > two guys can provide more information on this design. Thanks. > I didnt quiet follow the reasoning. The route (LPM+NH) points to a logical port where the packet is to go out. = Does this mean some other policy downstream will make the decision to change thi= s? Joel/Chuanhuang? > =C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=97=8F Store dstmac and possibly a EncapSrc= Index > =C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=97=8F Find srcmac and VLAN details within = EncapTable by one-of: > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=97=8F Use stored EncapSrcInd= ex to index another srcEncap table > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=97=8F Store srcmac and optio= nal vlan information in EncapTable > Re: I'm sorry that I still can not catch up here well. Why don't we just = define a table >in which dstmac and srcmac are included, just as the ArpTab= le does in =C2=A0current >version EtherEncap LFB? We could. Using an index will use less memory - but we can optimize later. cheers, jamal From wmwang2001@hotmail.com Mon Apr 11 07:48: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 396BD3A6A1F for ; Mon, 11 Apr 2011 07:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.283 X-Spam-Level: X-Spam-Status: No, score=-98.283 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, FORGED_MUA_OUTLOOK=3.116, J_CHICKENPOX_21=0.6, J_CHICKENPOX_33=0.6, 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 TFcwdHu-SZ3R for ; Mon, 11 Apr 2011 07:48:20 -0700 (PDT) Received: from blu0-omc2-s14.blu0.hotmail.com (blu0-omc2-s14.blu0.hotmail.com [65.55.111.89]) by core3.amsl.com (Postfix) with ESMTP id 3A6DD3A69FF for ; Mon, 11 Apr 2011 07:48:20 -0700 (PDT) Received: from BLU0-SMTP142 ([65.55.111.72]) by blu0-omc2-s14.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 11 Apr 2011 07:48:20 -0700 X-Originating-IP: [220.184.140.181] X-Originating-Email: [wmwang2001@hotmail.com] Message-ID: Received: from WmwangHome ([220.184.140.181]) by BLU0-SMTP142.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 11 Apr 2011 07:48:18 -0700 From: "Wang,Weiming" To: "Jamal Hadi Salim" References: Date: Mon, 11 Apr 2011 22:48:22 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" 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: 11 Apr 2011 14:48:18.0723 (UTC) FILETIME=[7F077730:01CBF857] Cc: forces@ietf.org, Chuanhuang Li , "Joel M. Halpern" Subject: Re: [forces] LFB LPM issue 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, 11 Apr 2011 14:48:21 -0000 SGkgSmFtYWwsIG1vcmUgcmVwbHkgaW5saW5lLiANCg0KdGhhbmtzLA0KV2VpbWluZw0KLS0tLS0g T3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJKYW1hbCBIYWRpIFNhbGltIiA8aGFkaUBt b2phdGF0dS5jb20+DQo+PiAtLS0tLQ0KPj4g4pePIE5IIG91dHB1dHMgYXMgcGFydCBvZiBtZXRh ZGF0YSBFbmNhcE91dHB1dEluZGV4DQo+PiDil49BbHJlYWR5IGF2YWlsYWJsZSwganVzdCBub3Qg dXNlZCBjdXJyZW50bHkNCj4gDQo+PiBSZTogaW4gY3VycmVudCB2ZXJzaW9uIG9mIE5IIExGQiwg dGhlIEVuY2FwT3V0cHV0SW5kZXggaXMgdXNlZCBieSB0aGlzIE5IIExGQiA+aXRzZWxmIHRvIHNl bGVjdCB0aGUgb3V0cHV0IGZyb20gdGhlIG91dHB1dCBncm91cC4gRm9yIGluc3RhbmNlLCBpZiB0 aGUgZ3JvdXAgb3V0cHV0IDEgaXMgPmNvbm5lY3RlZCB0byBhIGRvd25zdHJlYW0gRXRoZXJFbmNh cCBMRkIsIHRoZW4gdGhlIHBhY2tldHMgd2l0aCB0aGUgPkVuY2FwT3V0cHV0SW5kZXggYXNzaWdu ZWQgdG8gMSBtZWFucyB0byBvdXRwdXQgdG8gYW4gRXRoZXIgZW5jYXBzdWxhdG9yLg0KPj4NCj4+ IEknbSBub3Qgc3VyZSBpZiB5b3UgbWVhbiB0byBkZWZpbmUgdGhpcyBFbmNhcE91dHB1dEluZGV4 IGFzIGEgbWV0YWRhdGEgb3V0cHV0IHZpYSA+dGhlIE5IIG91dHB1dCBwb3J0PyBpZiBzbywgaG93 IGNhbiB3ZSBkaXN0aW5ndWlzaCBkaWZmZXJlbnQgZW5jYXBzdWxhdG9ycyBmb2xsb3dlZCwgPnNh eWluZyB3ZSBoYXZlIG90aGVyIGVuY2Fwc3VsYXRpb25zIG90aGVyIHRoYW4gRXRoZXJuZXQgZm9s bG93ZWQuDQo+Pg0KPiANCj4gSSBtaXN1bmRlcnN0b29kIHRoZSBtZWFuaW5nIG9mIHRoYXQgaW5k ZXggYmVjYXVzZSBJIGRvbnQgdGhpbmsgd2hhdA0KPiB5b3UganVzdCBkZXNjcmliZWQgYWJvdmUg aXMgaW4gdGhlIHRleHQgb2YgdGhlIGRyYWZ0Lg0KPiBBbSBpIG1pc3Rha2VuPyBJZiBpIGFtIG5v dCwgdGhlbiBwbGVhc2UgYWRkIHRvIHRoZSBUT0RPIGxpc3QNCj4gc3VjaCBhbiBleHBsYW5hdGlv bi4gQWxzbywgbWF5YmUgc29tZXdoZXJlIHdlIG5lZWQgdG8gc2F5IHRoYXQNCj4gdGhlIGRlc2ln biBjaG9pY2VzIG9mIHRoZSBMRkJzIGlzIHNvIHRoYXQgd2UgY2FuIGhhdmUgZ2VuZXJpY2l0eSBp bg0KPiBMaW5rIGxheWVycyAoYWx0aG91Z2ggd2UgY3VycmVudGx5IG9ubHkgZm9jdXMgb24gRXRo ZXJuZXQpIGFzIGV2aWRlbmNlZA0KPiBieSB0aGUgcHJlc2VuY2Ugb2YgRW5jYXBPdXRwdXRJbmRl eC4NCg0KV1JlOiBKYW1hbCwgNS4zLjIuICBJUHY0TmV4dEhvcCBzZWN0aW9uIGhhcyBkZXNjcmli ZWQgdGhlIHVzZSBvZiB0aGUgSW5kZXgsIHBscyBjaGVjayBwLjUwIG9mIExGQiBsaWIgdjMsIGFs dGhvdWdoIG1vcmUgd29yZHMgbWF5IGJlIGFkZGVkIHRvIHN0YXRlIHRoZSBnZW5lcmljaXR5IGlu IGxpbmsgbGF5ZXJzLiANCg0KPiANCj4gSGF2aW5nIHNhaWQgdGhhdDoNCj4gV2hhdCBpIG1lYW50 IGlzIHdlIG5lZWQgc29tZSBpbmRleCB3aGljaCBpcyBvdXRwdXQgYXMgbWV0YWRhdGEgZnJvbSBO SC4NCj4gVGhlIHZhbHVlIG9mIHRoaXMgbWV0YWRhdGEgd2lsbCBiZSB1c2VkIHRvIGluZGV4IGlu dG8gYSB0YWJsZSBpbiB0aGUNCj4gRXRoZXIgZW5jYXBzdWxhdG9yLiBJIGNhbGxlZCBpdCBFbmNh cE91dHB1dEluZGV4IGJ1dCBjaGFuZ2UgaXRzDQo+IG5hbWUgdG8gc29tZXRoaW5nIGVsc2UuIEZv ciBleGFtcGxlLCBsZXRzIGNhbGwgaXQgTkhFbmNhcEluZm9JbmRleA0KV1JlOiBjdXJyZW50bHkg d2UgaGF2ZSB1c2VkIHRoZSBsb2dpY2FsIHBvcnQgSUQgYXMgdGhlIG1ldGFkYXRhIG91dHB1dCBi eSB0aGUgTkggTEZCIHRvIGluZGV4IHRoZSB0YWJsZSBpbiBFdGhlcmVuY2FwIExGQi4gSSdtIG5v dCBzdXJlIGlmIHlvdSBtZWFuIHRoaXMga2luZCBvZiBpbmRleCwgb3IgdG90YWxseSBvdGhlciBv bmU/IA0KDQo+IA0KPj4g4pePQVJQL05EIHJlc29sdXRpb24gcmVtb3ZlZA0KPj4gUmU6IG5vdCBz dXJlIHRoZSBkZXRhaWxzLCB5b3UgbWVhbiB0aGUgQVJQL05EIGZ1bmN0aW9uIHdpbGwgYmUgaW5j bHVkZWQgaW4gdGhlIEV0aGVyRW5jYXAgTEZCPw0KPj4NCj4+IOKXjyBFdGhlckVuY2FwIGlzIG5v dCBhd2FyZSBvZiBJUFY0IG9yIFY2DQo+PiBSZTogWWVzLCBjdXJyZW50IHZlcnNpb24gb2YgRXRo ZXJFbmNhcCBpbmNsdWRlcyBJUHY0IGFuZCB2Ni4NCj4+DQo+PiDil48gVXAgdG8gaW1wbGVtZW50 YXRpb24gaWYgSVAgaXMgaWdub3JlZCBvciBob3cgaXQgaXMgdXNlZCAoQVJQL05EKQ0KPj4gUmU6 IGNvdWxkIHRoaXMgYmUgZGVzY3JpYmVkIG1vcmU/IEkganVzdCBjYW4gbm90IGNhdGNoIHVwIHdl bGwgd2l0aCB3aGF0IGl0IG1lYW5zIGJlaGluZC4NCj4+DQo+IA0KPiBJIG1lYW50IHdlIGhhdmUg b25seSB0aGUgdXNlZnVsIGVuY2Fwc3VsYXRpb24gaW5mb3JtYXRpb24gZm9yIHRoZSBuZXh0aG9w DQo+IGxpbmsgbGF5ZXIgZGV0YWlscyAtIG5vdCBob3cgc3VjaCBpbmZvcm1hdGlvbiBpcyBnYXRo ZXJlZC4NCj4gVGhpcyBpbmZvcm1hdGlvbiBpcyBpbmRleGVkIGJ5IHdoYXQgaSBjYWxsZWQgTkhF bmNhcEluZm9JbmRleCBhYm92ZS4NCj4gVGhpcyB3aWxsIGFsbG93IHNvbWVvbmUgdG8gaW5zdGFs bCBhbGwgdGhlIGRldGFpbHMgb2YgZHN0bWFjLCBzcmNtYWMgYW5kIFZMQU4NCj4gaW5mbyB3aXRo b3V0IG5lZWRpbmcgZm9yIEZFIHRvIGJlIGF3YXJlIG9mIEFSUC4gT3IgaWYgdGhleSBkZWNpZGUg dG8gdXNlDQo+IEFSUCB3aGVuIHRoZSBwYWNrZXQgZ2V0cyB0byB0aGF0IHBvaW50LCB0aGVuIHRo ZXkgY2FuIGNob29zZSB0byBkbyBzbw0KPiAoZXZlbiB0aG91Z2ggaSB0aGluayB0aGF0IGlzIGEg YmFkIGlkZWEpLg0KPiANCj4+IOKXjyBOZXcgRW5jYXBUYWJsZSBpbiBFdGhlckVuY2FwIExGQiBp bmRleGVkIGJ5IEVuY2FwT3V0cHV0SW5kZXgNCj4+IFJlOiBJIGp1c3QgY2FuIG5vdCB1bmRlcnN0 YW5kIHdlbGwgaG93IGNhbiBFbmNhcE91dHB1dEluZGV4IGJlIHVzZWQgYXMgaW5kZXggZm9yID5w YWNrZXRzIHRvIGZpbmQgb3V0IGVuY2FwIGluZm9ybWF0aW9uIGZvciB0aGUgcGFja2V0cz8gQ291 bGQgeW91IHByb3ZpZGUgbW9yZSBvbiA+dGhpcz8gdGhhbmtzLg0KPiANCj4gVGFibGUgbmFtZTog TkhFbmNhcFRhYmxlDQo+IFRhYmxlIGluZGV4OiBOSEVuY2FwSW5mb0luZGV4DQo+IFRhYmxlIGVu dHJpZXMgb3B0aW9uIDE6DQo+IGRzdG1hYywgc3JjbWFjLCBvcHRpb25hbCB2bGFuIGluZm9ybWF0 aW9uDQo+IG9yIFRhYmxlIGVudHJpZXMgb3B0aW9uIDE6DQo+IGRzdG1hYywgRW5jYXBTcmNJbmRl eA0KPiBhbmQgdGhlbiB1c2UgRW5jYXBTcmNJbmRleCB0byBmaW5kIHNyY21hYyBhbmQgb3B0aW9u YWwgVkxBTiBpbmZvcm1hdGlvbi4NCj4gDQo+IEkgaG9wZSB0aGlzIG1ha2VzIHNlbnNlLg0KV1Jl OiBKYW1hbCwgdG8gdGhpcyBwb2ludCwgSSBnZXQgdG8gdW5kZXJzdGFuZCBtb3JlIG9uIHdoYXQg eW91IHRob3VnaHQuIA0KWW91ciB0aG91Z2h0IG1pZ2h0IGJlOiANCi4gTFBNIExGQiB0byBmaW5k IGFuIE5ISUQNCi5OSCBMRkIgdXNlcyB0aGUgTkhJRCB0byBmaW5kIGEgcG9ydCBJRCBhbmQgc29t ZSBpbmRleCAoeW91IGNhbGwgRW5jYXBJbmZvSW5kZXgpDQouIEVuY2FwIExGQiB1c2VzIHRoZSBp bmRleCB0byBmaW5kIGFsbCBlbmNhcCBpbmZvcm1hdGlvbiwgV0hJTEUga2VlcGluZyB0aGUgcG9y dCBJRCB1bmNoYW5nZWQgdG8gb3V0cHV0IHBvcnQgdG8gZG93bnN0cmVhbSBMRkIuDQoNCldoaWxl IG91ciBjdXJyZW50IHZlcnNpb24gdXNlcyB0aGUgZm9sbG93aW5nIHN0ZXBzOiANCi4gTFBNIExG QiB0byBmaW5kIGFuIE5ISUQNCi4gTkggTEZCIHVzZXMgdGhlIE5ISUQgdG8gZmluZCBhIHBvcnQg IElEIChsb2dpY2FsIHBvcnQgSUQpDQouIEVuY2FwIExGQiB1c2VzIHRoZSBwb3J0IElEIHRvIGZp bmQgYSBuZXcgb3V0cHV0IGxvZ2ljYWwgcG9ydCBJRCBhbmQgYSBWTEFOIGlkLCB0aGVuIHZpYSB0 aGUgb3V0cHV0IGxvZ2ljYWwgcG9ydCBJRCB0byBmaW5kIG1vcmUgZW5jYXAgaW5mb3JtYXRpb24g aW4gYW4gQXJwVGFiZWwuIE1vcmVvdmVyLCB0aGUgb3V0cHV0IGxvZ2ljYWwgcG9ydCAgSUQgaXMg b3V0cHV0IHRvIGRvd25zdHJlYW0gTEZCLiANCg0KU28sIHRoZSBrZXkgZGlmZmVyZW5jZSBpcyB3 aGF0IHdlIHNoYWxsIGNhbGwgdGhlIElEIGdlbmVyYXRlZCBieSBOSCBMRkIoeW91IGNhbGwgaXQg YW4gaW5kZXgsIHdlIGN1cnJlbnRseSBqdXN0IGNhbGwgaXQgbG9naWNhbCBwb3J0IElEKS4gIEkg cmVtZW1iZXIgd2UgY2FsbCBpdCBsb2dpY2FsIHBvcnQgSUQgYmVjYXVzZSBzb21lIEwyIGJyaWRn aW5nIExGQnMgbWF5IGFsc28gcG9zc2libHkgZ2VuZXJhdGUgdGhpcyBraW5kIG9mIGxvZ2ljYWwg cG9ydCBJRHMgdG8gaW5wdXQgdG8gRXRoZXJlbmNhcCBMRkIgZm9yIGVuY2FwIGluZm9ybWF0aW9u LiBJIG5lZWQgSm9lbC9DaHVhbmh1YW5nIHRvIHZlcmlmeSB0aGlzLiANCg0KPiANCj4+IOKXjyBO byBJUCBpbmZvcm1hdGlvbiBzdG9yZWQNCj4gDQo+IEFzIGV2aWRlbmNlIGZyb20gYWJvdmUsIHlv dSBjYW4gc2VlIG5vIElQIGluZm9ybWF0aW9uIG5lZWRlZCBieQ0KPiBldGhlcm5ldCBlbmNhcHN1 bGF0b3IuIE5ISVAgaXMgc3RpbGwgcGFzc2VkIGFzIG1ldGFkYXRhIC0gc28gaWYgeW91cg0KPiBp bXBsZW1lbnRhdGlvbg0KPiB3YW50cyB0byBkbyBBUlAgb3IgTkQgdG8gcG9wdWxhdGUgZHNtYWMg YWRkcmVzcywgdGhleSBjYW4gZG8gdGhhdC4NCj4gDQo+PiDil48gTm8gTG9naWNhbFBvcnRJRCwg d2UgYWxyZWFkeSBoYXZlIG9uZSBmcm9tIE5IDQo+PiBSZTogSW4gY3VycmVudCBFdGhlckVuY2Fw IExGQiwgd2UndiBkZWZpbmVkIGEgVkxBTiBvdXRwdXQgdGFibGUsIHdoaWNoIGlzIHVzZWQgZm9y ID5hIHBhY2tldCB0byBmaW5kIG91dCBhbiBvdXRwdXQgbG9naWNhbCBwb3J0IElEIGFuZCBhIFZs YW5JRCBieSBhbiBpbnB1dCBsb2dpY2FsIHBvcnQgSUQgPndoaWNoIGlzIGZyb20gdXBzdHJlYW0g TkggTEZCLiBUaGlzIG1lYW5zLCB0aGUgbG9naWNhbCBwb3J0IElEIGdlbmVyYXRlZCBieSA+TmV4 dEhvcCB0YWJsZSBpbiBOSCBpcyBkaWZmZXJlbnQgZnJvbSB0aGUgbG9naWNhbCBwb3J0IElEIGdl bmVyYXRlZCBieSB0aGlzID5FdGhlckVuY2FwIExGQi4NCj4+IFdlIGRlc2lnbmVkIHRoaXMgYWZ0 ZXIgc29tZSBkaXNjdXNzaW9ucyBiZXR3ZWVuIEpvZWwgYW5kIENodWFuaHVhbmcuIEkgaG9wZSB5 b3UgPiB0d28gZ3V5cyBjYW4gcHJvdmlkZSBtb3JlIGluZm9ybWF0aW9uIG9uIHRoaXMgZGVzaWdu LiBUaGFua3MuDQo+Pg0KPiANCj4gSSBkaWRudCBxdWlldCBmb2xsb3cgdGhlIHJlYXNvbmluZy4N Cj4gVGhlIHJvdXRlIChMUE0rTkgpIHBvaW50cyB0byBhIGxvZ2ljYWwgcG9ydCB3aGVyZSB0aGUg cGFja2V0IGlzIHRvIGdvIG91dC4gRG9lcw0KPiB0aGlzIG1lYW4gc29tZSBvdGhlciBwb2xpY3kg ZG93bnN0cmVhbSB3aWxsIG1ha2UgdGhlIGRlY2lzaW9uIHRvIGNoYW5nZSB0aGlzPw0KPiBKb2Vs L0NodWFuaHVhbmc/DQpXUmU6IEkgdGhpbmsgdGhpcyBxdWVzdGlvbiBoYXMgbGlua2VkIHRvIHRo ZSBxdWVzaW9uIG9uZSBhYm92ZS4gDQo+IA0KPj4g4pePIFN0b3JlIGRzdG1hYyBhbmQgcG9zc2li bHkgYSBFbmNhcFNyY0luZGV4DQo+PiDil48gRmluZCBzcmNtYWMgYW5kIFZMQU4gZGV0YWlscyB3 aXRoaW4gRW5jYXBUYWJsZSBieSBvbmUtb2Y6DQo+PiDil48gVXNlIHN0b3JlZCBFbmNhcFNyY0lu ZGV4IHRvIGluZGV4IGFub3RoZXIgc3JjRW5jYXAgdGFibGUNCj4+IOKXjyBTdG9yZSBzcmNtYWMg YW5kIG9wdGlvbmFsIHZsYW4gaW5mb3JtYXRpb24gaW4gRW5jYXBUYWJsZQ0KPj4gUmU6IEknbSBz b3JyeSB0aGF0IEkgc3RpbGwgY2FuIG5vdCBjYXRjaCB1cCBoZXJlIHdlbGwuIFdoeSBkb24ndCB3 ZSBqdXN0IGRlZmluZSBhIHRhYmxlID5pbiB3aGljaCBkc3RtYWMgYW5kIHNyY21hYyBhcmUgaW5j bHVkZWQsIGp1c3QgYXMgdGhlIEFycFRhYmxlIGRvZXMgaW4gY3VycmVudCA+dmVyc2lvbiBFdGhl ckVuY2FwIExGQj8NCj4gDQo+IFdlIGNvdWxkLiBVc2luZyBhbiBpbmRleCB3aWxsIHVzZSBsZXNz IG1lbW9yeSAtIGJ1dCB3ZSBjYW4gb3B0aW1pemUgbGF0ZXIuDQo+IA0K From hadi@mojatatu.com Mon Apr 11 08:10: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 6BF663A6A72 for ; Mon, 11 Apr 2011 08:10:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.533 X-Spam-Level: X-Spam-Status: No, score=-101.533 tagged_above=-999 required=5 tests=[AWL=-0.356, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_33=0.6, J_CHICKENPOX_37=0.6, 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 zO0PFlXBDfyR for ; Mon, 11 Apr 2011 08:10:02 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id B551728C11D for ; Mon, 11 Apr 2011 08:10:02 -0700 (PDT) Received: by vws12 with SMTP id 12so5247216vws.31 for ; Mon, 11 Apr 2011 08:10:02 -0700 (PDT) Received: by 10.52.67.167 with SMTP id o7mr3455837vdt.240.1302534601972; Mon, 11 Apr 2011 08:10:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.181.8 with HTTP; Mon, 11 Apr 2011 08:09:25 -0700 (PDT) In-Reply-To: References: From: Jamal Hadi Salim Date: Mon, 11 Apr 2011 11:09:25 -0400 Message-ID: To: "Wang,Weiming" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: forces@ietf.org, Chuanhuang Li , "Joel M. Halpern" Subject: Re: [forces] LFB LPM issue 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, 11 Apr 2011 15:10:03 -0000 Hi Weiming, On Mon, Apr 11, 2011 at 10:48 AM, Wang,Weiming wro= te: > WRe: Jamal, 5.3.2. =A0IPv4NextHop section has described the use of the In= dex, pls >check p.50 of LFB lib v3, although more words may be added to sta= te the genericity >in link layers. I am looking at the text now and i see it mentioned as "encapsulation outpu= t index". I searched for "EncapOutputIndex" in the text. So i am not sure if i am at fault - or you need to fix the text and call it "EncapOutputIndex" for consistency. > WRe: currently we have used the logical port ID as the metadata output by= the NH >LFB to index the table in Etherencap LFB. I'm not sure if you mean= this kind > of index, or totally other one? My thinking is that logical port ID is related to what output logical port = it is going out. I notice you use it to index into this table - but i think we ne= ed a new index for this table. We can continue to pass the logical port ID as is or derive it from here .. >> >> Table name: NHEncapTable >> Table index: NHEncapInfoIndex >> Table entries option 1: >> dstmac, srcmac, optional vlan information >> or Table entries option 1: >> dstmac, EncapSrcIndex >> and then use EncapSrcIndex to find srcmac and optional VLAN information. >> >> I hope this makes sense. > WRe: Jamal, to this point, I get to understand more on what you thought. > Your thought might be: > . LPM LFB to find an NHID > .NH LFB uses the NHID to find a port ID and some index (you call EncapInf= oIndex) > . Encap LFB uses the index to find all encap information, WHILE keeping t= he port ID unchanged to output port to downstream LFB. > I am not fixated on where the logical port id is stored. It could be in the encap LFB. > While our current version uses the following steps: > . LPM LFB to find an NHID > . NH LFB uses the NHID to find a port =A0ID (logical port ID) > . Encap LFB uses the port ID to find a new output logical port ID and a V= LAN id, then via the output logical port ID to find more encap information = in an ArpTabel. Moreover, the output logical port =A0ID is output to downst= ream LFB. > > So, the key difference is what we shall call the ID generated by NH LFB(y= ou call it >an index, we currently just call it logical port ID). =A0I reme= mber we call it logical port ID >because some L2 bridging LFBs may also pos= sibly generate this kind of logical port >IDs to input to Etherencap LFB fo= r encap information. I need Joel/Chuanhuang to >verify this. > This may explain why you repeat the port information further down. I dont think you should call that thing "logical port ID" - it confuses the terms. cheers, jamal From jmh@joelhalpern.com Mon Apr 11 08:01:19 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 E268E3A6889 for ; Mon, 11 Apr 2011 08:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.249 X-Spam-Level: X-Spam-Status: No, score=-99.249 tagged_above=-999 required=5 tests=[AWL=-3.250, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_24=0.6, J_CHICKENPOX_25=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_29=0.6, J_CHICKENPOX_31=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_47=0.6, J_CHICKENPOX_52=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 Oh++7-rSHGxN for ; Mon, 11 Apr 2011 08:01:19 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes.out.tigertech.net [74.114.88.72]) by core3.amsl.com (Postfix) with ESMTP id 26BF53A68D1 for ; Mon, 11 Apr 2011 08:01:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id BCDF74300EA; Mon, 11 Apr 2011 08:01:19 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [172.17.114.244] (207.47.24.2.static.nextweb.net [207.47.24.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id 92FAD430039; Mon, 11 Apr 2011 08:01:19 -0700 (PDT) Message-ID: <4DA317B9.9040604@joelhalpern.com> Date: Mon, 11 Apr 2011 11:01:13 -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: "Wang,Weiming" References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Mon, 11 Apr 2011 08:19:25 -0700 Cc: forces@ietf.org, Chuanhuang Li Subject: Re: [forces] LFB LPM issue 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, 11 Apr 2011 15:01:20 -0000 The NH LFB needs to generate both a port ID and an encapsulation index. The encapsulation index does not select the port, as each port has its own encapsulation table (conceptually. Implementation-wise we may design the LFB to use both indices if you want.) If the output port selected by the NH LFB is actually a bridged port, then the encapsualtion information will also need to provide a more specific output port. Normally, it will be the same output port index as the input port index. Yours, Joel On 4/11/2011 10:48 AM, Wang,Weiming wrote: > Hi Jamal, more reply inline. > > thanks, > Weiming > ----- Original Message ----- > From: "Jamal Hadi Salim" >>> ----- >>> ● NH outputs as part of metadata EncapOutputIndex >>> ●Already available, just not used currently >> >>> Re: in current version of NH LFB, the EncapOutputIndex is used by this NH LFB>itself to select the output from the output group. For instance, if the group output 1 is>connected to a downstream EtherEncap LFB, then the packets with the>EncapOutputIndex assigned to 1 means to output to an Ether encapsulator. >>> >>> I'm not sure if you mean to define this EncapOutputIndex as a metadata output via>the NH output port? if so, how can we distinguish different encapsulators followed,>saying we have other encapsulations other than Ethernet followed. >>> >> >> I misunderstood the meaning of that index because I dont think what >> you just described above is in the text of the draft. >> Am i mistaken? If i am not, then please add to the TODO list >> such an explanation. Also, maybe somewhere we need to say that >> the design choices of the LFBs is so that we can have genericity in >> Link layers (although we currently only focus on Ethernet) as evidenced >> by the presence of EncapOutputIndex. > > WRe: Jamal, 5.3.2. IPv4NextHop section has described the use of the Index, pls check p.50 of LFB lib v3, although more words may be added to state the genericity in link layers. > >> >> Having said that: >> What i meant is we need some index which is output as metadata from NH. >> The value of this metadata will be used to index into a table in the >> Ether encapsulator. I called it EncapOutputIndex but change its >> name to something else. For example, lets call it NHEncapInfoIndex > WRe: currently we have used the logical port ID as the metadata output by the NH LFB to index the table in Etherencap LFB. I'm not sure if you mean this kind of index, or totally other one? > >> >>> ●ARP/ND resolution removed >>> Re: not sure the details, you mean the ARP/ND function will be included in the EtherEncap LFB? >>> >>> ● EtherEncap is not aware of IPV4 or V6 >>> Re: Yes, current version of EtherEncap includes IPv4 and v6. >>> >>> ● Up to implementation if IP is ignored or how it is used (ARP/ND) >>> Re: could this be described more? I just can not catch up well with what it means behind. >>> >> >> I meant we have only the useful encapsulation information for the nexthop >> link layer details - not how such information is gathered. >> This information is indexed by what i called NHEncapInfoIndex above. >> This will allow someone to install all the details of dstmac, srcmac and VLAN >> info without needing for FE to be aware of ARP. Or if they decide to use >> ARP when the packet gets to that point, then they can choose to do so >> (even though i think that is a bad idea). >> >>> ● New EncapTable in EtherEncap LFB indexed by EncapOutputIndex >>> Re: I just can not understand well how can EncapOutputIndex be used as index for>packets to find out encap information for the packets? Could you provide more on>this? thanks. >> >> Table name: NHEncapTable >> Table index: NHEncapInfoIndex >> Table entries option 1: >> dstmac, srcmac, optional vlan information >> or Table entries option 1: >> dstmac, EncapSrcIndex >> and then use EncapSrcIndex to find srcmac and optional VLAN information. >> >> I hope this makes sense. > WRe: Jamal, to this point, I get to understand more on what you thought. > Your thought might be: > . LPM LFB to find an NHID > .NH LFB uses the NHID to find a port ID and some index (you call EncapInfoIndex) > . Encap LFB uses the index to find all encap information, WHILE keeping the port ID unchanged to output port to downstream LFB. > > While our current version uses the following steps: > . LPM LFB to find an NHID > . NH LFB uses the NHID to find a port ID (logical port ID) > . Encap LFB uses the port ID to find a new output logical port ID and a VLAN id, then via the output logical port ID to find more encap information in an ArpTabel. Moreover, the output logical port ID is output to downstream LFB. > > So, the key difference is what we shall call the ID generated by NH LFB(you call it an index, we currently just call it logical port ID). I remember we call it logical port ID because some L2 bridging LFBs may also possibly generate this kind of logical port IDs to input to Etherencap LFB for encap information. I need Joel/Chuanhuang to verify this. > >> >>> ● No IP information stored >> >> As evidence from above, you can see no IP information needed by >> ethernet encapsulator. NHIP is still passed as metadata - so if your >> implementation >> wants to do ARP or ND to populate dsmac address, they can do that. >> >>> ● No LogicalPortID, we already have one from NH >>> Re: In current EtherEncap LFB, we'v defined a VLAN output table, which is used for>a packet to find out an output logical port ID and a VlanID by an input logical port ID>which is from upstream NH LFB. This means, the logical port ID generated by>NextHop table in NH is different from the logical port ID generated by this>EtherEncap LFB. >>> We designed this after some discussions between Joel and Chuanhuang. I hope you> two guys can provide more information on this design. Thanks. >>> >> >> I didnt quiet follow the reasoning. >> The route (LPM+NH) points to a logical port where the packet is to go out. Does >> this mean some other policy downstream will make the decision to change this? >> Joel/Chuanhuang? > WRe: I think this question has linked to the quesion one above. >> >>> ● Store dstmac and possibly a EncapSrcIndex >>> ● Find srcmac and VLAN details within EncapTable by one-of: >>> ● Use stored EncapSrcIndex to index another srcEncap table >>> ● Store srcmac and optional vlan information in EncapTable >>> Re: I'm sorry that I still can not catch up here well. Why don't we just define a table>in which dstmac and srcmac are included, just as the ArpTable does in current>version EtherEncap LFB? >> >> We could. Using an index will use less memory - but we can optimize later. >> From hadi@mojatatu.com Mon Apr 11 08:25:51 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 D3A113A69C6 for ; Mon, 11 Apr 2011 08:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.413 X-Spam-Level: X-Spam-Status: No, score=-102.413 tagged_above=-999 required=5 tests=[AWL=0.564, 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 13U6rwO0Fven for ; Mon, 11 Apr 2011 08:25:51 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 294F73A697E for ; Mon, 11 Apr 2011 08:25:50 -0700 (PDT) Received: by qyk7 with SMTP id 7so3689270qyk.10 for ; Mon, 11 Apr 2011 08:25:51 -0700 (PDT) Received: by 10.52.166.101 with SMTP id zf5mr122978vdb.280.1302535551153; Mon, 11 Apr 2011 08:25:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.181.8 with HTTP; Mon, 11 Apr 2011 08:25:31 -0700 (PDT) In-Reply-To: <4DA317B9.9040604@joelhalpern.com> References: <4DA317B9.9040604@joelhalpern.com> From: Jamal Hadi Salim Date: Mon, 11 Apr 2011 11:25:31 -0400 Message-ID: To: "Joel M. Halpern" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: forces@ietf.org, Chuanhuang Li Subject: Re: [forces] LFB LPM issue 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, 11 Apr 2011 15:25:52 -0000 Hi Joel, On Mon, Apr 11, 2011 at 11:01 AM, Joel M. Halpern wro= te: > The NH LFB needs to generate both a port ID and an encapsulation index. > > The encapsulation index does not select the port, as each port has its ow= n > encapsulation table (conceptually. =A0Implementation-wise we may design t= he > LFB to use both indices if you want.) > > If the output port selected by the NH LFB is actually a bridged port, the= n > the encapsualtion information will also need to provide a more specific > output port. =A0Normally, it will be the same output port index as the in= put > port index. > So you have a two level mux? i.e a) Selection encapsulation table (type?) - in current case Ethernet b) Select port which may have its own encap table. The discussion with Weiming is what to select within an encap table (my suggestion of a new index) i.e while two packets may go out the same port, they may use different src/dstmac as well as VLAN info. cheers, jamal From hadi@mojatatu.com Mon Apr 11 08:26: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 B2FC73A6A72 for ; Mon, 11 Apr 2011 08:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.443 X-Spam-Level: X-Spam-Status: No, score=-102.443 tagged_above=-999 required=5 tests=[AWL=0.534, 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 R9OyzirhN9bR for ; Mon, 11 Apr 2011 08:26:39 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 133903A6A47 for ; Mon, 11 Apr 2011 08:26:38 -0700 (PDT) Received: by vws12 with SMTP id 12so5264701vws.31 for ; Mon, 11 Apr 2011 08:26:39 -0700 (PDT) Received: by 10.52.65.69 with SMTP id v5mr4050853vds.200.1302535599234; Mon, 11 Apr 2011 08:26:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.181.8 with HTTP; Mon, 11 Apr 2011 08:26:19 -0700 (PDT) From: Jamal Hadi Salim Date: Mon, 11 Apr 2011 11:26:19 -0400 Message-ID: To: forces@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [forces] LFBLib v3: typos etc 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, 11 Apr 2011 15:26:39 -0000 There are a few typos, btw: 1) inconsistencies in spelling LFB sometime as lfb and sometimes in mixed upper and lower case 2) spelling. Example "packet" sometimes shows up as "pakcet" cheers, jamal From wmwang2001@hotmail.com Mon Apr 11 08:29:02 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 7F9C928C12B for ; Mon, 11 Apr 2011 08:29:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.583 X-Spam-Level: X-Spam-Status: No, score=-95.583 tagged_above=-999 required=5 tests=[AWL=-2.700, BAYES_00=-2.599, FORGED_MUA_OUTLOOK=3.116, J_CHICKENPOX_21=0.6, J_CHICKENPOX_24=0.6, J_CHICKENPOX_25=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_29=0.6, J_CHICKENPOX_31=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_47=0.6, J_CHICKENPOX_52=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 f-Jmyw1o5vi8 for ; Mon, 11 Apr 2011 08:29:01 -0700 (PDT) Received: from blu0-omc2-s19.blu0.hotmail.com (blu0-omc2-s19.blu0.hotmail.com [65.55.111.94]) by core3.amsl.com (Postfix) with ESMTP id 6E1D53A697E for ; Mon, 11 Apr 2011 08:29:01 -0700 (PDT) Received: from BLU0-SMTP179 ([65.55.111.72]) by blu0-omc2-s19.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 11 Apr 2011 08:29:01 -0700 X-Originating-IP: [220.184.140.181] X-Originating-Email: [wmwang2001@hotmail.com] Message-ID: Received: from WmwangHome ([220.184.140.181]) by BLU0-SMTP179.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 11 Apr 2011 08:28:59 -0700 From: "Wang,Weiming" To: "Joel M. Halpern" References: <4DA317B9.9040604@joelhalpern.com> Date: Mon, 11 Apr 2011 23:29:06 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" 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: 11 Apr 2011 15:29:00.0506 (UTC) FILETIME=[2E71FBA0:01CBF85D] Cc: forces@ietf.org, Chuanhuang Li Subject: Re: [forces] LFB LPM issue 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, 11 Apr 2011 15:29:02 -0000 Sm9lbCwgDQoNCk9uIHRoZSBlbmNhcHN1bGF0aW9uIGluZGV4LCBJIHRoaW5rIHdlIGhhdmUgcmVh Y2hlZCBhIGNvbnNlbnN1cyB0aGF0IHRoZSBpbmRleCBpcyBhcyBhIHBvcnQgc2VsZWN0b3IgZm9y IE5IIExGQiBncm91cCBvdXRwdXQuIEkganVzdCBjaGVja2VkIHRoZSBtZXNzYWdlcyBhcyB0aGUg Zm9sbG93aW5nIHRpbWUgYWdhaW46DQoNClNlbnQ6IEZyaWRheSwgU2VwdGVtYmVyIDEwLCAyMDEw IDg6MzcgUE0NClN1YmplY3Q6IFJlOiBEZWZpbml0aW9uIG9mIElQdjROZXh0SG9wQXBwbGljYXRv ciBMRkINCg0KU2VudDogU2F0dXJkYXksIFNlcHRlbWJlciAxMSwgMjAxMCAxMjo1NyBBTQ0KU3Vi amVjdDogUmU6IERlZmluaXRpb24gb2YgSVB2NE5leHRIb3BBcHBsaWNhdG9yIExGQg0KDQp0aGFu a3MsDQpXZWltaW5nDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiSm9l bCBNLiBIYWxwZXJuIiA8am1oQGpvZWxoYWxwZXJuLmNvbT4NCg0KPiBUaGUgTkggTEZCIG5lZWRz IHRvIGdlbmVyYXRlIGJvdGggYSBwb3J0IElEIGFuZCBhbiBlbmNhcHN1bGF0aW9uIGluZGV4Lg0K PiANCj4gVGhlIGVuY2Fwc3VsYXRpb24gaW5kZXggZG9lcyBub3Qgc2VsZWN0IHRoZSBwb3J0LCBh cyBlYWNoIHBvcnQgaGFzIGl0cyANCj4gb3duIGVuY2Fwc3VsYXRpb24gdGFibGUgKGNvbmNlcHR1 YWxseS4gIEltcGxlbWVudGF0aW9uLXdpc2Ugd2UgbWF5IA0KPiBkZXNpZ24gdGhlIExGQiB0byB1 c2UgYm90aCBpbmRpY2VzIGlmIHlvdSB3YW50LikNCj4gDQo+IElmIHRoZSBvdXRwdXQgcG9ydCBz ZWxlY3RlZCBieSB0aGUgTkggTEZCIGlzIGFjdHVhbGx5IGEgYnJpZGdlZCBwb3J0LCANCj4gdGhl biB0aGUgZW5jYXBzdWFsdGlvbiBpbmZvcm1hdGlvbiB3aWxsIGFsc28gbmVlZCB0byBwcm92aWRl IGEgbW9yZSANCj4gc3BlY2lmaWMgb3V0cHV0IHBvcnQuICBOb3JtYWxseSwgaXQgd2lsbCBiZSB0 aGUgc2FtZSBvdXRwdXQgcG9ydCBpbmRleCANCj4gYXMgdGhlIGlucHV0IHBvcnQgaW5kZXguDQo+ IA0KPiBZb3VycywNCj4gSm9lbA0KPiANCj4gT24gNC8xMS8yMDExIDEwOjQ4IEFNLCBXYW5nLFdl aW1pbmcgd3JvdGU6DQo+PiBIaSBKYW1hbCwgbW9yZSByZXBseSBpbmxpbmUuDQo+Pg0KPj4gdGhh bmtzLA0KPj4gV2VpbWluZw0KPj4gLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KPj4gRnJv bTogIkphbWFsIEhhZGkgU2FsaW0iPGhhZGlAbW9qYXRhdHUuY29tPg0KPj4+PiAtLS0tLQ0KPj4+ PiDil48gTkggb3V0cHV0cyBhcyBwYXJ0IG9mIG1ldGFkYXRhIEVuY2FwT3V0cHV0SW5kZXgNCj4+ Pj4g4pePQWxyZWFkeSBhdmFpbGFibGUsIGp1c3Qgbm90IHVzZWQgY3VycmVudGx5DQo+Pj4NCj4+ Pj4gUmU6IGluIGN1cnJlbnQgdmVyc2lvbiBvZiBOSCBMRkIsIHRoZSBFbmNhcE91dHB1dEluZGV4 IGlzIHVzZWQgYnkgdGhpcyBOSCBMRkI+aXRzZWxmIHRvIHNlbGVjdCB0aGUgb3V0cHV0IGZyb20g dGhlIG91dHB1dCBncm91cC4gRm9yIGluc3RhbmNlLCBpZiB0aGUgZ3JvdXAgb3V0cHV0IDEgaXM+ Y29ubmVjdGVkIHRvIGEgZG93bnN0cmVhbSBFdGhlckVuY2FwIExGQiwgdGhlbiB0aGUgcGFja2V0 cyB3aXRoIHRoZT5FbmNhcE91dHB1dEluZGV4IGFzc2lnbmVkIHRvIDEgbWVhbnMgdG8gb3V0cHV0 IHRvIGFuIEV0aGVyIGVuY2Fwc3VsYXRvci4NCj4+Pj4NCj4+Pj4gSSdtIG5vdCBzdXJlIGlmIHlv dSBtZWFuIHRvIGRlZmluZSB0aGlzIEVuY2FwT3V0cHV0SW5kZXggYXMgYSBtZXRhZGF0YSBvdXRw dXQgdmlhPnRoZSBOSCBvdXRwdXQgcG9ydD8gaWYgc28sIGhvdyBjYW4gd2UgZGlzdGluZ3Vpc2gg ZGlmZmVyZW50IGVuY2Fwc3VsYXRvcnMgZm9sbG93ZWQsPnNheWluZyB3ZSBoYXZlIG90aGVyIGVu Y2Fwc3VsYXRpb25zIG90aGVyIHRoYW4gRXRoZXJuZXQgZm9sbG93ZWQuDQo+Pj4+DQo+Pj4NCj4+ PiBJIG1pc3VuZGVyc3Rvb2QgdGhlIG1lYW5pbmcgb2YgdGhhdCBpbmRleCBiZWNhdXNlIEkgZG9u dCB0aGluayB3aGF0DQo+Pj4geW91IGp1c3QgZGVzY3JpYmVkIGFib3ZlIGlzIGluIHRoZSB0ZXh0 IG9mIHRoZSBkcmFmdC4NCj4+PiBBbSBpIG1pc3Rha2VuPyBJZiBpIGFtIG5vdCwgdGhlbiBwbGVh c2UgYWRkIHRvIHRoZSBUT0RPIGxpc3QNCj4+PiBzdWNoIGFuIGV4cGxhbmF0aW9uLiBBbHNvLCBt YXliZSBzb21ld2hlcmUgd2UgbmVlZCB0byBzYXkgdGhhdA0KPj4+IHRoZSBkZXNpZ24gY2hvaWNl cyBvZiB0aGUgTEZCcyBpcyBzbyB0aGF0IHdlIGNhbiBoYXZlIGdlbmVyaWNpdHkgaW4NCj4+PiBM aW5rIGxheWVycyAoYWx0aG91Z2ggd2UgY3VycmVudGx5IG9ubHkgZm9jdXMgb24gRXRoZXJuZXQp IGFzIGV2aWRlbmNlZA0KPj4+IGJ5IHRoZSBwcmVzZW5jZSBvZiBFbmNhcE91dHB1dEluZGV4Lg0K Pj4NCj4+IFdSZTogSmFtYWwsIDUuMy4yLiAgSVB2NE5leHRIb3Agc2VjdGlvbiBoYXMgZGVzY3Jp YmVkIHRoZSB1c2Ugb2YgdGhlIEluZGV4LCBwbHMgY2hlY2sgcC41MCBvZiBMRkIgbGliIHYzLCBh bHRob3VnaCBtb3JlIHdvcmRzIG1heSBiZSBhZGRlZCB0byBzdGF0ZSB0aGUgZ2VuZXJpY2l0eSBp biBsaW5rIGxheWVycy4NCj4+DQo+Pj4NCj4+PiBIYXZpbmcgc2FpZCB0aGF0Og0KPj4+IFdoYXQg aSBtZWFudCBpcyB3ZSBuZWVkIHNvbWUgaW5kZXggd2hpY2ggaXMgb3V0cHV0IGFzIG1ldGFkYXRh IGZyb20gTkguDQo+Pj4gVGhlIHZhbHVlIG9mIHRoaXMgbWV0YWRhdGEgd2lsbCBiZSB1c2VkIHRv IGluZGV4IGludG8gYSB0YWJsZSBpbiB0aGUNCj4+PiBFdGhlciBlbmNhcHN1bGF0b3IuIEkgY2Fs bGVkIGl0IEVuY2FwT3V0cHV0SW5kZXggYnV0IGNoYW5nZSBpdHMNCj4+PiBuYW1lIHRvIHNvbWV0 aGluZyBlbHNlLiBGb3IgZXhhbXBsZSwgbGV0cyBjYWxsIGl0IE5IRW5jYXBJbmZvSW5kZXgNCj4+ IFdSZTogY3VycmVudGx5IHdlIGhhdmUgdXNlZCB0aGUgbG9naWNhbCBwb3J0IElEIGFzIHRoZSBt ZXRhZGF0YSBvdXRwdXQgYnkgdGhlIE5IIExGQiB0byBpbmRleCB0aGUgdGFibGUgaW4gRXRoZXJl bmNhcCBMRkIuIEknbSBub3Qgc3VyZSBpZiB5b3UgbWVhbiB0aGlzIGtpbmQgb2YgaW5kZXgsIG9y IHRvdGFsbHkgb3RoZXIgb25lPw0KPj4NCj4+Pg0KPj4+PiDil49BUlAvTkQgcmVzb2x1dGlvbiBy ZW1vdmVkDQo+Pj4+IFJlOiBub3Qgc3VyZSB0aGUgZGV0YWlscywgeW91IG1lYW4gdGhlIEFSUC9O RCBmdW5jdGlvbiB3aWxsIGJlIGluY2x1ZGVkIGluIHRoZSBFdGhlckVuY2FwIExGQj8NCj4+Pj4N Cj4+Pj4g4pePIEV0aGVyRW5jYXAgaXMgbm90IGF3YXJlIG9mIElQVjQgb3IgVjYNCj4+Pj4gUmU6 IFllcywgY3VycmVudCB2ZXJzaW9uIG9mIEV0aGVyRW5jYXAgaW5jbHVkZXMgSVB2NCBhbmQgdjYu DQo+Pj4+DQo+Pj4+IOKXjyBVcCB0byBpbXBsZW1lbnRhdGlvbiBpZiBJUCBpcyBpZ25vcmVkIG9y IGhvdyBpdCBpcyB1c2VkIChBUlAvTkQpDQo+Pj4+IFJlOiBjb3VsZCB0aGlzIGJlIGRlc2NyaWJl ZCBtb3JlPyBJIGp1c3QgY2FuIG5vdCBjYXRjaCB1cCB3ZWxsIHdpdGggd2hhdCBpdCBtZWFucyBi ZWhpbmQuDQo+Pj4+DQo+Pj4NCj4+PiBJIG1lYW50IHdlIGhhdmUgb25seSB0aGUgdXNlZnVsIGVu Y2Fwc3VsYXRpb24gaW5mb3JtYXRpb24gZm9yIHRoZSBuZXh0aG9wDQo+Pj4gbGluayBsYXllciBk ZXRhaWxzIC0gbm90IGhvdyBzdWNoIGluZm9ybWF0aW9uIGlzIGdhdGhlcmVkLg0KPj4+IFRoaXMg aW5mb3JtYXRpb24gaXMgaW5kZXhlZCBieSB3aGF0IGkgY2FsbGVkIE5IRW5jYXBJbmZvSW5kZXgg YWJvdmUuDQo+Pj4gVGhpcyB3aWxsIGFsbG93IHNvbWVvbmUgdG8gaW5zdGFsbCBhbGwgdGhlIGRl dGFpbHMgb2YgZHN0bWFjLCBzcmNtYWMgYW5kIFZMQU4NCj4+PiBpbmZvIHdpdGhvdXQgbmVlZGlu ZyBmb3IgRkUgdG8gYmUgYXdhcmUgb2YgQVJQLiBPciBpZiB0aGV5IGRlY2lkZSB0byB1c2UNCj4+ PiBBUlAgd2hlbiB0aGUgcGFja2V0IGdldHMgdG8gdGhhdCBwb2ludCwgdGhlbiB0aGV5IGNhbiBj aG9vc2UgdG8gZG8gc28NCj4+PiAoZXZlbiB0aG91Z2ggaSB0aGluayB0aGF0IGlzIGEgYmFkIGlk ZWEpLg0KPj4+DQo+Pj4+IOKXjyBOZXcgRW5jYXBUYWJsZSBpbiBFdGhlckVuY2FwIExGQiBpbmRl eGVkIGJ5IEVuY2FwT3V0cHV0SW5kZXgNCj4+Pj4gUmU6IEkganVzdCBjYW4gbm90IHVuZGVyc3Rh bmQgd2VsbCBob3cgY2FuIEVuY2FwT3V0cHV0SW5kZXggYmUgdXNlZCBhcyBpbmRleCBmb3I+cGFj a2V0cyB0byBmaW5kIG91dCBlbmNhcCBpbmZvcm1hdGlvbiBmb3IgdGhlIHBhY2tldHM/IENvdWxk IHlvdSBwcm92aWRlIG1vcmUgb24+dGhpcz8gdGhhbmtzLg0KPj4+DQo+Pj4gVGFibGUgbmFtZTog TkhFbmNhcFRhYmxlDQo+Pj4gVGFibGUgaW5kZXg6IE5IRW5jYXBJbmZvSW5kZXgNCj4+PiBUYWJs ZSBlbnRyaWVzIG9wdGlvbiAxOg0KPj4+IGRzdG1hYywgc3JjbWFjLCBvcHRpb25hbCB2bGFuIGlu Zm9ybWF0aW9uDQo+Pj4gb3IgVGFibGUgZW50cmllcyBvcHRpb24gMToNCj4+PiBkc3RtYWMsIEVu Y2FwU3JjSW5kZXgNCj4+PiBhbmQgdGhlbiB1c2UgRW5jYXBTcmNJbmRleCB0byBmaW5kIHNyY21h YyBhbmQgb3B0aW9uYWwgVkxBTiBpbmZvcm1hdGlvbi4NCj4+Pg0KPj4+IEkgaG9wZSB0aGlzIG1h a2VzIHNlbnNlLg0KPj4gV1JlOiBKYW1hbCwgdG8gdGhpcyBwb2ludCwgSSBnZXQgdG8gdW5kZXJz dGFuZCBtb3JlIG9uIHdoYXQgeW91IHRob3VnaHQuDQo+PiBZb3VyIHRob3VnaHQgbWlnaHQgYmU6 DQo+PiAuIExQTSBMRkIgdG8gZmluZCBhbiBOSElEDQo+PiAuTkggTEZCIHVzZXMgdGhlIE5ISUQg dG8gZmluZCBhIHBvcnQgSUQgYW5kIHNvbWUgaW5kZXggKHlvdSBjYWxsIEVuY2FwSW5mb0luZGV4 KQ0KPj4gLiBFbmNhcCBMRkIgdXNlcyB0aGUgaW5kZXggdG8gZmluZCBhbGwgZW5jYXAgaW5mb3Jt YXRpb24sIFdISUxFIGtlZXBpbmcgdGhlIHBvcnQgSUQgdW5jaGFuZ2VkIHRvIG91dHB1dCBwb3J0 IHRvIGRvd25zdHJlYW0gTEZCLg0KPj4NCj4+IFdoaWxlIG91ciBjdXJyZW50IHZlcnNpb24gdXNl cyB0aGUgZm9sbG93aW5nIHN0ZXBzOg0KPj4gLiBMUE0gTEZCIHRvIGZpbmQgYW4gTkhJRA0KPj4g LiBOSCBMRkIgdXNlcyB0aGUgTkhJRCB0byBmaW5kIGEgcG9ydCAgSUQgKGxvZ2ljYWwgcG9ydCBJ RCkNCj4+IC4gRW5jYXAgTEZCIHVzZXMgdGhlIHBvcnQgSUQgdG8gZmluZCBhIG5ldyBvdXRwdXQg bG9naWNhbCBwb3J0IElEIGFuZCBhIFZMQU4gaWQsIHRoZW4gdmlhIHRoZSBvdXRwdXQgbG9naWNh bCBwb3J0IElEIHRvIGZpbmQgbW9yZSBlbmNhcCBpbmZvcm1hdGlvbiBpbiBhbiBBcnBUYWJlbC4g TW9yZW92ZXIsIHRoZSBvdXRwdXQgbG9naWNhbCBwb3J0ICBJRCBpcyBvdXRwdXQgdG8gZG93bnN0 cmVhbSBMRkIuDQo+Pg0KPj4gU28sIHRoZSBrZXkgZGlmZmVyZW5jZSBpcyB3aGF0IHdlIHNoYWxs IGNhbGwgdGhlIElEIGdlbmVyYXRlZCBieSBOSCBMRkIoeW91IGNhbGwgaXQgYW4gaW5kZXgsIHdl IGN1cnJlbnRseSBqdXN0IGNhbGwgaXQgbG9naWNhbCBwb3J0IElEKS4gIEkgcmVtZW1iZXIgd2Ug Y2FsbCBpdCBsb2dpY2FsIHBvcnQgSUQgYmVjYXVzZSBzb21lIEwyIGJyaWRnaW5nIExGQnMgbWF5 IGFsc28gcG9zc2libHkgZ2VuZXJhdGUgdGhpcyBraW5kIG9mIGxvZ2ljYWwgcG9ydCBJRHMgdG8g aW5wdXQgdG8gRXRoZXJlbmNhcCBMRkIgZm9yIGVuY2FwIGluZm9ybWF0aW9uLiBJIG5lZWQgSm9l bC9DaHVhbmh1YW5nIHRvIHZlcmlmeSB0aGlzLg0KPj4NCj4+Pg0KPj4+PiDil48gTm8gSVAgaW5m b3JtYXRpb24gc3RvcmVkDQo+Pj4NCj4+PiBBcyBldmlkZW5jZSBmcm9tIGFib3ZlLCB5b3UgY2Fu IHNlZSBubyBJUCBpbmZvcm1hdGlvbiBuZWVkZWQgYnkNCj4+PiBldGhlcm5ldCBlbmNhcHN1bGF0 b3IuIE5ISVAgaXMgc3RpbGwgcGFzc2VkIGFzIG1ldGFkYXRhIC0gc28gaWYgeW91cg0KPj4+IGlt cGxlbWVudGF0aW9uDQo+Pj4gd2FudHMgdG8gZG8gQVJQIG9yIE5EIHRvIHBvcHVsYXRlIGRzbWFj IGFkZHJlc3MsIHRoZXkgY2FuIGRvIHRoYXQuDQo+Pj4NCj4+Pj4g4pePIE5vIExvZ2ljYWxQb3J0 SUQsIHdlIGFscmVhZHkgaGF2ZSBvbmUgZnJvbSBOSA0KPj4+PiBSZTogSW4gY3VycmVudCBFdGhl ckVuY2FwIExGQiwgd2UndiBkZWZpbmVkIGEgVkxBTiBvdXRwdXQgdGFibGUsIHdoaWNoIGlzIHVz ZWQgZm9yPmEgcGFja2V0IHRvIGZpbmQgb3V0IGFuIG91dHB1dCBsb2dpY2FsIHBvcnQgSUQgYW5k IGEgVmxhbklEIGJ5IGFuIGlucHV0IGxvZ2ljYWwgcG9ydCBJRD53aGljaCBpcyBmcm9tIHVwc3Ry ZWFtIE5IIExGQi4gVGhpcyBtZWFucywgdGhlIGxvZ2ljYWwgcG9ydCBJRCBnZW5lcmF0ZWQgYnk+ TmV4dEhvcCB0YWJsZSBpbiBOSCBpcyBkaWZmZXJlbnQgZnJvbSB0aGUgbG9naWNhbCBwb3J0IElE IGdlbmVyYXRlZCBieSB0aGlzPkV0aGVyRW5jYXAgTEZCLg0KPj4+PiBXZSBkZXNpZ25lZCB0aGlz IGFmdGVyIHNvbWUgZGlzY3Vzc2lvbnMgYmV0d2VlbiBKb2VsIGFuZCBDaHVhbmh1YW5nLiBJIGhv cGUgeW91PiAgdHdvIGd1eXMgY2FuIHByb3ZpZGUgbW9yZSBpbmZvcm1hdGlvbiBvbiB0aGlzIGRl c2lnbi4gVGhhbmtzLg0KPj4+Pg0KPj4+DQo+Pj4gSSBkaWRudCBxdWlldCBmb2xsb3cgdGhlIHJl YXNvbmluZy4NCj4+PiBUaGUgcm91dGUgKExQTStOSCkgcG9pbnRzIHRvIGEgbG9naWNhbCBwb3J0 IHdoZXJlIHRoZSBwYWNrZXQgaXMgdG8gZ28gb3V0LiBEb2VzDQo+Pj4gdGhpcyBtZWFuIHNvbWUg b3RoZXIgcG9saWN5IGRvd25zdHJlYW0gd2lsbCBtYWtlIHRoZSBkZWNpc2lvbiB0byBjaGFuZ2Ug dGhpcz8NCj4+PiBKb2VsL0NodWFuaHVhbmc/DQo+PiBXUmU6IEkgdGhpbmsgdGhpcyBxdWVzdGlv biBoYXMgbGlua2VkIHRvIHRoZSBxdWVzaW9uIG9uZSBhYm92ZS4NCj4+Pg0KPj4+PiDil48gU3Rv cmUgZHN0bWFjIGFuZCBwb3NzaWJseSBhIEVuY2FwU3JjSW5kZXgNCj4+Pj4g4pePIEZpbmQgc3Jj bWFjIGFuZCBWTEFOIGRldGFpbHMgd2l0aGluIEVuY2FwVGFibGUgYnkgb25lLW9mOg0KPj4+PiDi l48gVXNlIHN0b3JlZCBFbmNhcFNyY0luZGV4IHRvIGluZGV4IGFub3RoZXIgc3JjRW5jYXAgdGFi bGUNCj4+Pj4g4pePIFN0b3JlIHNyY21hYyBhbmQgb3B0aW9uYWwgdmxhbiBpbmZvcm1hdGlvbiBp biBFbmNhcFRhYmxlDQo+Pj4+IFJlOiBJJ20gc29ycnkgdGhhdCBJIHN0aWxsIGNhbiBub3QgY2F0 Y2ggdXAgaGVyZSB3ZWxsLiBXaHkgZG9uJ3Qgd2UganVzdCBkZWZpbmUgYSB0YWJsZT5pbiB3aGlj aCBkc3RtYWMgYW5kIHNyY21hYyBhcmUgaW5jbHVkZWQsIGp1c3QgYXMgdGhlIEFycFRhYmxlIGRv ZXMgaW4gY3VycmVudD52ZXJzaW9uIEV0aGVyRW5jYXAgTEZCPw0KPj4+DQo+Pj4gV2UgY291bGQu IFVzaW5nIGFuIGluZGV4IHdpbGwgdXNlIGxlc3MgbWVtb3J5IC0gYnV0IHdlIGNhbiBvcHRpbWl6 ZSBsYXRlci4NCj4+Pg0KPg== From joel@stevecrocker.com Mon Apr 11 08:41:02 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 0A60B3A69AD for ; Mon, 11 Apr 2011 08:41:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.47 X-Spam-Level: X-Spam-Status: No, score=-1.47 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DSL=1.129] 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 iJ+QhPmAwSHf for ; Mon, 11 Apr 2011 08:41:01 -0700 (PDT) Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by core3.amsl.com (Postfix) with ESMTP id E195F3A697E for ; Mon, 11 Apr 2011 08:40:58 -0700 (PDT) Received: from [207.47.24.2] (HELO [172.17.114.244]) by execdsl.com (CommuniGate Pro SMTP 5.1.16) with ESMTPS id 19546713; Mon, 11 Apr 2011 15:41:13 +0000 Message-ID: <4DA32104.4070601@stevecrocker.com> Date: Mon, 11 Apr 2011 11:40:52 -0400 From: Joel 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: <4DA317B9.9040604@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Joel M. Halpern" , Chuanhuang Li , forces@ietf.org Subject: Re: [forces] LFB LPM issue 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, 11 Apr 2011 15:41:02 -0000 Lets trace it out: The Longest Prefix Match (LPM) LFB looks up the destination IP address, and profuces a next hop index. the packet is then sent to the Next Hop (NH) LFB. The NH LFB uses the next hop index to pick up several pieces of information. this includes the next hop IP address (if any), the output index for the group port, used locally to select which next LFB to send the packet to, and an encapsulation index metadata, and a logical output port ID. Note1: at this stage, this is a logical port as seen by L3 processing. Eventually, the packet arrives at a media specific encapsulator. Let us assume that ARP information is all filled in. The media encapsulator knows how to add the proper header to the packet, and send it onward. Note2: If we want to design to allow a single instance of the media encapsulator to handle multiple L3 output ports, then we use the output port index as well as the encapsualtion index as table indicies. If each Media encapsulation LFB instance handles only one L3 output port, then only the encapsulation index is used as the table index. Note3: To allow for different ways of handling ARP, I would define the table here to have an indication if the entry is unfilled. If a packet arrives with an encapsulation index pointing to an unfilled entry, then it needs to be sent for ARP processing (either an APR LFB or the CE...) One of the things the media encapsulator has to do is to cope with the fact that there may be L2 bridging under the L3 port. As such, the output port ID may be refined / replaced with a more specific valuye by this processing. Note 4: The NH LFB can not do this refinement because it operates above the level where this is visible. Yours, Joel On 4/11/2011 11:25 AM, Jamal Hadi Salim wrote: > Hi Joel, > > On Mon, Apr 11, 2011 at 11:01 AM, Joel M. Halpern wrote: >> The NH LFB needs to generate both a port ID and an encapsulation index. >> >> The encapsulation index does not select the port, as each port has its own >> encapsulation table (conceptually. Implementation-wise we may design the >> LFB to use both indices if you want.) >> >> If the output port selected by the NH LFB is actually a bridged port, then >> the encapsualtion information will also need to provide a more specific >> output port. Normally, it will be the same output port index as the input >> port index. >> > So you have a two level mux? i.e > a) Selection encapsulation table (type?) - in current case Ethernet > b) Select port which may have its own encap table. > > The discussion with Weiming is what to select within an encap table > (my suggestion of a new index) i.e while two packets may go out > the same port, they may use different src/dstmac as well as VLAN info. > > cheers, > jamal > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces From chuanhuang_li@mail.zjgsu.edu.cn Mon Apr 11 09:52:56 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 7BC4F28C147 for ; Mon, 11 Apr 2011 09:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.374 X-Spam-Level: *** X-Spam-Status: No, score=3.374 tagged_above=-999 required=5 tests=[AWL=-2.276, BAYES_00=-2.599, FROM_EXCESS_BASE64=1.456, J_CHICKENPOX_21=0.6, J_CHICKENPOX_24=0.6, J_CHICKENPOX_25=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_29=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_47=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_53=0.6, MIME_BASE64_BLANKS=0.041, SARE_SUB_ENC_UTF8=0.152] 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 pBFvnvgC973x for ; Mon, 11 Apr 2011 09:52:55 -0700 (PDT) Received: from mail.zjgsu.edu.cn (ucmail.zjgsu.edu.cn [124.160.64.1]) by core3.amsl.com (Postfix) with SMTP id 962583A6A72 for ; Mon, 11 Apr 2011 09:52:53 -0700 (PDT) Received: from RobinLee (unknown [10.20.0.167]) by mailportal (Coremail) with SMTP id rBCI85Driy3IL6NNQEIPAA--.53074S2; Tue, 12 Apr 2011 00:43:52 +0800 (CST) Date: Tue, 12 Apr 2011 00:52:58 +0800 From: "=?utf-8?B?Q2h1YW5odWFuZyBMaQ==?=" To: "=?utf-8?B?V2FuZyxXZWltaW5n?=" , "=?utf-8?B?Sm9lbCBNLiBIYWxwZXJu?=" References: , , , <4DA317B9.9040604@joelhalpern.com> Message-ID: <201104120052581097823@mail.zjgsu.edu.cn> Organization: =?utf-8?B?WmhlamlhbmcgR29uZ3NoYW5nIFVuaXZlcmNpdHk=?= X-mailer: Foxmail 6, 15, 201, 23 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-CM-TRANSID: rBCI85Driy3IL6NNQEIPAA--.53074S2 X-Coremail-Antispam: 1Uf129KBjDUn29KB7ZKAUJUUUUUYxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJ3UbIYCTnIWIevJa73UjIFyTuYvj4RJUUUUUUUU X-CM-SenderInfo: pfkxt0xkxd0wxbolqzhdloh6pmjv3hxhgxhubq/ Cc: =?utf-8?B?Zm9yY2VzQGlldGYub3Jn?= Subject: Re: [forces] =?utf-8?q?LFB_LPM_issue?= 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, 11 Apr 2011 16:52:56 -0000 SGksIEFsbA0KDQpJIGtub3cgd2hhdCBKYW1hbCBoYWQgc3VnZ2VzdGVkLiBJbiB0aGF0IGNhc2Us IHRoZSAiTkhFbmNhcEluZm9JbmRleCIgaXMgbm90IA0KdGhlIHNhbWUgYXMgIkVuY2FwT3V0cHV0 SW5kZXgiIHdoaWNoIHdlIGhhdmUgY3VycmVudGx5IGRlZmluZWQgaW4gTkggdGFibGUuICANCiJO SEVuY2FwSW5mb0luZGV4IiB3aWxsIGJlIHVzZWQgZm9yIHRoZSBzZWxlY3Rpb24gb2YgZGlmZmVy ZW50IGVudHJ5IGluIEVuY2FwIFRhYmxlIA0KaW4gRXRoZXJFbmNhcCBMRkIuICJFbmNhcE91dHB1 dEluZGV4IiBpcyBzdGlsbCBmb3IgdGhlIHNlbGVjdGlvbiBvZiBkaWZmZXJlbnQgT3V0cHV0IA0K UG9ydCBpbiBOSCBMRkIuDQoNCkJ1dCBJIGhhdmUgc29tZSB3b3JyaWVzOg0KMTpBY2NvcmRpbmcg SmFtYWwncyBzdWdnZXN0aW9uLCB3ZSBuZWVkIGRlZmluZSBib3RoIG9mIHRoZXNlIHR3byBpbmRl eCBpbiBOSCB0YWJsZS4gDQpUaGlzIHdpbGwgbWFrZSB0aGUgbG9naWMgb2YgTkggTEZCIGNvbXBs aWNhdGVkLCBiZWNhdXNlIE5IIG5lZWQgdG8ga25vdyBzb21lIGRldGFpbGVkIA0KdGhpbmdzIG9m IGl0J3MgZm9sbG93ZWQgTEZCcy4gDQoyOlRvIHRoZSBwYWNrZXQgbmVlZGVkIHRvIGJlIGZvcndh cmRlZCB0byBsb2NhbCBzdWJuZXQgaG9zdCwgdGhlIHJvdXRpbmcgdGFibGUoTFBNK05IKSANCm5l ZWQgb25lIGVudHJ5IGZvciBvbmUgc3VibmV0IGhvc3QuKE93aW5nIHRvIHRoZSBzZWFyY2hpbmcg a2V5IGlzIE5IRW5jYXBJbmZvSW5kZXggaW4gDQpFbmNhcCB0YWJsZS4pLiBUaGVuLCBpZiB0aGUg c3VibmV0IGlzIGxhcmdlLCB0aGUgcm91dGluZyB0YWJsZSBpcyBhbHNvIGxhcmdlci4gIA0KIEN1 cnJlbnQgcmVzb2x1dGlvbjogVGhpcyBpcyBpbmRpY2F0ZWQgYnkgIk5leHRob3BPcHRpb24iICBp biBOSCB0YWJsZShPbmUgc3VibmV0IG9ubHkgbmVlZCANCm9uZSBlbnRyeSkuICBJZiB0aGUgcGFj a2V0IGlzIGZvciB0aGUgc3VibmV0IGhvc3QsIHRoZSBtZXRhZGF0YSAiTmV4dGhvcElQdjRBZGRy IiB3aWxsIA0KYmUgY2hhbmdlZCB0byBpdCdzIGRlc3RpbmF0aW9uIElQIGFkZHJlc3MuIEluIEV0 aGVyRW5jYXAsIGJ5IHVzaW5nIHRoaXMgSVAgYWRkcmVzcyhzZWFyY2hpbmcga2V5KSwgDQp0aGUg cGFja2V0IGNhbiBmb3VuZCBvdXQgaXQncyBlbmNhcHN1bGF0aW9uIGluZm9ybWF0aW9uLiANCjM6 QWxzbywgaWYgd2UgZGVmaW5lICJOSEVuY2FwSW5mb0luZGV4IiwgdGhlICJOZXh0aG9wSVBBZGRy IiBkZWZpbmVkIGluIE5IIHRhYmxlIG1heSBiZSBubyANCnVzZWZ1bCBpbiB0aGUgZm9sbG93ZWQg TEZCcy4NCg0KcHM6IEluIG15IG1pbmQsIEFsdGhvdWdoIHdlIHdpbGwgbm90IGRlZmluZSBBUlAv TkQgTEZCIGluIGN1cnJlbnQgdmVyc2lvbiBsaWIsIEkgdGhpbmsgaXQgaXMgbm90IA0KbWVhbiB3 ZSBzaG91bGQgYXZvaWQgZXZlcnl0aGluZyBhYm91dCB0aGVtIGluIHRoZSBvdGhlciBMRkIncyBk ZWZpbml0aW9uLiANCg0KWW91cnMsDQpDaHVhbmh1YW5nCQ0KDQo9PT09PT09IDIwMTEtMDQtMTEg MjM6MjE6NDggV2FuZyxXZWltaW5nLCB3cm90ZTogPT09PT09PQ0KDQo+Sm9lbCwgDQo+DQo+T24g dGhlIGVuY2Fwc3VsYXRpb24gaW5kZXgsIEkgdGhpbmsgd2UgaGF2ZSByZWFjaGVkIGEgY29uc2Vu c3VzIHRoYXQgdGhlIGluZGV4IGlzIGFzIGEgcG9ydCBzZWxlY3RvciBmb3IgTkggTEZCIGdyb3Vw IG91dHB1dC4gSSBqdXN0IGNoZWNrZWQgdGhlIG1lc3NhZ2VzIGFzIHRoZSBmb2xsb3dpbmcgdGlt ZSBhZ2FpbjoNCj4NCj5TZW50OiBGcmlkYXksIFNlcHRlbWJlciAxMCwgMjAxMCA4OjM3IFBNDQo+ U3ViamVjdDogUmU6IERlZmluaXRpb24gb2YgSVB2NE5leHRIb3BBcHBsaWNhdG9yIExGQg0KPg0K PlNlbnQ6IFNhdHVyZGF5LCBTZXB0ZW1iZXIgMTEsIDIwMTAgMTI6NTcgQU0NCj5TdWJqZWN0OiBS ZTogRGVmaW5pdGlvbiBvZiBJUHY0TmV4dEhvcEFwcGxpY2F0b3IgTEZCDQo+DQo+dGhhbmtzLA0K PldlaW1pbmcNCj4NCj4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KPkZyb206ICJKb2Vs IE0uIEhhbHBlcm4iIDxqbWhAam9lbGhhbHBlcm4uY29tPg0KPg0KPj4gVGhlIE5IIExGQiBuZWVk cyB0byBnZW5lcmF0ZSBib3RoIGEgcG9ydCBJRCBhbmQgYW4gZW5jYXBzdWxhdGlvbiBpbmRleC4N Cj4+IA0KPj4gVGhlIGVuY2Fwc3VsYXRpb24gaW5kZXggZG9lcyBub3Qgc2VsZWN0IHRoZSBwb3J0 LCBhcyBlYWNoIHBvcnQgaGFzIGl0cyANCj4+IG93biBlbmNhcHN1bGF0aW9uIHRhYmxlIChjb25j ZXB0dWFsbHkuICBJbXBsZW1lbnRhdGlvbi13aXNlIHdlIG1heSANCj4+IGRlc2lnbiB0aGUgTEZC IHRvIHVzZSBib3RoIGluZGljZXMgaWYgeW91IHdhbnQuKQ0KPj4gDQo+PiBJZiB0aGUgb3V0cHV0 IHBvcnQgc2VsZWN0ZWQgYnkgdGhlIE5IIExGQiBpcyBhY3R1YWxseSBhIGJyaWRnZWQgcG9ydCwg DQo+PiB0aGVuIHRoZSBlbmNhcHN1YWx0aW9uIGluZm9ybWF0aW9uIHdpbGwgYWxzbyBuZWVkIHRv IHByb3ZpZGUgYSBtb3JlIA0KPj4gc3BlY2lmaWMgb3V0cHV0IHBvcnQuICBOb3JtYWxseSwgaXQg d2lsbCBiZSB0aGUgc2FtZSBvdXRwdXQgcG9ydCBpbmRleCANCj4+IGFzIHRoZSBpbnB1dCBwb3J0 IGluZGV4Lg0KPj4gDQo+PiBZb3VycywNCj4+IEpvZWwNCj4+IA0KPj4gT24gNC8xMS8yMDExIDEw OjQ4IEFNLCBXYW5nLFdlaW1pbmcgd3JvdGU6DQo+Pj4gSGkgSmFtYWwsIG1vcmUgcmVwbHkgaW5s aW5lLg0KPj4+DQo+Pj4gdGhhbmtzLA0KPj4+IFdlaW1pbmcNCj4+PiAtLS0tLSBPcmlnaW5hbCBN ZXNzYWdlIC0tLS0tDQo+Pj4gRnJvbTogIkphbWFsIEhhZGkgU2FsaW0iPGhhZGlAbW9qYXRhdHUu Y29tPg0KPj4+Pj4gLS0tLS0NCj4+Pj4+IOKXjyBOSCBvdXRwdXRzIGFzIHBhcnQgb2YgbWV0YWRh dGEgRW5jYXBPdXRwdXRJbmRleA0KPj4+Pj4g4pePQWxyZWFkeSBhdmFpbGFibGUsIGp1c3Qgbm90 IHVzZWQgY3VycmVudGx5DQo+Pj4+DQo+Pj4+PiBSZTogaW4gY3VycmVudCB2ZXJzaW9uIG9mIE5I IExGQiwgdGhlIEVuY2FwT3V0cHV0SW5kZXggaXMgdXNlZCBieSB0aGlzIE5IIExGQj5pdHNlbGYg dG8gc2VsZWN0IHRoZSBvdXRwdXQgZnJvbSB0aGUgb3V0cHV0IGdyb3VwLiBGb3IgaW5zdGFuY2Us IGlmIHRoZSBncm91cCBvdXRwdXQgMSBpcz5jb25uZWN0ZWQgdG8gYSBkb3duc3RyZWFtIEV0aGVy RW5jYXAgTEZCLCB0aGVuIHRoZSBwYWNrZXRzIHdpdGggdGhlPkVuY2FwT3V0cHV0SW5kZXggYXNz aWduZWQgdG8gMSBtZWFucyB0byBvdXRwdXQgdG8gYW4gRXRoZXIgZW5jYXBzdWxhdG9yLg0KPj4+ Pj4NCj4+Pj4+IEknbSBub3Qgc3VyZSBpZiB5b3UgbWVhbiB0byBkZWZpbmUgdGhpcyBFbmNhcE91 dHB1dEluZGV4IGFzIGEgbWV0YWRhdGEgb3V0cHV0IHZpYT50aGUgTkggb3V0cHV0IHBvcnQ/IGlm IHNvLCBob3cgY2FuIHdlIGRpc3Rpbmd1aXNoIGRpZmZlcmVudCBlbmNhcHN1bGF0b3JzIGZvbGxv d2VkLD5zYXlpbmcgd2UgaGF2ZSBvdGhlciBlbmNhcHN1bGF0aW9ucyBvdGhlciB0aGFuIEV0aGVy bmV0IGZvbGxvd2VkLg0KPj4+Pj4NCj4+Pj4NCj4+Pj4gSSBtaXN1bmRlcnN0b29kIHRoZSBtZWFu aW5nIG9mIHRoYXQgaW5kZXggYmVjYXVzZSBJIGRvbnQgdGhpbmsgd2hhdA0KPj4+PiB5b3UganVz dCBkZXNjcmliZWQgYWJvdmUgaXMgaW4gdGhlIHRleHQgb2YgdGhlIGRyYWZ0Lg0KPj4+PiBBbSBp IG1pc3Rha2VuPyBJZiBpIGFtIG5vdCwgdGhlbiBwbGVhc2UgYWRkIHRvIHRoZSBUT0RPIGxpc3QN Cj4+Pj4gc3VjaCBhbiBleHBsYW5hdGlvbi4gQWxzbywgbWF5YmUgc29tZXdoZXJlIHdlIG5lZWQg dG8gc2F5IHRoYXQNCj4+Pj4gdGhlIGRlc2lnbiBjaG9pY2VzIG9mIHRoZSBMRkJzIGlzIHNvIHRo YXQgd2UgY2FuIGhhdmUgZ2VuZXJpY2l0eSBpbg0KPj4+PiBMaW5rIGxheWVycyAoYWx0aG91Z2gg d2UgY3VycmVudGx5IG9ubHkgZm9jdXMgb24gRXRoZXJuZXQpIGFzIGV2aWRlbmNlZA0KPj4+PiBi eSB0aGUgcHJlc2VuY2Ugb2YgRW5jYXBPdXRwdXRJbmRleC4NCj4+Pg0KPj4+IFdSZTogSmFtYWws IDUuMy4yLiAgSVB2NE5leHRIb3Agc2VjdGlvbiBoYXMgZGVzY3JpYmVkIHRoZSB1c2Ugb2YgdGhl IEluZGV4LCBwbHMgY2hlY2sgcC41MCBvZiBMRkIgbGliIHYzLCBhbHRob3VnaCBtb3JlIHdvcmRz IG1heSBiZSBhZGRlZCB0byBzdGF0ZSB0aGUgZ2VuZXJpY2l0eSBpbiBsaW5rIGxheWVycy4NCj4+ Pg0KPj4+Pg0KPj4+PiBIYXZpbmcgc2FpZCB0aGF0Og0KPj4+PiBXaGF0IGkgbWVhbnQgaXMgd2Ug bmVlZCBzb21lIGluZGV4IHdoaWNoIGlzIG91dHB1dCBhcyBtZXRhZGF0YSBmcm9tIE5ILg0KPj4+ PiBUaGUgdmFsdWUgb2YgdGhpcyBtZXRhZGF0YSB3aWxsIGJlIHVzZWQgdG8gaW5kZXggaW50byBh IHRhYmxlIGluIHRoZQ0KPj4+PiBFdGhlciBlbmNhcHN1bGF0b3IuIEkgY2FsbGVkIGl0IEVuY2Fw T3V0cHV0SW5kZXggYnV0IGNoYW5nZSBpdHMNCj4+Pj4gbmFtZSB0byBzb21ldGhpbmcgZWxzZS4g Rm9yIGV4YW1wbGUsIGxldHMgY2FsbCBpdCBOSEVuY2FwSW5mb0luZGV4DQo+Pj4gV1JlOiBjdXJy ZW50bHkgd2UgaGF2ZSB1c2VkIHRoZSBsb2dpY2FsIHBvcnQgSUQgYXMgdGhlIG1ldGFkYXRhIG91 dHB1dCBieSB0aGUgTkggTEZCIHRvIGluZGV4IHRoZSB0YWJsZSBpbiBFdGhlcmVuY2FwIExGQi4g SSdtIG5vdCBzdXJlIGlmIHlvdSBtZWFuIHRoaXMga2luZCBvZiBpbmRleCwgb3IgdG90YWxseSBv dGhlciBvbmU/DQo+Pj4NCj4+Pj4NCj4+Pj4+IOKXj0FSUC9ORCByZXNvbHV0aW9uIHJlbW92ZWQN Cj4+Pj4+IFJlOiBub3Qgc3VyZSB0aGUgZGV0YWlscywgeW91IG1lYW4gdGhlIEFSUC9ORCBmdW5j dGlvbiB3aWxsIGJlIGluY2x1ZGVkIGluIHRoZSBFdGhlckVuY2FwIExGQj8NCj4+Pj4+DQo+Pj4+ PiDil48gRXRoZXJFbmNhcCBpcyBub3QgYXdhcmUgb2YgSVBWNCBvciBWNg0KPj4+Pj4gUmU6IFll cywgY3VycmVudCB2ZXJzaW9uIG9mIEV0aGVyRW5jYXAgaW5jbHVkZXMgSVB2NCBhbmQgdjYuDQo+ Pj4+Pg0KPj4+Pj4g4pePIFVwIHRvIGltcGxlbWVudGF0aW9uIGlmIElQIGlzIGlnbm9yZWQgb3Ig aG93IGl0IGlzIHVzZWQgKEFSUC9ORCkNCj4+Pj4+IFJlOiBjb3VsZCB0aGlzIGJlIGRlc2NyaWJl ZCBtb3JlPyBJIGp1c3QgY2FuIG5vdCBjYXRjaCB1cCB3ZWxsIHdpdGggd2hhdCBpdCBtZWFucyBi ZWhpbmQuDQo+Pj4+Pg0KPj4+Pg0KPj4+PiBJIG1lYW50IHdlIGhhdmUgb25seSB0aGUgdXNlZnVs IGVuY2Fwc3VsYXRpb24gaW5mb3JtYXRpb24gZm9yIHRoZSBuZXh0aG9wDQo+Pj4+IGxpbmsgbGF5 ZXIgZGV0YWlscyAtIG5vdCBob3cgc3VjaCBpbmZvcm1hdGlvbiBpcyBnYXRoZXJlZC4NCj4+Pj4g VGhpcyBpbmZvcm1hdGlvbiBpcyBpbmRleGVkIGJ5IHdoYXQgaSBjYWxsZWQgTkhFbmNhcEluZm9J bmRleCBhYm92ZS4NCj4+Pj4gVGhpcyB3aWxsIGFsbG93IHNvbWVvbmUgdG8gaW5zdGFsbCBhbGwg dGhlIGRldGFpbHMgb2YgZHN0bWFjLCBzcmNtYWMgYW5kIFZMQU4NCj4+Pj4gaW5mbyB3aXRob3V0 IG5lZWRpbmcgZm9yIEZFIHRvIGJlIGF3YXJlIG9mIEFSUC4gT3IgaWYgdGhleSBkZWNpZGUgdG8g dXNlDQo+Pj4+IEFSUCB3aGVuIHRoZSBwYWNrZXQgZ2V0cyB0byB0aGF0IHBvaW50LCB0aGVuIHRo ZXkgY2FuIGNob29zZSB0byBkbyBzbw0KPj4+PiAoZXZlbiB0aG91Z2ggaSB0aGluayB0aGF0IGlz IGEgYmFkIGlkZWEpLg0KPj4+Pg0KPj4+Pj4g4pePIE5ldyBFbmNhcFRhYmxlIGluIEV0aGVyRW5j YXAgTEZCIGluZGV4ZWQgYnkgRW5jYXBPdXRwdXRJbmRleA0KPj4+Pj4gUmU6IEkganVzdCBjYW4g bm90IHVuZGVyc3RhbmQgd2VsbCBob3cgY2FuIEVuY2FwT3V0cHV0SW5kZXggYmUgdXNlZCBhcyBp bmRleCBmb3I+cGFja2V0cyB0byBmaW5kIG91dCBlbmNhcCBpbmZvcm1hdGlvbiBmb3IgdGhlIHBh Y2tldHM/IENvdWxkIHlvdSBwcm92aWRlIG1vcmUgb24+dGhpcz8gdGhhbmtzLg0KPj4+Pg0KPj4+ PiBUYWJsZSBuYW1lOiBOSEVuY2FwVGFibGUNCj4+Pj4gVGFibGUgaW5kZXg6IE5IRW5jYXBJbmZv SW5kZXgNCj4+Pj4gVGFibGUgZW50cmllcyBvcHRpb24gMToNCj4+Pj4gZHN0bWFjLCBzcmNtYWMs IG9wdGlvbmFsIHZsYW4gaW5mb3JtYXRpb24NCj4+Pj4gb3IgVGFibGUgZW50cmllcyBvcHRpb24g MToNCj4+Pj4gZHN0bWFjLCBFbmNhcFNyY0luZGV4DQo+Pj4+IGFuZCB0aGVuIHVzZSBFbmNhcFNy Y0luZGV4IHRvIGZpbmQgc3JjbWFjIGFuZCBvcHRpb25hbCBWTEFOIGluZm9ybWF0aW9uLg0KPj4+ Pg0KPj4+PiBJIGhvcGUgdGhpcyBtYWtlcyBzZW5zZS4NCj4+PiBXUmU6IEphbWFsLCB0byB0aGlz IHBvaW50LCBJIGdldCB0byB1bmRlcnN0YW5kIG1vcmUgb24gd2hhdCB5b3UgdGhvdWdodC4NCj4+ PiBZb3VyIHRob3VnaHQgbWlnaHQgYmU6DQo+Pj4gLiBMUE0gTEZCIHRvIGZpbmQgYW4gTkhJRA0K Pj4+IC5OSCBMRkIgdXNlcyB0aGUgTkhJRCB0byBmaW5kIGEgcG9ydCBJRCBhbmQgc29tZSBpbmRl eCAoeW91IGNhbGwgRW5jYXBJbmZvSW5kZXgpDQo+Pj4gLiBFbmNhcCBMRkIgdXNlcyB0aGUgaW5k ZXggdG8gZmluZCBhbGwgZW5jYXAgaW5mb3JtYXRpb24sIFdISUxFIGtlZXBpbmcgdGhlIHBvcnQg SUQgdW5jaGFuZ2VkIHRvIG91dHB1dCBwb3J0IHRvIGRvd25zdHJlYW0gTEZCLg0KPj4+DQo+Pj4g V2hpbGUgb3VyIGN1cnJlbnQgdmVyc2lvbiB1c2VzIHRoZSBmb2xsb3dpbmcgc3RlcHM6DQo+Pj4g LiBMUE0gTEZCIHRvIGZpbmQgYW4gTkhJRA0KPj4+IC4gTkggTEZCIHVzZXMgdGhlIE5ISUQgdG8g ZmluZCBhIHBvcnQgIElEIChsb2dpY2FsIHBvcnQgSUQpDQo+Pj4gLiBFbmNhcCBMRkIgdXNlcyB0 aGUgcG9ydCBJRCB0byBmaW5kIGEgbmV3IG91dHB1dCBsb2dpY2FsIHBvcnQgSUQgYW5kIGEgVkxB TiBpZCwgdGhlbiB2aWEgdGhlIG91dHB1dCBsb2dpY2FsIHBvcnQgSUQgdG8gZmluZCBtb3JlIGVu Y2FwIGluZm9ybWF0aW9uIGluIGFuIEFycFRhYmVsLiBNb3Jlb3ZlciwgdGhlIG91dHB1dCBsb2dp Y2FsIHBvcnQgIElEIGlzIG91dHB1dCB0byBkb3duc3RyZWFtIExGQi4NCj4+Pg0KPj4+IFNvLCB0 aGUga2V5IGRpZmZlcmVuY2UgaXMgd2hhdCB3ZSBzaGFsbCBjYWxsIHRoZSBJRCBnZW5lcmF0ZWQg YnkgTkggTEZCKHlvdSBjYWxsIGl0IGFuIGluZGV4LCB3ZSBjdXJyZW50bHkganVzdCBjYWxsIGl0 IGxvZ2ljYWwgcG9ydCBJRCkuICBJIHJlbWVtYmVyIHdlIGNhbGwgaXQgbG9naWNhbCBwb3J0IElE IGJlY2F1c2Ugc29tZSBMMiBicmlkZ2luZyBMRkJzIG1heSBhbHNvIHBvc3NpYmx5IGdlbmVyYXRl IHRoaXMga2luZCBvZiBsb2dpY2FsIHBvcnQgSURzIHRvIGlucHV0IHRvIEV0aGVyZW5jYXAgTEZC IGZvciBlbmNhcCBpbmZvcm1hdGlvbi4gSSBuZWVkIEpvZWwvQ2h1YW5odWFuZyB0byB2ZXJpZnkg dGhpcy4NCj4+Pg0KPj4+Pg0KPj4+Pj4g4pePIE5vIElQIGluZm9ybWF0aW9uIHN0b3JlZA0KPj4+ Pg0KPj4+PiBBcyBldmlkZW5jZSBmcm9tIGFib3ZlLCB5b3UgY2FuIHNlZSBubyBJUCBpbmZvcm1h dGlvbiBuZWVkZWQgYnkNCj4+Pj4gZXRoZXJuZXQgZW5jYXBzdWxhdG9yLiBOSElQIGlzIHN0aWxs IHBhc3NlZCBhcyBtZXRhZGF0YSAtIHNvIGlmIHlvdXINCj4+Pj4gaW1wbGVtZW50YXRpb24NCj4+ Pj4gd2FudHMgdG8gZG8gQVJQIG9yIE5EIHRvIHBvcHVsYXRlIGRzbWFjIGFkZHJlc3MsIHRoZXkg Y2FuIGRvIHRoYXQuDQo+Pj4+DQo+Pj4+PiDil48gTm8gTG9naWNhbFBvcnRJRCwgd2UgYWxyZWFk eSBoYXZlIG9uZSBmcm9tIE5IDQo+Pj4+PiBSZTogSW4gY3VycmVudCBFdGhlckVuY2FwIExGQiwg d2UndiBkZWZpbmVkIGEgVkxBTiBvdXRwdXQgdGFibGUsIHdoaWNoIGlzIHVzZWQgZm9yPmEgcGFj a2V0IHRvIGZpbmQgb3V0IGFuIG91dHB1dCBsb2dpY2FsIHBvcnQgSUQgYW5kIGEgVmxhbklEIGJ5 IGFuIGlucHV0IGxvZ2ljYWwgcG9ydCBJRD53aGljaCBpcyBmcm9tIHVwc3RyZWFtIE5IIExGQi4g VGhpcyBtZWFucywgdGhlIGxvZ2ljYWwgcG9ydCBJRCBnZW5lcmF0ZWQgYnk+TmV4dEhvcCB0YWJs ZSBpbiBOSCBpcyBkaWZmZXJlbnQgZnJvbSB0aGUgbG9naWNhbCBwb3J0IElEIGdlbmVyYXRlZCBi eSB0aGlzPkV0aGVyRW5jYXAgTEZCLg0KPj4+Pj4gV2UgZGVzaWduZWQgdGhpcyBhZnRlciBzb21l IGRpc2N1c3Npb25zIGJldHdlZW4gSm9lbCBhbmQgQ2h1YW5odWFuZy4gSSBob3BlIHlvdT4gIHR3 byBndXlzIGNhbiBwcm92aWRlIG1vcmUgaW5mb3JtYXRpb24gb24gdGhpcyBkZXNpZ24uIFRoYW5r cy4NCj4+Pj4+DQo+Pj4+DQo+Pj4+IEkgZGlkbnQgcXVpZXQgZm9sbG93IHRoZSByZWFzb25pbmcu DQo+Pj4+IFRoZSByb3V0ZSAoTFBNK05IKSBwb2ludHMgdG8gYSBsb2dpY2FsIHBvcnQgd2hlcmUg dGhlIHBhY2tldCBpcyB0byBnbyBvdXQuIERvZXMNCj4+Pj4gdGhpcyBtZWFuIHNvbWUgb3RoZXIg cG9saWN5IGRvd25zdHJlYW0gd2lsbCBtYWtlIHRoZSBkZWNpc2lvbiB0byBjaGFuZ2UgdGhpcz8N Cj4+Pj4gSm9lbC9DaHVhbmh1YW5nPw0KPj4+IFdSZTogSSB0aGluayB0aGlzIHF1ZXN0aW9uIGhh cyBsaW5rZWQgdG8gdGhlIHF1ZXNpb24gb25lIGFib3ZlLg0KPj4+Pg0KPj4+Pj4g4pePIFN0b3Jl IGRzdG1hYyBhbmQgcG9zc2libHkgYSBFbmNhcFNyY0luZGV4DQo+Pj4+PiDil48gRmluZCBzcmNt YWMgYW5kIFZMQU4gZGV0YWlscyB3aXRoaW4gRW5jYXBUYWJsZSBieSBvbmUtb2Y6DQo+Pj4+PiDi l48gVXNlIHN0b3JlZCBFbmNhcFNyY0luZGV4IHRvIGluZGV4IGFub3RoZXIgc3JjRW5jYXAgdGFi bGUNCj4+Pj4+IOKXjyBTdG9yZSBzcmNtYWMgYW5kIG9wdGlvbmFsIHZsYW4gaW5mb3JtYXRpb24g aW4gRW5jYXBUYWJsZQ0KPj4+Pj4gUmU6IEknbSBzb3JyeSB0aGF0IEkgc3RpbGwgY2FuIG5vdCBj YXRjaCB1cCBoZXJlIHdlbGwuIFdoeSBkb24ndCB3ZSBqdXN0IGRlZmluZSBhIHRhYmxlPmluIHdo aWNoIGRzdG1hYyBhbmQgc3JjbWFjIGFyZSBpbmNsdWRlZCwganVzdCBhcyB0aGUgQXJwVGFibGUg ZG9lcyBpbiBjdXJyZW50PnZlcnNpb24gRXRoZXJFbmNhcCBMRkI/DQo+Pj4+DQo+Pj4+IFdlIGNv dWxkLiBVc2luZyBhbiBpbmRleCB3aWxsIHVzZSBsZXNzIG1lbW9yeSAtIGJ1dCB3ZSBjYW4gb3B0 aW1pemUgbGF0ZXIuDQo+Pj4+DQo+Pg0K From joel@stevecrocker.com Mon Apr 11 11:27: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 B70B03A6A47 for ; Mon, 11 Apr 2011 11:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.87 X-Spam-Level: X-Spam-Status: No, score=-0.87 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HELO_EQ_DSL=1.129, J_CHICKENPOX_47=0.6, J_CHICKENPOX_53=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 QTIwW2LTevvC for ; Mon, 11 Apr 2011 11:27:22 -0700 (PDT) Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by core3.amsl.com (Postfix) with ESMTP id 217293A6A09 for ; Mon, 11 Apr 2011 11:27:22 -0700 (PDT) Received: from [129.192.147.67] (HELO [10.154.180.122]) by execdsl.com (CommuniGate Pro SMTP 5.1.16) with ESMTPS id 19547224; Mon, 11 Apr 2011 18:27:37 +0000 Message-ID: <4DA34802.6050502@stevecrocker.com> Date: Mon, 11 Apr 2011 14:27:14 -0400 From: Joel 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: Chuanhuang Li References: , , , <4DA317B9.9040604@joelhalpern.com> <201104120052581097823@mail.zjgsu.edu.cn> In-Reply-To: <201104120052581097823@mail.zjgsu.edu.cn> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "Joel M. Halpern" , "forces@ietf.org" Subject: Re: [forces] LFB LPM issue 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, 11 Apr 2011 18:27:22 -0000 I am not following your concerns. The CE will populate the indices. It knows what index it assigns to the specific next hop, and manages the table. There is no "coordiantion" between LFBs that causes problems. The local hosts are an interesting question. I can imagien various design change sto keep that simple, if we want to do so. (For example, we could have special entries in the enxt hop table that mean "local subnet", and use a single next hop index for those, and have the next hop LFB look at the ARP / ND table.) Yours, Joel On 4/11/2011 12:52 PM, Chuanhuang Li wrote: > Hi, All > > I know what Jamal had suggested. In that case, the "NHEncapInfoIndex" is not > the same as "EncapOutputIndex" which we have currently defined in NH table. > "NHEncapInfoIndex" will be used for the selection of different entry in Encap Table > in EtherEncap LFB. "EncapOutputIndex" is still for the selection of different Output > Port in NH LFB. > > But I have some worries: > 1:According Jamal's suggestion, we need define both of these two index in NH table. > This will make the logic of NH LFB complicated, because NH need to know some detailed > things of it's followed LFBs. > 2:To the packet needed to be forwarded to local subnet host, the routing table(LPM+NH) > need one entry for one subnet host.(Owing to the searching key is NHEncapInfoIndex in > Encap table.). Then, if the subnet is large, the routing table is also larger. > Current resolution: This is indicated by "NexthopOption" in NH table(One subnet only need > one entry). If the packet is for the subnet host, the metadata "NexthopIPv4Addr" will > be changed to it's destination IP address. In EtherEncap, by using this IP address(searching key), > the packet can found out it's encapsulation information. > 3:Also, if we define "NHEncapInfoIndex", the "NexthopIPAddr" defined in NH table may be no > useful in the followed LFBs. > > ps: In my mind, Although we will not define ARP/ND LFB in current version lib, I think it is not > mean we should avoid everything about them in the other LFB's definition. > > Yours, > Chuanhuang > > ======= 2011-04-11 23:21:48 Wang,Weiming, wrote: ======= ... From hadi@mojatatu.com Mon Apr 11 16:05:04 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8C782E06BF for ; Mon, 11 Apr 2011 16:05:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.148 X-Spam-Level: X-Spam-Status: No, score=-102.148 tagged_above=-999 required=5 tests=[AWL=0.829, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XjyPknbwoOYM for ; Mon, 11 Apr 2011 16:05:03 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id 25BE8E0692 for ; Mon, 11 Apr 2011 16:04:59 -0700 (PDT) Received: by vws12 with SMTP id 12so5716657vws.31 for ; Mon, 11 Apr 2011 16:04:59 -0700 (PDT) Received: by 10.52.65.69 with SMTP id v5mr4732693vds.200.1302563099154; Mon, 11 Apr 2011 16:04:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.181.8 with HTTP; Mon, 11 Apr 2011 16:04:39 -0700 (PDT) In-Reply-To: <4DA32104.4070601@stevecrocker.com> References: <4DA317B9.9040604@joelhalpern.com> <4DA32104.4070601@stevecrocker.com> From: Jamal Hadi Salim Date: Mon, 11 Apr 2011 19:04:39 -0400 Message-ID: To: Joel Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Joel M. Halpern" , Chuanhuang Li , forces@ietf.org Subject: Re: [forces] LFB LPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 23:05:04 -0000 I am fine with this proposal. Just one or two comments below: On Mon, Apr 11, 2011 at 11:40 AM, Joel wrote: > Lets trace it out: > The Longest Prefix Match (LPM) LFB looks up the destination IP address, a= nd > profuces a next hop index. > the packet is then sent to the Next Hop (NH) LFB. > The NH LFB uses the next hop index to pick up several pieces of informati= on. > =A0this includes the next hop IP address (if any), the output index for t= he > group port, used locally to select which next LFB to send the packet to, = and > an encapsulation index metadata, and a logical output port ID. > Note1: at this stage, this is a logical port as seen by L3 processing. > > Eventually, the packet arrives at a media specific encapsulator. =A0Let u= s > assume that ARP information is all filled in. =A0The media encapsulator k= nows > how to add the proper header to the packet, and send it onward. > Note2: If we want to design to allow a single instance of the media > encapsulator to handle multiple L3 output ports, then we use the output p= ort > index as well as the encapsualtion index as table indicies. =A0If each Me= dia > encapsulation LFB instance handles only one L3 output port, then only the > encapsulation index is used as the table index. > Note3: To allow for different ways of handling ARP, I would define the ta= ble > here to have an indication if the entry is unfilled. =A0If a packet arriv= es > with an encapsulation index pointing to an unfilled entry, then it needs = to > be sent for ARP processing (either an APR LFB or the CE...) We could define that as a table miss exception; of which ARP/ND is one possible resolution. > One of the things the media encapsulator has to do is to cope with the fa= ct > that there may be L2 bridging under the L3 port. =A0As such, the output p= ort > ID may be refined / replaced with a more specific valuye by this processi= ng. This is the part i need to think about a little more. What are the circumst= ances for this to happen? i.e if the CE already knows all, why would it not popul= ate such information at the L3 level? Given the CE already knows what headers need to be encapsulated on an outgoing packet. > Note 4: The NH LFB can not do this refinement because it operates above t= he > level where this is visible. cheers, jamal From hadi@mojatatu.com Mon Apr 11 16:11:55 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 86DBDE06F7 for ; Mon, 11 Apr 2011 16:11:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.907 X-Spam-Level: X-Spam-Status: No, score=-101.907 tagged_above=-999 required=5 tests=[AWL=0.470, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TGYBdDYfMAA9 for ; Mon, 11 Apr 2011 16:11:54 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id 891C3E06F6 for ; Mon, 11 Apr 2011 16:11:54 -0700 (PDT) Received: by vws12 with SMTP id 12so5722743vws.31 for ; Mon, 11 Apr 2011 16:11:54 -0700 (PDT) Received: by 10.52.166.101 with SMTP id zf5mr777690vdb.280.1302563514102; Mon, 11 Apr 2011 16:11:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.181.8 with HTTP; Mon, 11 Apr 2011 16:11:34 -0700 (PDT) In-Reply-To: <201104120052581097823@mail.zjgsu.edu.cn> References: <4DA317B9.9040604@joelhalpern.com> <201104120052581097823@mail.zjgsu.edu.cn> From: Jamal Hadi Salim Date: Mon, 11 Apr 2011 19:11:34 -0400 Message-ID: To: Chuanhuang Li Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Joel M. Halpern" , "forces@ietf.org" Subject: Re: [forces] LFB LPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 23:11:55 -0000 On Mon, Apr 11, 2011 at 12:52 PM, Chuanhuang Li wrote: > Hi, All > > I know what Jamal had suggested. In that case, the "NHEncapInfoIndex" is = not > the same as "EncapOutputIndex" which we have currently defined in NH tabl= e. > "NHEncapInfoIndex" will be used for the selection of different entry in E= ncap Table > in EtherEncap LFB. "EncapOutputIndex" is still for the selection of diffe= rent Output > Port in NH LFB. > > But I have some worries: > 1:According Jamal's suggestion, we need define both of these two index in= NH table. > This will make the logic of NH LFB complicated, because NH need to know s= ome detailed things of it's followed LFBs. It is the job of the CE to keep track of this info (even today downstream L= FBs depend on metadata programmed by the CE on an LFB). > 2:To the packet needed to be forwarded to local subnet host, the routing = table(LPM+NH) > need one entry for one subnet host.(Owing to the searching key is NHEncap= InfoIndex in > Encap table.). Then, if the subnet is large, the routing table is also la= rger. > =A0Current resolution: This is indicated by "NexthopOption" =A0in NH tabl= e(One subnet only need > one entry). =A0If the packet is for the subnet host, the metadata "Nextho= pIPv4Addr" will > be changed to it's destination IP address. In EtherEncap, by using this I= P address(searching key), > the packet can found out it's encapsulation information. The intent is not to remove this feature. I didnt quiet follow how we loose= it, but we need to make sure it stays. > 3:Also, if we define "NHEncapInfoIndex", the "NexthopIPAddr" defined in N= H table > may be no useful in the followed LFBs. It may still be useful. Refer to exchange in my last email with Joel. It ma= y still be used to do ARP/ND when the encap table miss happens. If i was to implement, I will make sure theres never such a table miss and therefore no need for ARP/ND. But thats a choice i dont want to impose. > ps: In my mind, Although we will not define ARP/ND LFB in current version= lib, I think it is not > mean we should avoid everything about them in the other LFB's definition. > Refer to above. I dont think we should really define ARP/ND LFB. We should mention that it is possible to use ARP/ND without going into the structure of such an LFB. cheers, jamal From joel@stevecrocker.com Mon Apr 11 16:13:42 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id BB583E0683 for ; Mon, 11 Apr 2011 16:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.47 X-Spam-Level: X-Spam-Status: No, score=-1.47 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DSL=1.129] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9arWo11FxQB3 for ; Mon, 11 Apr 2011 16:13:41 -0700 (PDT) Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by ietfc.amsl.com (Postfix) with ESMTP id E9B17E06A7 for ; Mon, 11 Apr 2011 16:13:39 -0700 (PDT) Received: from [129.192.147.67] (HELO [10.154.180.122]) by execdsl.com (CommuniGate Pro SMTP 5.1.16) with ESMTPS id 19547827; Mon, 11 Apr 2011 23:13:53 +0000 Message-ID: <4DA38B1A.4030801@stevecrocker.com> Date: Mon, 11 Apr 2011 19:13:30 -0400 From: Joel 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: <4DA317B9.9040604@joelhalpern.com> <4DA32104.4070601@stevecrocker.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Joel M. Halpern" , Chuanhuang Li , forces@ietf.org Subject: Re: [forces] LFB LPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 23:13:42 -0000 In one sense, the CE will know all. The basic problem is when brdging shifts thigns around. You can, for a single, stable, next hop, go through the three stages: 1) Next Hop A -> L3 Output Port A -> real output port A1 2) Next Hop A -> L3 Output Port A -> unknown real output port due to brdging cache flush 3) Next Hop A -> L3 Output Port A -> real output port A2 We could include that real output port in the Next Hop table. But it is really a media specific thing. The information about it should be confined to LFBs that care about the specific media and specific logical output port. related example is ARP / ND. If you do not know what the MAC address is, you do not know what the real output port is, even though you do know the logical (L3) output port. Yours, Joel On 4/11/2011 7:04 PM, Jamal Hadi Salim wrote: > ... >> One of the things the media encapsulator has to do is to cope with the fact >> that there may be L2 bridging under the L3 port. As such, the output port >> ID may be refined / replaced with a more specific valuye by this processing. > This is the part i need to think about a little more. What are the circumstances > for this to happen? i.e if the CE already knows all, why would it not populate > such information at the L3 level? Given the CE already knows what headers > need to be encapsulated on an outgoing packet. > >> Note 4: The NH LFB can not do this refinement because it operates above the >> level where this is visible. > cheers, > jamal From chuanhuang_li@mail.zjgsu.edu.cn Mon Apr 11 21:31:44 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 67858E0676 for ; Mon, 11 Apr 2011 21:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.209 X-Spam-Level: ** X-Spam-Status: No, score=2.209 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FROM_EXCESS_BASE64=1.456, J_CHICKENPOX_57=0.6, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-1XP+G4Hfyu for ; Mon, 11 Apr 2011 21:31:43 -0700 (PDT) Received: from mail.zjgsu.edu.cn (ucmail.zjgsu.edu.cn [124.160.64.1]) by ietfc.amsl.com (Postfix) with SMTP id AE9A2E06E9 for ; Mon, 11 Apr 2011 21:31:41 -0700 (PDT) Received: from RobinLee (unknown [10.20.0.167]) by mailportal (Coremail) with SMTP id rBCI85D7CS2M06NNQEIPAA--.54409S2; Tue, 12 Apr 2011 12:22:36 +0800 (CST) Date: Tue, 12 Apr 2011 12:31:48 +0800 From: "=?utf-8?B?Q2h1YW5odWFuZyBMaQ==?=" To: "=?utf-8?B?Sm9lbA==?=" References: , , , <4DA317B9.9040604@joelhalpern.com>, <201104120052581097823@mail.zjgsu.edu.cn> Message-ID: <201104121231484534654@mail.zjgsu.edu.cn> Organization: =?utf-8?B?WmhlamlhbmcgR29uZ3NoYW5nIFVuaXZlcmNpdHk=?= X-mailer: Foxmail 6, 15, 201, 23 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-CM-TRANSID: rBCI85D7CS2M06NNQEIPAA--.54409S2 X-Coremail-Antispam: 1Uf129KBjDUn29KB7ZKAUJUUUUUYxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJ3UbIYCTnIWIevJa73UjIFyTuYvj4RJUUUUUUUU X-CM-SenderInfo: pfkxt0xkxd0wxbolqzhdloh6pmjv3hxhgxhubq/ Cc: =?utf-8?B?Sm9lbCBNLiBIYWxwZXJu?= , =?utf-8?B?Zm9yY2VzQGlldGYub3Jn?= Subject: Re: [forces] =?utf-8?q?LFB_LPM_issue?= X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 04:31:44 -0000 Hi, Joel and Jamal >The local hosts are an interesting question. I can imagien various >design change sto keep that simple, if we want to do so. (For example, >we could have special entries in the enxt hop table that mean "local >subnet", and use a single next hop index for those, and have the next >hop LFB look at the ARP / ND table.) I think this ARP/ND table(Include IP information) is different from the Encap Table which Jamal had mentioned (No IP information). If ARP/ND is implemented on CE, these packets for local hosts will be needed to redirect to CE to complete the encapsulation. It's so strange. If ARP/ND is implemented on FE, these packets will be sent to ARP/ND LFB to encapsulate. In this case, the EtherEncap LFB only have some encapsulating function. >The CE will populate the indices. It knows what index it assigns to the >specific next hop, and manages the table. There is no "coordiantion" >between LFBs that causes problems. Yes, CE knows what index it assigns, When ARP/ND is implemented on CE. But if ARP/ND is implemented on FE, CE dons't know this information. CE can config a fix index to every entry, but i think this may affect the EtherEncap LFB to manager his table. Also, for ARP/ND LFB, it need to know whether it tells to EtherEncap LFB to flush the Encap table, when it gets a new L2 information. From hadi@mojatatu.com Tue Apr 12 02:05:51 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1DB72E06BA for ; Tue, 12 Apr 2011 02:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.739 X-Spam-Level: X-Spam-Status: No, score=-101.739 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPnQR3sM34tx for ; Tue, 12 Apr 2011 02:05:50 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfc.amsl.com (Postfix) with ESMTP id 99B90E0678 for ; Tue, 12 Apr 2011 02:05:50 -0700 (PDT) Received: by vxg33 with SMTP id 33so5818183vxg.31 for ; Tue, 12 Apr 2011 02:05:50 -0700 (PDT) Received: by 10.52.67.167 with SMTP id o7mr4812697vdt.240.1302599150230; Tue, 12 Apr 2011 02:05:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.181.8 with HTTP; Tue, 12 Apr 2011 02:05:30 -0700 (PDT) In-Reply-To: <4DA38B1A.4030801@stevecrocker.com> References: <4DA317B9.9040604@joelhalpern.com> <4DA32104.4070601@stevecrocker.com> <4DA38B1A.4030801@stevecrocker.com> From: Jamal Hadi Salim Date: Tue, 12 Apr 2011 05:05:30 -0400 Message-ID: To: Joel Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Joel M. Halpern" , Chuanhuang Li , forces@ietf.org Subject: Re: [forces] LFB LPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 09:05:51 -0000 Ok, i can see it. So it seems to be sensible to leave out the Output Port out of the NH level, rather have the media level decide that, no? i.e the NH passes on the encap index to the encapsulator which resolves not just the header level details but also the Output port. In the case of bridges, tunnels, arp etc it should work. cheers, jamal PS:- it is getting confusing sometimes in the discussion figuring whether we are talking about a media port or an LFB port. I am assuming output port to mean a media port. On Mon, Apr 11, 2011 at 7:13 PM, Joel wrote: > In one sense, the CE will know all. > The basic problem is when brdging shifts thigns around. =A0You can, for a > single, stable, next hop, go through the three stages: > 1) Next Hop A -> L3 Output Port A -> real output port A1 > 2) Next Hop A -> L3 Output Port A -> unknown real output port due to brdg= ing > cache flush > 3) Next Hop A -> L3 Output Port A -> real output port A2 > We could include that real output port in the Next Hop table. =A0But it i= s > really a media specific thing. =A0The information about it should be conf= ined > to LFBs that care about the specific media and specific logical output po= rt. > > related example is ARP / ND. =A0If you do not know what the MAC address i= s, > you do not know what the real output port is, even though you do know the > logical (L3) output port. From hadi@mojatatu.com Tue Apr 12 02:26:03 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 57849E06D7 for ; Tue, 12 Apr 2011 02:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.954 X-Spam-Level: X-Spam-Status: No, score=-101.954 tagged_above=-999 required=5 tests=[AWL=0.423, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ALvuCQeFoTRE for ; Tue, 12 Apr 2011 02:26:02 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id A6903E0692 for ; Tue, 12 Apr 2011 02:26:02 -0700 (PDT) Received: by vws12 with SMTP id 12so6089137vws.31 for ; Tue, 12 Apr 2011 02:26:02 -0700 (PDT) Received: by 10.52.67.167 with SMTP id o7mr4839494vdt.240.1302600362226; Tue, 12 Apr 2011 02:26:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.181.8 with HTTP; Tue, 12 Apr 2011 02:25:41 -0700 (PDT) In-Reply-To: <201104121231484534654@mail.zjgsu.edu.cn> References: <4DA317B9.9040604@joelhalpern.com> <201104120052581097823@mail.zjgsu.edu.cn> <201104121231484534654@mail.zjgsu.edu.cn> From: Jamal Hadi Salim Date: Tue, 12 Apr 2011 05:25:41 -0400 Message-ID: To: Chuanhuang Li Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Joel M. Halpern" , "forces@ietf.org" Subject: Re: [forces] LFB LPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 09:26:03 -0000 On Tue, Apr 12, 2011 at 12:31 AM, Chuanhuang Li wrote: > Hi, Joel and Jamal >>The local hosts are an interesting question. =A0I can imagien various >>design change sto keep that simple, if we want to do so. =A0(For example, >>we could have special entries in the enxt hop table that mean "local >>subnet", and use a single next hop index for those, and have the next >>hop LFB look at the ARP / ND table.) > I think this ARP/ND table(Include IP information) is different from the E= ncap Table > which Jamal had mentioned (No IP information). The necessary contents of the current doc's ARP/ND should be in the encap t= able. The IP is still passed if it needs to be used. How it is used is implementa= tion specific. > If ARP/ND is implemented on CE, these packets for local hosts will be nee= ded to > redirect to CE to complete the encapsulation. It's so strange. > If ARP/ND is implemented on FE, these packets will be sent to ARP/ND > LFB to encapsulate. In this case, the EtherEncap LFB only have some > encapsulating function. > I didnt follow the above discussion. Currently, the NH table is populated with an IP address that belongs to the CE or FE. There is some flag in the table which says "this is a local packet, therefore send it to the host". In other words a packet arriving for the CE or FE IP should never reach the EtherEncap LFB. A packet originated from the CE or FE should be fine since it is destined for a different IP. Am i mistaken? >>The CE will populate the indices. =A0It knows what index it assigns to th= e >>specific next hop, and manages the table. =A0There is no "coordiantion" >>between LFBs that causes problems. > Yes, CE knows what index it assigns, When ARP/ND is implemented on CE. > But if ARP/ND is implemented on FE, CE dons't know this information. CE c= an config a fix index > to every entry, but i think this may affect the EtherEncap LFB to manager= his table. > Also, for ARP/ND LFB, it need to know whether it tells to EtherEncap LFB = to flush the Encap table, > when it gets a new L2 information. > Ok, maybe Joel followed - I will defer to him. cheers, jamal From chuanhuang_li@mail.zjgsu.edu.cn Tue Apr 12 05:02:30 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2664DE06C6 for ; Tue, 12 Apr 2011 05:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.747 X-Spam-Level: * X-Spam-Status: No, score=1.747 tagged_above=-999 required=5 tests=[AWL=0.463, BAYES_05=-1.11, J_CHICKENPOX_57=0.6, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m8LtsPtAtBVx for ; Tue, 12 Apr 2011 05:02:29 -0700 (PDT) Received: from mail.zjgsu.edu.cn (ucmail.zjgsu.edu.cn [124.160.64.1]) by ietfc.amsl.com (Postfix) with SMTP id CD37DE066B for ; Tue, 12 Apr 2011 05:02:28 -0700 (PDT) Received: from RobinLee (unknown [10.20.0.167]) by mailportal (Coremail) with SMTP id rBCI85DbsDAxPaRNQEIPAA--.55596S2; Tue, 12 Apr 2011 19:53:21 +0800 (CST) Date: Tue, 12 Apr 2011 20:02:38 +0800 From: "Chuanhuang Li" To: "Jamal Hadi Salim" References: , , , , <4DA317B9.9040604@joelhalpern.com>, <201104120052581097823@mail.zjgsu.edu.cn>, <201104121231484534654@mail.zjgsu.edu.cn> Message-ID: <201104122002382030086@mail.zjgsu.edu.cn> Organization: Zhejiang Gongshang Univercity X-mailer: Foxmail 6, 15, 201, 23 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-CM-TRANSID: rBCI85DbsDAxPaRNQEIPAA--.55596S2 X-Coremail-Antispam: 1Uf129KBjDUn29KB7ZKAUJUUUUUYxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJ3UbIYCTnIWIevJa73UjIFyTuYvj4RJUUUUUUUU X-CM-SenderInfo: pfkxt0xkxd0wxbolqzhdloh6pmjv3hxhgxhubq/ Cc: "Joel M. Halpern" , "forces@ietf.org" Subject: Re: [forces] LFB LPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 12:02:30 -0000 SGksSmFtYWwgDQogICAgUGxlYXNlIHNlZSB0aGUgaW5saW5lLiBUaGFua3MhDQo9PT09PT09IDIw MTEtMDQtMTIgMTc6MTg6NTAgSmFtYWwgSGFkaSBTYWxpbSwgd3JvdGU6ID09PT09PT0NCg0KPk9u IFR1ZSwgQXByIDEyLCAyMDExIGF0IDEyOjMxIEFNLCBDaHVhbmh1YW5nIExpDQo+PGNodWFuaHVh bmdfbGlAbWFpbC56amdzdS5lZHUuY24+IHdyb3RlOg0KPj4gSGksIEpvZWwgYW5kIEphbWFsDQo+ Pj5UaGUgbG9jYWwgaG9zdHMgYXJlIGFuIGludGVyZXN0aW5nIHF1ZXN0aW9uLiCgSSBjYW4gaW1h Z2llbiB2YXJpb3VzDQo+Pj5kZXNpZ24gY2hhbmdlIHN0byBrZWVwIHRoYXQgc2ltcGxlLCBpZiB3 ZSB3YW50IHRvIGRvIHNvLiCgKEZvciBleGFtcGxlLA0KPj4+d2UgY291bGQgaGF2ZSBzcGVjaWFs IGVudHJpZXMgaW4gdGhlIGVueHQgaG9wIHRhYmxlIHRoYXQgbWVhbiAibG9jYWwNCj4+PnN1Ym5l dCIsIGFuZCB1c2UgYSBzaW5nbGUgbmV4dCBob3AgaW5kZXggZm9yIHRob3NlLCBhbmQgaGF2ZSB0 aGUgbmV4dA0KPj4+aG9wIExGQiBsb29rIGF0IHRoZSBBUlAgLyBORCB0YWJsZS4pDQo+PiBJIHRo aW5rIHRoaXMgQVJQL05EIHRhYmxlKEluY2x1ZGUgSVAgaW5mb3JtYXRpb24pIGlzIGRpZmZlcmVu dCBmcm9tIHRoZSBFbmNhcCBUYWJsZQ0KPj4gd2hpY2ggSmFtYWwgaGFkIG1lbnRpb25lZCAoTm8g SVAgaW5mb3JtYXRpb24pLg0KPg0KPlRoZSBuZWNlc3NhcnkgY29udGVudHMgb2YgdGhlIGN1cnJl bnQgZG9jJ3MgQVJQL05EIHNob3VsZCBiZSBpbiB0aGUgZW5jYXAgdGFibGUuDQo+VGhlIElQIGlz IHN0aWxsIHBhc3NlZCBpZiBpdCBuZWVkcyB0byBiZSB1c2VkLiBIb3cgaXQgaXMgdXNlZCBpcyBp bXBsZW1lbnRhdGlvbg0KPnNwZWNpZmljLg0KRG8geW91IG1lYW4gSVAgYWRkcmVzcyBpbmZvcm1h dGlvbiBzdGlsbCBiZSBuZWVkZWQgaW4gRW5jYXAgdGFibGU/DQpJbiBwcmV2aW91cyBlbWFpbCwg eW91IHNhaWQgbm8gSVAgaW5mb3JtYXRpb24gbmVlZGVkIGJ5IGV0aGVybmV0IGVuY2Fwc3VsYXRv ci4NClNvIEknbSBjb25mdXNlZC4gDQoNCj4+IElmIEFSUC9ORCBpcyBpbXBsZW1lbnRlZCBvbiBD RSwgdGhlc2UgcGFja2V0cyBmb3IgbG9jYWwgaG9zdHMgd2lsbCBiZSBuZWVkZWQgdG8NCj4+IHJl ZGlyZWN0IHRvIENFIHRvIGNvbXBsZXRlIHRoZSBlbmNhcHN1bGF0aW9uLiBJdCdzIHNvIHN0cmFu Z2UuDQo+PiBJZiBBUlAvTkQgaXMgaW1wbGVtZW50ZWQgb24gRkUsIHRoZXNlIHBhY2tldHMgd2ls bCBiZSBzZW50IHRvIEFSUC9ORA0KPj4gTEZCIHRvIGVuY2Fwc3VsYXRlLiBJbiB0aGlzIGNhc2Us IHRoZSBFdGhlckVuY2FwIExGQiBvbmx5IGhhdmUgc29tZQ0KPj4gZW5jYXBzdWxhdGluZyBmdW5j dGlvbi4NCj4+DQo+DQo+SSBkaWRudCBmb2xsb3cgdGhlIGFib3ZlIGRpc2N1c3Npb24uDQo+Q3Vy cmVudGx5LCB0aGUgTkggdGFibGUgaXMgcG9wdWxhdGVkIHdpdGggYW4gSVAgYWRkcmVzcyB0aGF0 IGJlbG9uZ3MNCj50byB0aGUgQ0Ugb3IgRkUuIFRoZXJlIGlzIHNvbWUgZmxhZyBpbiB0aGUgdGFi bGUgd2hpY2ggc2F5cyAidGhpcyBpcw0KPmEgbG9jYWwgcGFja2V0LCB0aGVyZWZvcmUgc2VuZCBp dCB0byB0aGUgaG9zdCIuDQo+SW4gb3RoZXIgd29yZHMgYSBwYWNrZXQgYXJyaXZpbmcgZm9yIHRo ZSBDRSBvciBGRSBJUCBzaG91bGQgbmV2ZXIgcmVhY2gNCj50aGUgRXRoZXJFbmNhcCBMRkIuIEEg cGFja2V0IG9yaWdpbmF0ZWQgZnJvbSB0aGUgQ0Ugb3IgRkUgc2hvdWxkDQo+YmUgZmluZSBzaW5j ZSBpdCBpcyBkZXN0aW5lZCBmb3IgYSBkaWZmZXJlbnQgSVAuDQo+QW0gaSBtaXN0YWtlbj8NCkFs bCBJIGhhdmUgc2FpZCBpcyBiYXNlZCBvbiB5b3VyIHN1Z2dlc3Rpb246IHRoZXJlIGlzIG5vIElQ IGluZm9ybWF0aW9uIGluIEVjYXAgdGFibGUuDQpBbmQgdGhlIHBhY2tldHMgd2UgZGlzY3Vzc2Vk IGFyZSB0aG9zZSBuZWVkIHRvIGJlIGZvcndhcmRlZCB0byB0aGUgc3VibmV0IGhvc3RzLCBub3Qg dGhlIHBhY2tldHMgDQp3aGljaCBuZWVkIHRvIGJlIHByb2Nlc3NlZCBvbiBsb2NhbCBDRS4gVGhl IGxhdGVyIHdpbGwgZ28gb3V0IGZyb20gYSBzcGVjaWFsIG91dHB1dCBwb3J0IG9mIE5IIExGQiB0 byANClJlZGlyZWN0T3V0IExGQi4NCg0KDQo+Pj5UaGUgQ0Ugd2lsbCBwb3B1bGF0ZSB0aGUgaW5k aWNlcy4goEl0IGtub3dzIHdoYXQgaW5kZXggaXQgYXNzaWducyB0byB0aGUNCj4+PnNwZWNpZmlj IG5leHQgaG9wLCBhbmQgbWFuYWdlcyB0aGUgdGFibGUuIKBUaGVyZSBpcyBubyAiY29vcmRpYW50 aW9uIg0KPj4+YmV0d2VlbiBMRkJzIHRoYXQgY2F1c2VzIHByb2JsZW1zLg0KPj4gWWVzLCBDRSBr bm93cyB3aGF0IGluZGV4IGl0IGFzc2lnbnMsIFdoZW4gQVJQL05EIGlzIGltcGxlbWVudGVkIG9u IENFLg0KPj4gQnV0IGlmIEFSUC9ORCBpcyBpbXBsZW1lbnRlZCBvbiBGRSwgQ0UgZG9ucyd0IGtu b3cgdGhpcyBpbmZvcm1hdGlvbi4gQ0UgY2FuIGNvbmZpZyBhIGZpeCBpbmRleA0KPj4gdG8gZXZl cnkgZW50cnksIGJ1dCBpIHRoaW5rIHRoaXMgbWF5IGFmZmVjdCB0aGUgRXRoZXJFbmNhcCBMRkIg dG8gbWFuYWdlciBoaXMgdGFibGUuDQo+PiBBbHNvLCBmb3IgQVJQL05EIExGQiwgaXQgbmVlZCB0 byBrbm93IHdoZXRoZXIgaXQgdGVsbHMgdG8gRXRoZXJFbmNhcCBMRkIgdG8gZmx1c2ggdGhlIEVu Y2FwIHRhYmxlLA0KPj4gd2hlbiBpdCBnZXRzIGEgbmV3IEwyIGluZm9ybWF0aW9uLg0KPj4NCj4N Cj5PaywgbWF5YmUgSm9lbCBmb2xsb3dlZCAtIEkgd2lsbCBkZWZlciB0byBoaW0uDQo+DQo+Y2hl ZXJzLA0KPmphbWFsDQo= From jmh@joelhalpern.com Tue Apr 12 05:12:17 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B1A82E079B for ; Tue, 12 Apr 2011 05:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_57=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3hj1wbComEdf for ; Tue, 12 Apr 2011 05:12:17 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes.out.tigertech.net [74.114.88.72]) by ietfc.amsl.com (Postfix) with ESMTP id 02E58E0709 for ; Tue, 12 Apr 2011 05:12:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 5B8C94300AE; Tue, 12 Apr 2011 05:12:16 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [172.17.114.244] (207.47.24.2.static.nextweb.net [207.47.24.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id 2F94C430052; Tue, 12 Apr 2011 05:12:16 -0700 (PDT) Message-ID: <4DA4419F.3040808@joelhalpern.com> Date: Tue, 12 Apr 2011 08:12:15 -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: Chuanhuang Li References: , , , <4DA317B9.9040604@joelhalpern.com>, <201104120052581097823@mail.zjgsu.edu.cn> <201104121231484534654@mail.zjgsu.edu.cn> In-Reply-To: <201104121231484534654@mail.zjgsu.edu.cn> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "forces@ietf.org" Subject: Re: [forces] LFB LPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 12:12:17 -0000 Even with ARP/ND on the FE, the CE will still know what index in the EncapTable is assigned to the nexthop. It will assign that index when it creates the nexthop. It will be marked as pending resolution, and will get filled in when the ARP occurs. Yours, Joel On 4/12/2011 12:31 AM, Chuanhuang Li wrote: > Hi, Joel and Jamal >> The local hosts are an interesting question. I can imagien various >> design change sto keep that simple, if we want to do so. (For example, >> we could have special entries in the enxt hop table that mean "local >> subnet", and use a single next hop index for those, and have the next >> hop LFB look at the ARP / ND table.) > I think this ARP/ND table(Include IP information) is different from the Encap Table > which Jamal had mentioned (No IP information). > If ARP/ND is implemented on CE, these packets for local hosts will be needed to > redirect to CE to complete the encapsulation. It's so strange. > If ARP/ND is implemented on FE, these packets will be sent to ARP/ND > LFB to encapsulate. In this case, the EtherEncap LFB only have some encapsulating function. > >> The CE will populate the indices. It knows what index it assigns to the >> specific next hop, and manages the table. There is no "coordiantion" >> between LFBs that causes problems. > Yes, CE knows what index it assigns, When ARP/ND is implemented on CE. > But if ARP/ND is implemented on FE, CE dons't know this information. CE can config a fix index > to every entry, but i think this may affect the EtherEncap LFB to manager his table. > Also, for ARP/ND LFB, it need to know whether it tells to EtherEncap LFB to flush the Encap table, > when it gets a new L2 information. > > > > > From jmh@joelhalpern.com Tue Apr 12 05:17:30 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D25F7E0699 for ; Tue, 12 Apr 2011 05:17:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oFObbk+fytUA for ; Tue, 12 Apr 2011 05:17:30 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes.out.tigertech.net [74.114.88.72]) by ietfc.amsl.com (Postfix) with ESMTP id 3BAC0E066B for ; Tue, 12 Apr 2011 05:17:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id E0C554300E4; Tue, 12 Apr 2011 05:17:29 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [172.17.114.244] (207.47.24.2.static.nextweb.net [207.47.24.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id B0129430052; Tue, 12 Apr 2011 05:17:29 -0700 (PDT) Message-ID: <4DA442D9.3060404@joelhalpern.com> Date: Tue, 12 Apr 2011 08:17:29 -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: <4DA317B9.9040604@joelhalpern.com> <4DA32104.4070601@stevecrocker.com> <4DA38B1A.4030801@stevecrocker.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: forces@ietf.org, Chuanhuang Li Subject: Re: [forces] LFB LPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 12:17:31 -0000 Is it your thought that we would use one mediaEncap LFB Instance per Level 3 output port? If so, then the output port number in the NH LFB is purely diagnostic / informational, and could be removed. (If we have to send a packet to the CE for ARP, we have to add the L3 port number metadata then.) Yours, Joel On 4/12/2011 5:05 AM, Jamal Hadi Salim wrote: > Ok, i can see it. > So it seems to be sensible to leave out the Output Port out of the > NH level, rather have the media level decide that, no? > i.e the NH passes on the encap index to the encapsulator which resolves > not just the header level details but also the Output port. > In the case of bridges, tunnels, arp etc it should work. > > cheers, > jamal > > PS:- it is getting confusing sometimes in the discussion figuring whether > we are talking about a media port or an LFB port. I am assuming output > port to mean a media port. > > On Mon, Apr 11, 2011 at 7:13 PM, Joel wrote: >> In one sense, the CE will know all. >> The basic problem is when brdging shifts thigns around. You can, for a >> single, stable, next hop, go through the three stages: >> 1) Next Hop A -> L3 Output Port A -> real output port A1 >> 2) Next Hop A -> L3 Output Port A -> unknown real output port due to brdging >> cache flush >> 3) Next Hop A -> L3 Output Port A -> real output port A2 >> We could include that real output port in the Next Hop table. But it is >> really a media specific thing. The information about it should be confined >> to LFBs that care about the specific media and specific logical output port. >> >> related example is ARP / ND. If you do not know what the MAC address is, >> you do not know what the real output port is, even though you do know the >> logical (L3) output port. > From hadi@mojatatu.com Wed Apr 13 02:15:48 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id F2F00E0689 for ; Wed, 13 Apr 2011 02:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.779 X-Spam-Level: X-Spam-Status: No, score=-101.779 tagged_above=-999 required=5 tests=[AWL=0.198, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vapMHf9uYvWT for ; Wed, 13 Apr 2011 02:15:47 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfc.amsl.com (Postfix) with ESMTP id 80CA7E0684 for ; Wed, 13 Apr 2011 02:15:47 -0700 (PDT) Received: by vxg33 with SMTP id 33so362830vxg.31 for ; Wed, 13 Apr 2011 02:15:47 -0700 (PDT) Received: by 10.220.125.24 with SMTP id w24mr2065439vcr.262.1302686147063; Wed, 13 Apr 2011 02:15:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.181.8 with HTTP; Wed, 13 Apr 2011 02:15:26 -0700 (PDT) In-Reply-To: <201104122002382030086@mail.zjgsu.edu.cn> References: <4DA317B9.9040604@joelhalpern.com> <201104120052581097823@mail.zjgsu.edu.cn> <201104121231484534654@mail.zjgsu.edu.cn> <201104122002382030086@mail.zjgsu.edu.cn> From: Jamal Hadi Salim Date: Wed, 13 Apr 2011 05:15:26 -0400 Message-ID: To: Chuanhuang Li Content-Type: text/plain; charset=ISO-8859-1 Cc: "Joel M. Halpern" , "forces@ietf.org" Subject: Re: [forces] LFB LPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 09:15:48 -0000 Hi Chuanhuang, On Tue, Apr 12, 2011 at 8:02 AM, Chuanhuang Li [..] > Do you mean IP address information still be needed in Encap table? > In previous email, you said no IP information needed by > ethernet encapsulator. So I'm confused. Right, no IP address in the Encap table. NHIP address is still passed to the Etherencap as metadata. It is to be ignored by implementation which doesnt do ARP/ND. The NHIP can be used to do ARP/ND if implementation chooses to. This will happen if for example, the passed Encap index does not exist (which should never happen in an implementation that doesnt use ARP). For implementation that does ARP/ND, when the ARP/ND is resolved, the Encap table is populated by CE at a chosen index. This same index is updated to the NH so it can be used by subsequent packet. How you do that will depend on implementation - but it seems to make sense to have the CE do it. cheers, jamal From hadi@mojatatu.com Wed Apr 13 02:33:03 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D4EFAE065F for ; Wed, 13 Apr 2011 02:33:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.29 X-Spam-Level: X-Spam-Status: No, score=-102.29 tagged_above=-999 required=5 tests=[AWL=0.687, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oqo9T0IictxP for ; Wed, 13 Apr 2011 02:33:03 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id 3272EE06D8 for ; Wed, 13 Apr 2011 02:33:03 -0700 (PDT) Received: by vws12 with SMTP id 12so386488vws.31 for ; Wed, 13 Apr 2011 02:33:02 -0700 (PDT) Received: by 10.52.67.167 with SMTP id o7mr6846013vdt.240.1302687182136; Wed, 13 Apr 2011 02:33:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.181.8 with HTTP; Wed, 13 Apr 2011 02:32:42 -0700 (PDT) In-Reply-To: <4DA442D9.3060404@joelhalpern.com> References: <4DA317B9.9040604@joelhalpern.com> <4DA32104.4070601@stevecrocker.com> <4DA38B1A.4030801@stevecrocker.com> <4DA442D9.3060404@joelhalpern.com> From: Jamal Hadi Salim Date: Wed, 13 Apr 2011 05:32:42 -0400 Message-ID: To: "Joel M. Halpern" Content-Type: text/plain; charset=ISO-8859-1 Cc: forces@ietf.org, Chuanhuang Li Subject: Re: [forces] LFB LPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 09:33:04 -0000 On Tue, Apr 12, 2011 at 8:17 AM, Joel M. Halpern wrote: > Is it your thought that we would use one mediaEncap LFB Instance per Level 3 > output port? That was my initial thinking - but now that you bring it up again, you made me look closer at figure1... Other than EtherPHYCop, is there any need for any other LFB instance to be per-mediaport? Indeed, the reverse case can be also argued and you have everything per-mediaport. But we do have ability for grouping of LFB-ports which can be used to mux to different instances of the same LFB class etc. Figure1 seems to have have some LFBs FE wide and some mediaport specific (the mediaencap seems to be port specific). cheers, jamal From chuanhuang_li@mail.zjgsu.edu.cn Wed Apr 13 03:29:53 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A55C4E06E2 for ; Wed, 13 Apr 2011 03:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.103 X-Spam-Level: * X-Spam-Status: No, score=1.103 tagged_above=-999 required=5 tests=[AWL=0.643, BAYES_20=-0.74, J_CHICKENPOX_52=0.6, J_CHICKENPOX_54=0.6] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZFnSM1+OsCH for ; Wed, 13 Apr 2011 03:29:52 -0700 (PDT) Received: from mail.zjgsu.edu.cn (ucmail.zjgsu.edu.cn [124.160.64.1]) by ietfc.amsl.com (Postfix) with SMTP id EA3C2E06D9 for ; Wed, 13 Apr 2011 03:29:51 -0700 (PDT) Received: from RobinLee (unknown [10.20.0.167]) by mailportal (Coremail) with SMTP id rBCI85DbwTH3eKVNQEIPAA--.58207S2; Wed, 13 Apr 2011 18:20:39 +0800 (CST) Date: Wed, 13 Apr 2011 18:30:05 +0800 From: "Chuanhuang Li" To: "Jamal Hadi Salim" References: , , , , <4DA317B9.9040604@joelhalpern.com>, <201104120052581097823@mail.zjgsu.edu.cn>, <201104121231484534654@mail.zjgsu.edu.cn>, <201104122002382030086@mail.zjgsu.edu.cn> Message-ID: <201104131830052038064@mail.zjgsu.edu.cn> Organization: Zhejiang Gongshang Univercity X-mailer: Foxmail 6, 15, 201, 23 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-CM-TRANSID: rBCI85DbwTH3eKVNQEIPAA--.58207S2 X-Coremail-Antispam: 1Uf129KBjDUn29KB7ZKAUJUUUUUYxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJ3UbIYCTnIWIevJa73UjIFyTuYvj4RJUUUUUUUU X-CM-SenderInfo: pfkxt0xkxd0wxbolqzhdloh6pmjv3hxhgxhubq/ Cc: "Joel M. Halpern" , "forces@ietf.org" Subject: Re: [forces] LFB LPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 10:29:53 -0000 Hi,Jamal Sorry. From the context, Do you mean : if user need to support ARP/ND on FE, ARP/ND logic should be implemented in the EtherEncap LFB,? And Etherencap LFB includes the defintions of Encap talbe(no IP information) and ARP/ND table(have IP information)? If so, I think there are duplicated definitions about L2 information in this LFB. and in my thought, the ARP/ND logic shouldn't be included in EtherEncap LFB. If you mean there is only Encap talbe in EtherEncap LFB, how to resolve the problem which I had posted in previous email? (processing packets which need to be forwarded to the subnet hosts.) Thanks! Yours, Chuanhuang ======= 2011-04-13 17:08:36 Jamal Hadi Salim, wrote: ======= >Hi Chuanhuang, > >On Tue, Apr 12, 2011 at 8:02 AM, Chuanhuang Li >[..] >> Do you mean IP address information still be needed in Encap table? >> In previous email, you said no IP information needed by >> ethernet encapsulator. So I'm confused. > > >Right, no IP address in the Encap table. > >NHIP address is still passed to the Etherencap as metadata. >It is to be ignored by implementation which doesnt do ARP/ND. >The NHIP can be used to do ARP/ND if implementation chooses to. >This will happen if for example, the passed Encap index does >not exist (which should never happen in an implementation that >doesnt use ARP). For implementation that does ARP/ND, >when the ARP/ND is resolved, the Encap table is populated >by CE at a chosen index. This same index is updated to the NH >so it can be used by subsequent packet. >How you do that will depend on implementation - but it seems to >make sense to have the CE do it. > >cheers, >jamal From hadi@mojatatu.com Wed Apr 13 03:30:32 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1CBA0E06C1 for ; Wed, 13 Apr 2011 03:30:32 -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.144, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5ibeEB0qGQC for ; Wed, 13 Apr 2011 03:30:31 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfc.amsl.com (Postfix) with ESMTP id A029FE0613 for ; Wed, 13 Apr 2011 03:30:31 -0700 (PDT) Received: by vxg33 with SMTP id 33so411583vxg.31 for ; Wed, 13 Apr 2011 03:30:31 -0700 (PDT) Received: by 10.220.210.3 with SMTP id gi3mr435747vcb.213.1302690631098; Wed, 13 Apr 2011 03:30:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.181.77 with HTTP; Wed, 13 Apr 2011 03:30:11 -0700 (PDT) From: Jamal Hadi Salim Date: Wed, 13 Apr 2011 06:30:11 -0400 Message-ID: To: forces@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Joel M. Halpern" , Chuanhuang Li Subject: [forces] BasicMetadataDispatch WAS(Re: LFB LPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 10:30:32 -0000 Following up after looking at the draft some more.. In Figure1 is the sole purpose of BasicMetadataDispatch to just select a mediaport path? It doesnt seem sensible given we could use LFB-port-groups to select LFB (instances). cheers, jamal On Wed, Apr 13, 2011 at 5:32 AM, Jamal Hadi Salim wrote= : > That was my initial thinking - but now that you bring it up again, > you made me look closer at figure1... =A0Other than EtherPHYCop, is there= any > need for any other LFB instance to be per-mediaport? Indeed, the reverse > case can be also argued and you have everything per-mediaport. > But we do have ability for grouping of LFB-ports which can be used to mux > to different instances of the same LFB class etc. > Figure1 seems to have have some LFBs FE wide and some mediaport > specific (the mediaencap seems to be port specific). > > cheers, > jamal > From hadi@mojatatu.com Wed Apr 13 03:46:03 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 25849E0738 for ; Wed, 13 Apr 2011 03:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.44 X-Spam-Level: X-Spam-Status: No, score=-101.44 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_25=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yTPr3LLB4lQK for ; Wed, 13 Apr 2011 03:46:02 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id 2DC2DE073C for ; Wed, 13 Apr 2011 03:46:02 -0700 (PDT) Received: by vws12 with SMTP id 12so434615vws.31 for ; Wed, 13 Apr 2011 03:46:01 -0700 (PDT) Received: by 10.220.166.84 with SMTP id l20mr2082864vcy.248.1302691561698; Wed, 13 Apr 2011 03:46:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.181.77 with HTTP; Wed, 13 Apr 2011 03:45:40 -0700 (PDT) In-Reply-To: <201104131830052038064@mail.zjgsu.edu.cn> References: <4DA317B9.9040604@joelhalpern.com> <201104120052581097823@mail.zjgsu.edu.cn> <201104121231484534654@mail.zjgsu.edu.cn> <201104122002382030086@mail.zjgsu.edu.cn> <201104131830052038064@mail.zjgsu.edu.cn> From: Jamal Hadi Salim Date: Wed, 13 Apr 2011 06:45:40 -0400 Message-ID: To: Chuanhuang Li Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Joel M. Halpern" , "forces@ietf.org" Subject: Re: [forces] LFB LPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 10:46:03 -0000 Hi Chuanhuang, On Wed, Apr 13, 2011 at 6:30 AM, Chuanhuang Li wrote: > Hi,Jamal > =A0 =A0Sorry. From the context, Do you mean : if user need to support ARP= /ND on FE, > ARP/ND logic should be > implemented in the EtherEncap LFB,? If they are going to be implementing ARP, IMO it should not be defined in t= his specific LFB. For this LFB we assume something (CE most likely) is going to populate neighbor L2 information. If you use ARP/ND or have static entri= es and how you do so - that is the problem of the implementation, not the mode= l. >=A0And Etherencap LFB includes the defintions of =A0Encap talbe(no IP info= rmation) > and ARP/ND table(have IP information)? My opinion is to not have any ARP/ND table here. Maybe Joel has a different opinion. > =A0 =A0If so, I think there are duplicated definitions about L2 informati= on in this LFB. > and in my thought, the ARP/ND logic shouldn't be included in EtherEncap L= FB. Refer to above. > If you mean there is only Encap talbe in EtherEncap LFB, how to resolve > the problem which > I had posted in previous email? (processing packets which need to be >forwarded to the subnet hosts.) Is subnet host meaning "directly connected" routes? I am not sure if we are distinguishing those from a host that is say more than one hop away? To re-iterate what i said earlier about ARP/ND implementation: NHIP and Encap Table index (or other) are passed to the Etherencap as metadata. One approach is to try and index with passed index into Encap Table and fail - which means NH L2 has not been resolved. At this point, your implementation may do ARP. The model shouldnt care and should not have information on ARP. When the ARP/ND is resolved, you will have enough information so that the Encap table is populated by at a chosen table index. This same Encap Table index is updated to the NH so it can be used by subsequent packet (so we dont have lookup failure in Encap Table). Does that make sense? cheers, jamal From chuanhuang_li@mail.zjgsu.edu.cn Wed Apr 13 03:46:59 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 52CC9E06FC for ; Wed, 13 Apr 2011 03:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.186 X-Spam-Level: * X-Spam-Status: No, score=1.186 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_20=-0.74, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZgFaImZ0FStj for ; Wed, 13 Apr 2011 03:46:58 -0700 (PDT) Received: from mail.zjgsu.edu.cn (ucmail.zjgsu.edu.cn [124.160.64.1]) by ietfc.amsl.com (Postfix) with SMTP id 24F1BE06C1 for ; Wed, 13 Apr 2011 03:46:57 -0700 (PDT) Received: from RobinLee (unknown [10.20.0.167]) by mailportal (Coremail) with SMTP id rBCI85DbNjP8fKVNQEIPAA--.58224S2; Wed, 13 Apr 2011 18:37:48 +0800 (CST) Date: Wed, 13 Apr 2011 18:47:14 +0800 From: "Chuanhuang Li" To: "Jamal Hadi Salim" , "forces" Message-ID: <201104131847143284482@mail.zjgsu.edu.cn> Organization: Zhejiang Gongshang Univercity X-mailer: Foxmail 6, 15, 201, 23 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-CM-TRANSID: rBCI85DbNjP8fKVNQEIPAA--.58224S2 X-Coremail-Antispam: 1Uf129KBjDUn29KB7ZKAUJUUUUUYxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJ3UbIYCTnIWIevJa73UjIFyTuYvj4RJUUUUUUUU X-CM-SenderInfo: pfkxt0xkxd0wxbolqzhdloh6pmjv3hxhgxhubq/ Cc: "Joel M. Halpern" Subject: Re: [forces] BasicMetadataDispatch WAS(Re: LFB LPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 10:46:59 -0000 QmFzaWNNZXRhZGF0YURpc3BhdGNoIGlzIGRlZmluZWQgYXMgYSBnZW5lcmFsIG1ldGFkYXRhIGRp c3BhdGNoIExGQiBpbml0aWFsbHkuDQpJdCBjYW4gYmUgdXNlZCB3aGVyZXZlciB1c2VyIHdhbnRz IHRvIGRpc3BhdGggcGFja2V0cyBhY2NvcmRpbmcgc29tZSBzcGVjaWFsIG1ldGFkYXRhLg0KSXQg aGFzIG1vcmUgZmxleGliaWxpdHkuDQogDQpZb3VycywNCkNodWFuaHVhbmcgDQoJDQo9PT09PT09 IDIwMTEtMDQtMTMgMTg6MjM6MTggSmFtYWwgSGFkaSBTYWxpbSwgd3JvdGU6ID09PT09PT0NCg0K PkZvbGxvd2luZyB1cCBhZnRlciBsb29raW5nIGF0IHRoZSBkcmFmdCBzb21lIG1vcmUuLg0KPklu IEZpZ3VyZTEgaXMgdGhlIHNvbGUgcHVycG9zZSBvZiBCYXNpY01ldGFkYXRhRGlzcGF0Y2ggdG8g anVzdCBzZWxlY3QNCj5hIG1lZGlhcG9ydCBwYXRoPyBJdCBkb2VzbnQgc2VlbSBzZW5zaWJsZSBn aXZlbiB3ZSBjb3VsZCB1c2UNCj5MRkItcG9ydC1ncm91cHMgdG8gc2VsZWN0IExGQiAoaW5zdGFu Y2VzKS4NCj4NCj5jaGVlcnMsDQo+amFtYWwNCj4NCj5PbiBXZWQsIEFwciAxMywgMjAxMSBhdCA1 OjMyIEFNLCBKYW1hbCBIYWRpIFNhbGltIDxoYWRpQG1vamF0YXR1LmNvbT4gd3JvdGU6DQo+DQo+ PiBUaGF0IHdhcyBteSBpbml0aWFsIHRoaW5raW5nIC0gYnV0IG5vdyB0aGF0IHlvdSBicmluZyBp dCB1cCBhZ2FpbiwNCj4+IHlvdSBtYWRlIG1lIGxvb2sgY2xvc2VyIGF0IGZpZ3VyZTEuLi4goE90 aGVyIHRoYW4gRXRoZXJQSFlDb3AsIGlzIHRoZXJlIGFueQ0KPj4gbmVlZCBmb3IgYW55IG90aGVy IExGQiBpbnN0YW5jZSB0byBiZSBwZXItbWVkaWFwb3J0PyBJbmRlZWQsIHRoZSByZXZlcnNlDQo+ PiBjYXNlIGNhbiBiZSBhbHNvIGFyZ3VlZCBhbmQgeW91IGhhdmUgZXZlcnl0aGluZyBwZXItbWVk aWFwb3J0Lg0KPj4gQnV0IHdlIGRvIGhhdmUgYWJpbGl0eSBmb3IgZ3JvdXBpbmcgb2YgTEZCLXBv cnRzIHdoaWNoIGNhbiBiZSB1c2VkIHRvIG11eA0KPj4gdG8gZGlmZmVyZW50IGluc3RhbmNlcyBv ZiB0aGUgc2FtZSBMRkIgY2xhc3MgZXRjLg0KPj4gRmlndXJlMSBzZWVtcyB0byBoYXZlIGhhdmUg c29tZSBMRkJzIEZFIHdpZGUgYW5kIHNvbWUgbWVkaWFwb3J0DQo+PiBzcGVjaWZpYyAodGhlIG1l ZGlhZW5jYXAgc2VlbXMgdG8gYmUgcG9ydCBzcGVjaWZpYykuDQo+Pg0KPj4gY2hlZXJzLA0KPj4g amFtYWwNCj4+DQo+Lg0K From hadi@mojatatu.com Wed Apr 13 03:56:47 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 338DEE0707 for ; Wed, 13 Apr 2011 03:56:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.328 X-Spam-Level: X-Spam-Status: No, score=-102.328 tagged_above=-999 required=5 tests=[AWL=0.649, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id czbDSbQGLzfq for ; Wed, 13 Apr 2011 03:56:46 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id 995FCE06FE for ; Wed, 13 Apr 2011 03:56:46 -0700 (PDT) Received: by vws12 with SMTP id 12so441299vws.31 for ; Wed, 13 Apr 2011 03:56:46 -0700 (PDT) Received: by 10.220.166.84 with SMTP id l20mr2085636vcy.248.1302692206163; Wed, 13 Apr 2011 03:56:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.181.77 with HTTP; Wed, 13 Apr 2011 03:56:26 -0700 (PDT) In-Reply-To: <201104131847143284482@mail.zjgsu.edu.cn> References: <201104131847143284482@mail.zjgsu.edu.cn> From: Jamal Hadi Salim Date: Wed, 13 Apr 2011 06:56:26 -0400 Message-ID: To: Chuanhuang Li Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: forces , "Joel M. Halpern" Subject: Re: [forces] BasicMetadataDispatch WAS(Re: LFB LPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 10:56:47 -0000 I understand its value as metadata router. But why is it necessary in figure1? Could you not have an LFB-port-group at the EtherEncap to select the egress port EtherMACOut? Figure 1 is not consistent in the sense some LFBs are shown as FE-wide instances and in others as mediaport-specific (refer to my email to Joel). And then you have BasicMetadataDispatch routing from FE-wide to mediaport-specifics.. cheers, jamal On Wed, Apr 13, 2011 at 6:47 AM, Chuanhuang Li wrote: > BasicMetadataDispatch is defined as a general metadata dispatch LFB initi= ally. > It can be used wherever user wants to dispath packets according some spec= ial metadata. > It has more flexibility. > > Yours, > Chuanhuang > > =3D=3D=3D=3D=3D=3D=3D 2011-04-13 18:23:18 Jamal Hadi Salim, wrote: =3D=3D= =3D=3D=3D=3D=3D > >>Following up after looking at the draft some more.. >>In Figure1 is the sole purpose of BasicMetadataDispatch to just select >>a mediaport path? It doesnt seem sensible given we could use >>LFB-port-groups to select LFB (instances). >> >>cheers, >>jamal >> >>On Wed, Apr 13, 2011 at 5:32 AM, Jamal Hadi Salim wro= te: >> >>> That was my initial thinking - but now that you bring it up again, >>> you made me look closer at figure1... =A0Other than EtherPHYCop, is the= re any >>> need for any other LFB instance to be per-mediaport? Indeed, the revers= e >>> case can be also argued and you have everything per-mediaport. >>> But we do have ability for grouping of LFB-ports which can be used to m= ux >>> to different instances of the same LFB class etc. >>> Figure1 seems to have have some LFBs FE wide and some mediaport >>> specific (the mediaencap seems to be port specific). >>> >>> cheers, >>> jamal >>> >>. > From chuanhuang_li@mail.zjgsu.edu.cn Wed Apr 13 04:25:43 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id CA660E06E0 for ; Wed, 13 Apr 2011 04:25:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.223 X-Spam-Level: X-Spam-Status: No, score=0.223 tagged_above=-999 required=5 tests=[AWL=1.028, BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3zYaD5bFbqnn for ; Wed, 13 Apr 2011 04:25:43 -0700 (PDT) Received: from mail.zjgsu.edu.cn (ucmail.zjgsu.edu.cn [124.160.64.1]) by ietfc.amsl.com (Postfix) with SMTP id 921BDE068E for ; Wed, 13 Apr 2011 04:25:42 -0700 (PDT) Received: from RobinLee (unknown [10.20.0.167]) by mailportal (Coremail) with SMTP id rBCI85Dr5jAQhqVNQEIPAA--.58276S2; Wed, 13 Apr 2011 19:16:32 +0800 (CST) Date: Wed, 13 Apr 2011 19:25:58 +0800 From: "Chuanhuang Li" To: "Jamal Hadi Salim" References: <201104131847143284482@mail.zjgsu.edu.cn> Message-ID: <201104131925587965227@mail.zjgsu.edu.cn> Organization: Zhejiang Gongshang Univercity X-mailer: Foxmail 6, 15, 201, 23 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-CM-TRANSID: rBCI85Dr5jAQhqVNQEIPAA--.58276S2 X-Coremail-Antispam: 1Uf129KBjDUn29KB7ZKAUJUUUUUYxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJ3UbIYCTnIWIevJa73UjIFyTuYvj4RJUUUUUUUU X-CM-SenderInfo: pfkxt0xkxd0wxbolqzhdloh6pmjv3hxhgxhubq/ Cc: forces , "Joel M. Halpern" Subject: Re: [forces] BasicMetadataDispatch WAS(Re: LFB LPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 11:25:44 -0000 SGksSmFtYWwNCg0KSm9lbCBhbmQgV2VpbWluZyBoYWQgZGlzY3Vzc2VkIEFib3V0IHdoeSB1c2lu ZyBhIHNlcGFyYXRlZCBkaXNwYXRjaC4NClBsZWFzZSBzZWUgdGhlIGVtYWlsOg0Kc3ViamVjdDog UmU6IERlZmluaXRpb24gb2YgRXRoZXJFbmNhcHN1bGF0b3IgTEZCDQp0aW1lOiAyMDEwLTEwLTEy IGFuZCAyMDEwLTEwLTEzIA0KDQpZb3VycywNCkNodWFuaHVhbmcNCgkNCg0KPT09PT09PSAyMDEx LTA0LTEzIDE4OjQ5OjM3IEphbWFsIEhhZGkgU2FsaW0sIHdyb3RlOiA9PT09PT09DQoNCj5JIHVu ZGVyc3RhbmQgaXRzIHZhbHVlIGFzIG1ldGFkYXRhIHJvdXRlci4gQnV0IHdoeSBpcyBpdA0KPm5l Y2Vzc2FyeSBpbiBmaWd1cmUxPw0KPkNvdWxkIHlvdSBub3QgaGF2ZSBhbiBMRkItcG9ydC1ncm91 cCBhdCB0aGUgRXRoZXJFbmNhcCB0byBzZWxlY3QNCj50aGUgZWdyZXNzIHBvcnQgRXRoZXJNQUNP dXQ/DQo+DQo+RmlndXJlIDEgaXMgbm90IGNvbnNpc3RlbnQgaW4gdGhlIHNlbnNlIHNvbWUgTEZC cyBhcmUgc2hvd24gYXMNCj5GRS13aWRlIGluc3RhbmNlcyBhbmQgaW4gb3RoZXJzIGFzIG1lZGlh cG9ydC1zcGVjaWZpYyAocmVmZXIgdG8gbXkNCj5lbWFpbCB0byBKb2VsKS4gQW5kIHRoZW4geW91 IGhhdmUgQmFzaWNNZXRhZGF0YURpc3BhdGNoIHJvdXRpbmcNCj5mcm9tIEZFLXdpZGUgdG8gbWVk aWFwb3J0LXNwZWNpZmljcy4uDQo+DQo+Y2hlZXJzLA0KPmphbWFsDQo+DQo+T24gV2VkLCBBcHIg MTMsIDIwMTEgYXQgNjo0NyBBTSwgQ2h1YW5odWFuZyBMaQ0KPjxjaHVhbmh1YW5nX2xpQG1haWwu empnc3UuZWR1LmNuPiB3cm90ZToNCj4+IEJhc2ljTWV0YWRhdGFEaXNwYXRjaCBpcyBkZWZpbmVk IGFzIGEgZ2VuZXJhbCBtZXRhZGF0YSBkaXNwYXRjaCBMRkIgaW5pdGlhbGx5Lg0KPj4gSXQgY2Fu IGJlIHVzZWQgd2hlcmV2ZXIgdXNlciB3YW50cyB0byBkaXNwYXRoIHBhY2tldHMgYWNjb3JkaW5n IHNvbWUgc3BlY2lhbCBtZXRhZGF0YS4NCj4+IEl0IGhhcyBtb3JlIGZsZXhpYmlsaXR5Lg0KPj4N Cj4+IFlvdXJzLA0KPj4gQ2h1YW5odWFuZw0KPj4NCj4+ID09PT09PT0gMjAxMS0wNC0xMyAxODoy MzoxOCBKYW1hbCBIYWRpIFNhbGltLCB3cm90ZTogPT09PT09PQ0KPj4NCj4+PkZvbGxvd2luZyB1 cCBhZnRlciBsb29raW5nIGF0IHRoZSBkcmFmdCBzb21lIG1vcmUuLg0KPj4+SW4gRmlndXJlMSBp cyB0aGUgc29sZSBwdXJwb3NlIG9mIEJhc2ljTWV0YWRhdGFEaXNwYXRjaCB0byBqdXN0IHNlbGVj dA0KPj4+YSBtZWRpYXBvcnQgcGF0aD8gSXQgZG9lc250IHNlZW0gc2Vuc2libGUgZ2l2ZW4gd2Ug Y291bGQgdXNlDQo+Pj5MRkItcG9ydC1ncm91cHMgdG8gc2VsZWN0IExGQiAoaW5zdGFuY2VzKS4N Cj4+Pg0KPj4+Y2hlZXJzLA0KPj4+amFtYWwNCj4+Pg0KPj4+T24gV2VkLCBBcHIgMTMsIDIwMTEg YXQgNTozMiBBTSwgSmFtYWwgSGFkaSBTYWxpbSA8aGFkaUBtb2phdGF0dS5jb20+IHdyb3RlOg0K Pj4+DQo+Pj4+IFRoYXQgd2FzIG15IGluaXRpYWwgdGhpbmtpbmcgLSBidXQgbm93IHRoYXQgeW91 IGJyaW5nIGl0IHVwIGFnYWluLA0KPj4+PiB5b3UgbWFkZSBtZSBsb29rIGNsb3NlciBhdCBmaWd1 cmUxLi4uIKBPdGhlciB0aGFuIEV0aGVyUEhZQ29wLCBpcyB0aGVyZSBhbnkNCj4+Pj4gbmVlZCBm b3IgYW55IG90aGVyIExGQiBpbnN0YW5jZSB0byBiZSBwZXItbWVkaWFwb3J0PyBJbmRlZWQsIHRo ZSByZXZlcnNlDQo+Pj4+IGNhc2UgY2FuIGJlIGFsc28gYXJndWVkIGFuZCB5b3UgaGF2ZSBldmVy eXRoaW5nIHBlci1tZWRpYXBvcnQuDQo+Pj4+IEJ1dCB3ZSBkbyBoYXZlIGFiaWxpdHkgZm9yIGdy b3VwaW5nIG9mIExGQi1wb3J0cyB3aGljaCBjYW4gYmUgdXNlZCB0byBtdXgNCj4+Pj4gdG8gZGlm ZmVyZW50IGluc3RhbmNlcyBvZiB0aGUgc2FtZSBMRkIgY2xhc3MgZXRjLg0KPj4+PiBGaWd1cmUx IHNlZW1zIHRvIGhhdmUgaGF2ZSBzb21lIExGQnMgRkUgd2lkZSBhbmQgc29tZSBtZWRpYXBvcnQN Cj4+Pj4gc3BlY2lmaWMgKHRoZSBtZWRpYWVuY2FwIHNlZW1zIHRvIGJlIHBvcnQgc3BlY2lmaWMp Lg0KPj4+Pg0KPj4+PiBjaGVlcnMsDQo+Pj4+IGphbWFsDQo+Pj4+DQo+Pj4uDQo+Pg0K From jmh@joelhalpern.com Wed Apr 13 08:19:36 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id ADEB9E07B8 for ; Wed, 13 Apr 2011 08:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2c+iaX0AiKm9 for ; Wed, 13 Apr 2011 08:19:35 -0700 (PDT) Received: from hgblob.out.tigertech.net (hgblob.out.tigertech.net [74.114.88.71]) by ietfc.amsl.com (Postfix) with ESMTP id A0F44E0705 for ; Wed, 13 Apr 2011 08:19:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 7359B3228BE3; Wed, 13 Apr 2011 08:19:34 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [172.17.114.244] (207.47.24.2.static.nextweb.net [207.47.24.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 56A7632289B4; Wed, 13 Apr 2011 08:19:34 -0700 (PDT) Message-ID: <4DA5BF05.1090404@joelhalpern.com> Date: Wed, 13 Apr 2011 11:19:33 -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: <4DA317B9.9040604@joelhalpern.com> <4DA32104.4070601@stevecrocker.com> <4DA38B1A.4030801@stevecrocker.com> <4DA442D9.3060404@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: forces@ietf.org, Chuanhuang Li Subject: Re: [forces] LFB LPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 15:19:36 -0000 THis is a design choice which, as far as I can tell, can go either way. Obviously, we have to have a class per media type, and at least one instance per instantiated media type. Whether we use the logical L3 output port as a table index, or instantiate an LFB instance per logical L3 output port is a decision regarding which I have no preference, but we should be explicit. Yours, Joel On 4/13/2011 5:32 AM, Jamal Hadi Salim wrote: > On Tue, Apr 12, 2011 at 8:17 AM, Joel M. Halpern wrote: >> Is it your thought that we would use one mediaEncap LFB Instance per Level 3 >> output port? > > That was my initial thinking - but now that you bring it up again, > you made me look closer at figure1... Other than EtherPHYCop, is there any > need for any other LFB instance to be per-mediaport? Indeed, the reverse > case can be also argued and you have everything per-mediaport. > But we do have ability for grouping of LFB-ports which can be used to mux > to different instances of the same LFB class etc. > Figure1 seems to have have some LFBs FE wide and some mediaport > specific (the mediaencap seems to be port specific). > > cheers, > jamal > From jmh@joelhalpern.com Wed Apr 13 08:32:03 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5AA84E07D2 for ; Wed, 13 Apr 2011 08:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.599 X-Spam-Level: X-Spam-Status: No, score=-101.599 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_00=-2.599, J_CHICKENPOX_25=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_54=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8cVblJbHQOv for ; Wed, 13 Apr 2011 08:32:02 -0700 (PDT) Received: from hgblob.out.tigertech.net (hgblob.out.tigertech.net [74.114.88.71]) by ietfc.amsl.com (Postfix) with ESMTP id 87C37E0749 for ; Wed, 13 Apr 2011 08:32:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id CEB673244A1B; Wed, 13 Apr 2011 08:31:59 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [172.17.114.244] (207.47.24.2.static.nextweb.net [207.47.24.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 3952C324777B; Wed, 13 Apr 2011 08:31:59 -0700 (PDT) Message-ID: <4DA5C1E8.20504@joelhalpern.com> Date: Wed, 13 Apr 2011 11:31:52 -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: <4DA317B9.9040604@joelhalpern.com> <201104120052581097823@mail.zjgsu.edu.cn> <201104121231484534654@mail.zjgsu.edu.cn> <201104122002382030086@mail.zjgsu.edu.cn> <201104131830052038064@mail.zjgsu.edu.cn> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "forces@ietf.org" , Chuanhuang Li Subject: Re: [forces] LFB LPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 15:32:03 -0000 The question with regard to the ARP table is how we want to handle destination hosts on the local subnet. We can do it by having an entry in the LPM, NH, and encap LFBs for each host. While that is potentially a lot of entries, it is not too many to support (LPMs have to handle 100's of thousands of entries anyway.) Alternatively, we could have the ARP table in the encap LFB, and just have a single "local" entry in the other tables. Either design works. In the long run, I think the later is conceptually cleaner in that creating an entry for a new host on the subnet means modifying only one table instead of three. Yours, Joel On 4/13/2011 6:45 AM, Jamal Hadi Salim wrote: > Hi Chuanhuang, > > On Wed, Apr 13, 2011 at 6:30 AM, Chuanhuang Li > wrote: >> Hi,Jamal >> Sorry. From the context, Do you mean : if user need to support ARP/ND on FE, >> ARP/ND logic should be >> implemented in the EtherEncap LFB,? > > If they are going to be implementing ARP, IMO it should not be defined in this > specific LFB. For this LFB we assume something (CE most likely) is going > to populate neighbor L2 information. If you use ARP/ND or have static entries > and how you do so - that is the problem of the implementation, not the model. > >> And Etherencap LFB includes the defintions of Encap talbe(no IP information) >> and ARP/ND table(have IP information)? > > My opinion is to not have any ARP/ND table here. Maybe Joel has a different > opinion. > >> If so, I think there are duplicated definitions about L2 information in this LFB. >> and in my thought, the ARP/ND logic shouldn't be included in EtherEncap LFB. > > Refer to above. > >> If you mean there is only Encap talbe in EtherEncap LFB, how to resolve >> the problem which >> I had posted in previous email? (processing packets which need to be >> forwarded to the subnet hosts.) > > Is subnet host meaning "directly connected" routes? > I am not sure if we are distinguishing those from a host that is > say more than one hop away? > To re-iterate what i said earlier about ARP/ND implementation: > > NHIP and Encap Table index (or other) are passed to the Etherencap > as metadata. One approach is to try and index with passed index > into Encap Table and fail - which means NH L2 has not been resolved. > At this point, your implementation may do ARP. The model shouldnt > care and should not have information on ARP. > When the ARP/ND is resolved, you will have enough information > so that the Encap table is populated by at a chosen table index. > This same Encap Table index is updated to the NH > so it can be used by subsequent packet (so we dont have lookup > failure in Encap Table). > Does that make sense? > > cheers, > jamal > From hadi@mojatatu.com Thu Apr 14 04:27:48 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6419CE06C1 for ; Thu, 14 Apr 2011 04:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.57 X-Spam-Level: X-Spam-Status: No, score=-101.57 tagged_above=-999 required=5 tests=[AWL=-0.193, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_25=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IOBERtyMpsMm for ; Thu, 14 Apr 2011 04:27:47 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfc.amsl.com (Postfix) with ESMTP id 9E06DE06E4 for ; Thu, 14 Apr 2011 04:27:47 -0700 (PDT) Received: by vxg33 with SMTP id 33so1512432vxg.31 for ; Thu, 14 Apr 2011 04:27:47 -0700 (PDT) Received: by 10.52.69.140 with SMTP id e12mr903943vdu.187.1302780467115; Thu, 14 Apr 2011 04:27:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.181.77 with HTTP; Thu, 14 Apr 2011 04:27:26 -0700 (PDT) In-Reply-To: <201104131925587965227@mail.zjgsu.edu.cn> References: <201104131847143284482@mail.zjgsu.edu.cn> <201104131925587965227@mail.zjgsu.edu.cn> From: Jamal Hadi Salim Date: Thu, 14 Apr 2011 07:27:26 -0400 Message-ID: To: Chuanhuang Li Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: forces , "Joel M. Halpern" Subject: Re: [forces] BasicMetadataDispatch WAS(Re: LFB LPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 11:27:48 -0000 Ok, I think i followed the gist of the conversation and i am afraid I will have to revive some of that discussion. I apologize. I need to think a little and see how best to express my view. cheers, jamal On Wed, Apr 13, 2011 at 7:25 AM, Chuanhuang Li wrote: > Hi,Jamal > > Joel and Weiming had discussed About why using a separated dispatch. > Please see the email: > subject: Re: Definition of EtherEncapsulator LFB > time: 2010-10-12 and 2010-10-13 > > Yours, > Chuanhuang > > > =3D=3D=3D=3D=3D=3D=3D 2011-04-13 18:49:37 Jamal Hadi Salim, wrote: =3D=3D= =3D=3D=3D=3D=3D > >>I understand its value as metadata router. But why is it >>necessary in figure1? >>Could you not have an LFB-port-group at the EtherEncap to select >>the egress port EtherMACOut? >> >>Figure 1 is not consistent in the sense some LFBs are shown as >>FE-wide instances and in others as mediaport-specific (refer to my >>email to Joel). And then you have BasicMetadataDispatch routing >>from FE-wide to mediaport-specifics.. >> >>cheers, >>jamal >> >>On Wed, Apr 13, 2011 at 6:47 AM, Chuanhuang Li >> wrote: >>> BasicMetadataDispatch is defined as a general metadata dispatch LFB ini= tially. >>> It can be used wherever user wants to dispath packets according some sp= ecial metadata. >>> It has more flexibility. >>> >>> Yours, >>> Chuanhuang >>> >>> =3D=3D=3D=3D=3D=3D=3D 2011-04-13 18:23:18 Jamal Hadi Salim, wrote: =3D= =3D=3D=3D=3D=3D=3D >>> >>>>Following up after looking at the draft some more.. >>>>In Figure1 is the sole purpose of BasicMetadataDispatch to just select >>>>a mediaport path? It doesnt seem sensible given we could use >>>>LFB-port-groups to select LFB (instances). >>>> >>>>cheers, >>>>jamal >>>> >>>>On Wed, Apr 13, 2011 at 5:32 AM, Jamal Hadi Salim w= rote: >>>> >>>>> That was my initial thinking - but now that you bring it up again, >>>>> you made me look closer at figure1... =A0Other than EtherPHYCop, is t= here any >>>>> need for any other LFB instance to be per-mediaport? Indeed, the reve= rse >>>>> case can be also argued and you have everything per-mediaport. >>>>> But we do have ability for grouping of LFB-ports which can be used to= mux >>>>> to different instances of the same LFB class etc. >>>>> Figure1 seems to have have some LFBs FE wide and some mediaport >>>>> specific (the mediaencap seems to be port specific). >>>>> >>>>> cheers, >>>>> jamal >>>>> >>>>. >>> > From hadi@mojatatu.com Thu Apr 14 05:23:18 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A328BE089C for ; Thu, 14 Apr 2011 05:23:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.562 X-Spam-Level: X-Spam-Status: No, score=-101.562 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_25=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K5RTPe-Z5rXj for ; Thu, 14 Apr 2011 05:23:17 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfc.amsl.com (Postfix) with ESMTP id B63CEE088B for ; Thu, 14 Apr 2011 05:23:17 -0700 (PDT) Received: by vxg33 with SMTP id 33so1554821vxg.31 for ; Thu, 14 Apr 2011 05:23:17 -0700 (PDT) Received: by 10.52.97.99 with SMTP id dz3mr953050vdb.267.1302783797179; Thu, 14 Apr 2011 05:23:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.181.77 with HTTP; Thu, 14 Apr 2011 05:22:57 -0700 (PDT) In-Reply-To: References: <201104131847143284482@mail.zjgsu.edu.cn> <201104131925587965227@mail.zjgsu.edu.cn> From: Jamal Hadi Salim Date: Thu, 14 Apr 2011 08:22:57 -0400 Message-ID: To: Chuanhuang Li Content-Type: multipart/mixed; boundary=20cf307ca1dc73363004a0dffdf7 Cc: forces , "Joel M. Halpern" Subject: Re: [forces] BasicMetadataDispatch WAS(Re: LFB LPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 12:23:18 -0000 --20cf307ca1dc73363004a0dffdf7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable So my take on this is there is confusion at least for me because we talk about L2 but dont go further (given it is out of scope). I believe we need to talk about the relationship in the draft. This applies to tunneling like GRE or ethernet MPLS etc not just to VLANs. I have attached a text file with two figures. The first one shows a small change to the egress side to be aware of L2 as we do in Ethermacin. The second model is better IMO. Note: in both cases, there is no dispatch LFB, we have each Etherencap using an LFB-port-group to select amongst many EtherMAC outs. cheers, jamal On Thu, Apr 14, 2011 at 7:27 AM, Jamal Hadi Salim wrote= : > Ok, I think i followed the gist of the conversation and i am > afraid I will have to revive some of that discussion. I apologize. > > I need to think a little and see how best to express my view. > > cheers, > jamal > > On Wed, Apr 13, 2011 at 7:25 AM, Chuanhuang Li > wrote: >> Hi,Jamal >> >> Joel and Weiming had discussed About why using a separated dispatch. >> Please see the email: >> subject: Re: Definition of EtherEncapsulator LFB >> time: 2010-10-12 and 2010-10-13 >> >> Yours, >> Chuanhuang >> >> >> =3D=3D=3D=3D=3D=3D=3D 2011-04-13 18:49:37 Jamal Hadi Salim, wrote: =3D= =3D=3D=3D=3D=3D=3D >> >>>I understand its value as metadata router. But why is it >>>necessary in figure1? >>>Could you not have an LFB-port-group at the EtherEncap to select >>>the egress port EtherMACOut? >>> >>>Figure 1 is not consistent in the sense some LFBs are shown as >>>FE-wide instances and in others as mediaport-specific (refer to my >>>email to Joel). And then you have BasicMetadataDispatch routing >>>from FE-wide to mediaport-specifics.. >>> >>>cheers, >>>jamal >>> >>>On Wed, Apr 13, 2011 at 6:47 AM, Chuanhuang Li >>> wrote: >>>> BasicMetadataDispatch is defined as a general metadata dispatch LFB in= itially. >>>> It can be used wherever user wants to dispath packets according some s= pecial metadata. >>>> It has more flexibility. >>>> >>>> Yours, >>>> Chuanhuang >>>> >>>> =3D=3D=3D=3D=3D=3D=3D 2011-04-13 18:23:18 Jamal Hadi Salim, wrote: =3D= =3D=3D=3D=3D=3D=3D >>>> >>>>>Following up after looking at the draft some more.. >>>>>In Figure1 is the sole purpose of BasicMetadataDispatch to just select >>>>>a mediaport path? It doesnt seem sensible given we could use >>>>>LFB-port-groups to select LFB (instances). >>>>> >>>>>cheers, >>>>>jamal >>>>> >>>>>On Wed, Apr 13, 2011 at 5:32 AM, Jamal Hadi Salim = wrote: >>>>> >>>>>> That was my initial thinking - but now that you bring it up again, >>>>>> you made me look closer at figure1... =A0Other than EtherPHYCop, is = there any >>>>>> need for any other LFB instance to be per-mediaport? Indeed, the rev= erse >>>>>> case can be also argued and you have everything per-mediaport. >>>>>> But we do have ability for grouping of LFB-ports which can be used t= o mux >>>>>> to different instances of the same LFB class etc. >>>>>> Figure1 seems to have have some LFBs FE wide and some mediaport >>>>>> specific (the mediaencap seems to be port specific). >>>>>> >>>>>> cheers, >>>>>> jamal >>>>>> >>>>>. >>>> >> > --20cf307ca1dc73363004a0dffdf7 Content-Type: text/plain; charset=US-ASCII; name="L2L3inter.txt" Content-Disposition: attachment; filename="L2L3inter.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gmhnocoi0 CkN1cnJlbnQgbW9kZWwsIHNsaWdodGx5IG1vZGlmaWVkCj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09CgogICAgICAgICstLS0tLSsgICArLS0tLS0tKwogICAgICAgIHwgICAgIHwgICB8 ICAgICAgfDwtLS0tLS0tLS0tLS0tPC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKICAgICAgICB8 ICAgICB8ICAgfFBvcnQjTnwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8 CiAgICAgICAgfCAgICAgfDwtLXxFdGhlciB8PC0tLS0tLS0tLS0tLS08LS0tLS0tLS0tLS0tLS0r ICAgICAgICAgfAogICAgICAgIHwgICAgIHwgICB8TUFDT3V0fCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfCAgICAgICAgIHwKICAgICAgICB8ICAgICB8ICAgfCAgICAgIHwgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHwgICAgICAgICB8CiAgICAgICAgfCAgICAgfCAgICstLS0tLS0r ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBeICAgICAgICAgfAogICAgICAgIHwgICAgIHwg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgIHwKICAgICAg ICB8ICAgICB8ICAgICAgICAgICAgICstLS0tLS0tLS0rICAgICAgICAgICAgICAgIHwgICAgICAg ICB8CiAgICAgICAgfCAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAgfC0tLS0tLT4tLS0tLS0t LS0rICAgICAgICAgXgogICAgICAgIHwgICAgIHwgICAgICArLS0tLS0+fCBMMi8gICAgIHwgICAg ICAgICAgICAgICAgICAgICAgICAgIHwKICAgICAgICB8RXRoZXJ8ICAgICAgfCAgICAgIHx0dW5u ZWxpbmd8ICAgICAgICAgICAgICAgICAgICAgICAgICB8IAogICAgICAgIHxQSFkgIHwgICAgICB8 ICAgICAgfCAgICAgICAgICstLS0tLTwtLS0tLS0tLSsgICAgICAgICAgIHwKICAgICAgICB8Q29w I058ICAgICAgfCAgICAgIHwgICAgICAgICB8ICAgICAgICAgICAgICB8ICAgICAgICAgICB8CiAg ICAgICAgfCAgICAgfCAgICAgIHwgICAgICArLS0tLS0tLS0tKyAgICAgICAgICAgICAgfCAgICAg ICAgICAgfAogICAgICAgIHwgICAgIHwgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIF4gICAgICAgICAgIF4KICAgICAgICB8ICAgICB8ICBMMkJyaWRnaW5nUGF0aE91dCAgICAg ICAgICAgICAgICAgICB8ICAgICAgICAgICB8CiAgICAgICAgfCAgICAgfCAgICAgIHwgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgfAogICAgICAgIHwgICAgIHwgICAg ICB8ICAgICAgICAgICAgICAgICAgICAgTDJCcmlkZ2luZ1BhdGhPdXQgICAgIHwgCiAgICAgICAg fCAgICAgfCAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAg fAogICAgICAgIHwgICAgIHwgICArLS0rLS0tKyAgICAgICAgICAgICAgICAgICstLS0tLS0tLSst LS0tLS0tLS0rIHwKICAgICAgICB8ICAgICB8ICAgfCAgICAgIHwgICAgICAgICAgICAgICAgICB8 IEwzIGZ1bmN0aW9uYWxpdHk6fCB8CiAgICAgICAgfCAgICAgfCAgIHwgICAgICB8ICAgICAgICAg ICAgICAgICAgfCBBbGwgZGVmaW5lZCBMRkJTIHwgfAogICAgICAgIHwgICAgIHwgICB8UG9ydCNO fCAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICB8IHwKICAgICAgICB8ICAgICB8 ICAgfEV0aGVyIHwgbWF0Y2ggTG9jYWxNQUMgICB8IChFdGhlckNsYXNzaWZpZXIgKy0rCiAgICAg ICAgfCAgICAgfC0tPnxNQUNJbiB8LS0tLS0tLS0tLS0tLS0tLS0+fCAgICAgIHRvICAgICAgICAg IHwKICAgICAgICB8ICAgICB8ICAgfCAgICAgIHwgb3Igbm8gTDJCcmlkZ2luZz98ICAgRXRoZXJF bmNhcCApICAgfAogICAgICAgIHwgICAgIHwgICArLS0tLS0tKyAgICAgICAgICAgICAgICAgICst LS0tLS0tLS0tLS0tLS0tLS0rICAKICAgICAgICB8ICAgICB8IAogICAgICAgICstLS0tLSsKCgoK QWx0aG91Z2ggYWJvdmUgc2hvd3MgTDIvVkxBTnMsIHRoZSBjb25jZXB0IGFwcGxpZXMgdG8gdHVu bmVscwooR1JFLCBFdGhlcm5ldC1NUExTIGV0YykuCgpJbmdyZXNzOgotLS0tLS0tCkwyIGlzIGJ5 cGFzc2VkIGlmIHdlIG1hdGNoIGEgTG9jYWwgUm91dGVyIE1BQy4gV2UgbWF5IG5lZWQKdG8gY2hh bmdlIHRoaXMgYW5kIHBhc3MgZXZlcnl0aGluZyB0byBMMiBpZiBpdCBlbmFibGVkLgoocmVmZXIg dG8gYWx0ZXJuYXRpdmUgbW9kZWwgYmVsb3cpLgpMMiBzdWJzeXN0ZW0gaGFzIHBlciBWTEFOIHRh Ymxlcywgb3B0aW9uYWxseSBwZXIgcG9ydC4KTDIgbG9va3VwIGlzIChvcHRpb25hbGx5IHBvcnQg KykgRFNUTUFDICsgVkxBTklELgoKTWlkZGxlOgotLS0tLS0tCkwzIGNhbiBjcm9zcyBWTEFOcyBi dXQgTDIgY2FudCAoYnkgZGVmaW5pdGlvbikuCgpFZ3Jlc3M6Ci0tLS0tLS0KTDMgY3Jvc3NlcyBW TEFOcyBhdCBFdGhlckVuY2FwIGxldmVsLgoqTWlzc2luZyBpbiB0ZXh0IGJ1dCBJIGhhdmUgYWRk ZWQgYWJvdmUgaXMgTDJCcmlkZ2luZ1BhdGhPdXQgYXQgRXRoZXJlbmNhcDogCnRlbGwgRXRoZXJl bmNhcCB0byBnbyB0byBMMiBvciBieXBhc3MgaXQuIFRoaXMgcmVkdWNlcyBkaXNjdXNzaW9ucyBv biBMMgppbnQgdGhlIHRleHQKCipXaGVuIG5vdCBieXBhc3Npbmc6CkwzIEV0aGVyRW5jYXAgcGFz c2VzIGFzIG1ldGFkYXRhIE5IIHBvcnQsIGRzdE1BQyBhbmQgVkxBTklEIHRvIEwyIApmb3IgZnVy dGhlciBwcm9jZXNzaW5nLgpMMiBtYXkgZW5kIHVwIGdvaW5nIGEgZGlmZmVyZW50IHBvcnQgdGhh biB0aGUgb25lIHBlcmNlaXZlZCBieSBMMy4KCkFsdGVybmF0aXZlIG1vZGVsIAo9PT09PT09PT09 PT09PT09PQpFdmVyeXRoaW5nIGdvZXMgdG8gTDIgaWYgTDJCcmlkZ2luZ1BhdGhPdXQgaXMgc2V0 OyBpbiB3aGljaCBjYXNlCkwyIHRhYmxlcyBjb250YWluIGVudHJpZXMgb2YgTG9jYWxNQUNzLgpJ ZiB3ZSBkbyB0aGF0LCB3ZSBuZWVkIHRvIGhhdmUgYSB3YXkgZm9yIEwyIHRvIGZlZWRiYWNrIHRv IEwzIHdoZW4KaXQgZmluZHMgYSBsb2NhbE1BQyBhcyBzaG93biBiZWxvdzoKCgogICAgICAgICst LS0tLSsgICArLS0tLS0tKwogICAgICAgIHwgICAgIHwgICB8ICAgICAgfDwtLS0tLS0tLS0tLS0t PC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwogICAgICAgIHwgICAgIHwgICB8UG9ydCNOfCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgICAgIHwgICAgIHw8LS18RXRo ZXIgfDwtLS0tLS0tLS0tLS0tPC0tLS0tLS0tLS0tLS0tKyAgICAgICAgfAogICAgICAgIHwgICAg IHwgICB8TUFDT3V0fCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgfAogICAg ICAgIHwgICAgIHwgICB8ICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAg ICAgfAogICAgICAgIHwgICAgIHwgICArLS0tLS0tKyAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgXiAgICAgICAgfAogICAgICAgIHwgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgfCAgICAgICAgfAogICAgICAgIHwgICAgIHwgICAgICAgICAgICAgKy0tLS0t LS0tLSsgICAgICAgICAgICAgICAgfCAgICAgICAgfAogICAgICAgIHwgICAgIHwgICAgICAgICAg ICAgfCAgICAgICAgIHwtLS0tLS0+LS0tLS0tLS0tKyAgICAgICAgXgogICAgICAgIHwgICAgIHwg ICAgICArLS0tLS0+fCBMMi8gICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgICAg IHxFdGhlcnwgICAgICB8ICAgICAgfHR1bm5lbGluZ3wgICAgICAgICAgICAgICAgICAgICAgICAg fCAKICAgICAgICB8UEhZICB8ICAgICAgfCAgICAgIHwgICAgICAgICArLS0tLS08LS0tLS0tLS0r ICAgICAgICAgIHwKICAgICAgICB8Q29wI058ICAgICAgfCAgICAgIHwgICAgICAgICB8ICAgICAg ICAgICAgICB8ICAgICAgICAgIHwKICAgICAgICB8ICAgICB8ICAgICAgfCAgICAgICstLS0tLS0r LS0rICAgICAgICAgICAgICB8ICAgICAgICAgIHwKICAgICAgICB8ICAgICB8ICAgICAgfCAgICAg ICAgICAgICB8ICAgICAgICAgICAgICAgICBeICAgICAgICAgIF4KICAgICAgICB8ICAgICB8ICAg ICAgfCAgICAgICAgICBMb2NhbE1BQ3MgICAgICAgICAgICB8ICAgICAgICAgIHwKICAgICAgICB8 ICAgICB8ICBMMkJyaWRnaW5nICAgICAgICB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgIHwK ICAgICAgICB8ICAgICB8ICAgUGF0aE91dCAgICAgICAgICB8ICAgICAgICAgICAgICAgICB8ICAg ICAgICAgIHwKICAgICAgICB8ICAgICB8ICAgICAgfCAgICAgICAgICAgICBWICAgICAgIEwyQnJp ZGdpbmdQYXRoT3V0ICAgIHwgCiAgICAgICAgfCAgICAgfCAgICAgIHwgICAgICAgICAgICAgfCAg ICAgICAgICAgICAgICAgfCAgICAgICAgICB8CiAgICAgICAgfCAgICAgfCAgICAgIHwgICAgICAg ICAgICAgViAgICAgICAgICAgICAgICAgfCAgICAgICAgICB8CiAgICAgICAgfCAgICAgfCAgICst LSstLS0rICAgICAgICAgfCAgICAgICArLS0tLS0tLS0tKy0tLS0tLS0tKyB8CiAgICAgICAgfCAg ICAgfCAgIHwgICAgICB8ICAgICAgICAgKy0tLS0tLT58IEwzIGZ1bmN0aW9uYWxpdHk6fCB8CiAg ICAgICAgfCAgICAgfCAgIHwgICAgICB8ICAgICAgICAgICAgICAgICB8IEFsbCBkZWZpbmVkIExG QlMgfCB8CiAgICAgICAgfCAgICAgfCAgIHxQb3J0I058ICAgICAgICAgICAgICAgICB8ICAgICAg ICAgICAgICAgICAgfCB8CiAgICAgICAgfCAgICAgfCAgIHxFdGhlciB8ICAgICAgICAgICAgICAg ICB8IChFdGhlckNsYXNzaWZpZXIgKy0rCiAgICAgICAgfCAgICAgfC0tPnxNQUNJbiB8LS0tLS0t Pi0tLS0tLS0tLT58ICAgICAgdG8gICAgICAgICAgfAogICAgICAgIHwgICAgIHwgICB8ICAgICAg fCBubyBMMkJyaWRnaW5nICAgfCAgIEV0aGVyRW5jYXAgKSAgIHwKICAgICAgICB8ICAgICB8ICAg Ky0tLS0tLSsgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0rICAKICAgICAgICB8 ICAgICB8IAogICAgICAgICstLS0tLSsKCgo= --20cf307ca1dc73363004a0dffdf7-- From chuanhuang_li@mail.zjgsu.edu.cn Thu Apr 14 07:43:03 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E54EBE069F for ; Thu, 14 Apr 2011 07:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.765 X-Spam-Level: X-Spam-Status: No, score=0.765 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_05=-1.11, J_CHICKENPOX_25=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_54=0.6] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YEGyQvq-m1DK for ; Thu, 14 Apr 2011 07:43:03 -0700 (PDT) Received: from mail.zjgsu.edu.cn (ucmail.zjgsu.edu.cn [124.160.64.1]) by ietfc.amsl.com (Postfix) with SMTP id 38185E066B for ; Thu, 14 Apr 2011 07:43:00 -0700 (PDT) Received: from RobinLee (unknown [10.20.0.167]) by mailportal (Coremail) with SMTP id rBCI85DbvDLDBadNQEIPAA--.60868S2; Thu, 14 Apr 2011 22:33:39 +0800 (CST) Date: Thu, 14 Apr 2011 22:43:16 +0800 From: "Chuanhuang Li" To: "Joel M. Halpern" , "Jamal Hadi Salim" References: , , , , <4DA317B9.9040604@joelhalpern.com>, <201104120052581097823@mail.zjgsu.edu.cn>, <201104121231484534654@mail.zjgsu.edu.cn>, <201104122002382030086@mail.zjgsu.edu.cn>, <201104131830052038064@mail.zjgsu.edu.cn>, Message-ID: <201104142243163753825@mail.zjgsu.edu.cn> Organization: Zhejiang Gongshang Univercity X-mailer: Foxmail 6, 15, 201, 23 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-CM-TRANSID: rBCI85DbvDLDBadNQEIPAA--.60868S2 X-Coremail-Antispam: 1Uf129KBjDUn29KB7ZKAUJUUUUUYxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJ3UbIYCTnIWIevJa73UjIFyTuYvj4RJUUUUUUUU X-CM-SenderInfo: pfkxt0xkxd0wxbolqzhdloh6pmjv3hxhgxhubq/ Cc: "forces@ietf.org" Subject: Re: [forces] LFB LPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 14:43:04 -0000 Hi, All I summarzed the points that we had discussed on NH and EtherEncap LFB: I think we have reached a consensus on the following points. 1: Add an element named "NHEncapInfoIndex" to the NH table component in NH LFB. 2: Define an element named such as "FillFlag" to indicate whether the table entry had been filled. 3: Continue to have the LogicalPortID element in L2 information table . And we need pick up a consensus way to solve the following points: 4: Is L2 information table exactly ARP/ND table? or need redefine an Encap Table with no IP information in EtherEncap LFB? L2 information table is exactly ARP/ND table: the current definition of Encap LFB will be changed a little, and it can solve the problem of forwarding packets to dirrectly connected hosts. As Joel said, in the long run, It is conceptually cleaner. Jamal, can you accept this resolution? and do you have any other suggestion? 5: Is "EncapInfoIndex" in L2 information table just the talbe index? or we define it as an element of the table content? I think we define it as an table element may be good to user to manager the table. What's your opinion?Thanks! Yours, Chuanhuang ======= 2011-04-13 23:24:37 Joel M. Halpern, wrote: ======= >The question with regard to the ARP table is how we want to handle >destination hosts on the local subnet. >We can do it by having an entry in the LPM, NH, and encap LFBs for each >host. While that is potentially a lot of entries, it is not too many to >support (LPMs have to handle 100's of thousands of entries anyway.) > >Alternatively, we could have the ARP table in the encap LFB, and just >have a single "local" entry in the other tables. > >Either design works. In the long run, I think the later is conceptually >cleaner in that creating an entry for a new host on the subnet means >modifying only one table instead of three. > >Yours, >Joel > >On 4/13/2011 6:45 AM, Jamal Hadi Salim wrote: >> Hi Chuanhuang, >> >> On Wed, Apr 13, 2011 at 6:30 AM, Chuanhuang Li >> wrote: >>> Hi,Jamal >>> Sorry. From the context, Do you mean : if user need to support ARP/ND on FE, >>> ARP/ND logic should be >>> implemented in the EtherEncap LFB,? >> >> If they are going to be implementing ARP, IMO it should not be defined in this >> specific LFB. For this LFB we assume something (CE most likely) is going >> to populate neighbor L2 information. If you use ARP/ND or have static entries >> and how you do so - that is the problem of the implementation, not the model. >> >>> And Etherencap LFB includes the defintions of Encap talbe(no IP information) >>> and ARP/ND table(have IP information)? >> >> My opinion is to not have any ARP/ND table here. Maybe Joel has a different >> opinion. >> >>> If so, I think there are duplicated definitions about L2 information in this LFB. >>> and in my thought, the ARP/ND logic shouldn't be included in EtherEncap LFB. >> >> Refer to above. >> >>> If you mean there is only Encap talbe in EtherEncap LFB, how to resolve >>> the problem which >>> I had posted in previous email? (processing packets which need to be >>> forwarded to the subnet hosts.) >> >> Is subnet host meaning "directly connected" routes? >> I am not sure if we are distinguishing those from a host that is >> say more than one hop away? >> To re-iterate what i said earlier about ARP/ND implementation: >> >> NHIP and Encap Table index (or other) are passed to the Etherencap >> as metadata. One approach is to try and index with passed index >> into Encap Table and fail - which means NH L2 has not been resolved. >> At this point, your implementation may do ARP. The model shouldnt >> care and should not have information on ARP. >> When the ARP/ND is resolved, you will have enough information >> so that the Encap table is populated by at a chosen table index. >> This same Encap Table index is updated to the NH >> so it can be used by subsequent packet (so we dont have lookup >> failure in Encap Table). >> Does that make sense? >> >> cheers, >> jamal >> From jmh@joelhalpern.com Thu Apr 14 07:52:48 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E4D99E06FA for ; Thu, 14 Apr 2011 07:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_25=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1kscS+aQGcQE for ; Thu, 14 Apr 2011 07:52:48 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes.out.tigertech.net [74.114.88.72]) by ietfc.amsl.com (Postfix) with ESMTP id CEE6DE0699 for ; Thu, 14 Apr 2011 07:52:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2D7134300F1; Thu, 14 Apr 2011 07:52:47 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [172.17.114.244] (207.47.24.2.static.nextweb.net [207.47.24.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id F28414300EA; Thu, 14 Apr 2011 07:52:46 -0700 (PDT) Message-ID: <4DA70A3D.1010302@joelhalpern.com> Date: Thu, 14 Apr 2011 10:52:45 -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: <201104131847143284482@mail.zjgsu.edu.cn> <201104131925587965227@mail.zjgsu.edu.cn> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: forces , Chuanhuang Li Subject: Re: [forces] BasicMetadataDispatch WAS(Re: LFB LPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 14:52:49 -0000 I find the figures the way you labelled them confusing, because the EtherClassifier is not an L3 element. In particular, for example, it would demux and hand off bridging control protocols. The other confusing thing is that you are handing the local delivery determination to the bridging function. I can live with that, but there are various things that have to be handled locally, and not handed to bridging logic. Yours, Joel On 4/14/2011 8:22 AM, Jamal Hadi Salim wrote: > So my take on this is there is confusion at least for me because we > talk about L2 but dont go further (given it is out of scope). I believe we > need to talk about the relationship in the draft. This applies to > tunneling like GRE or ethernet MPLS etc not just to VLANs. > > I have attached a text file with two figures. The first one shows > a small change to the egress side to be aware of L2 > as we do in Ethermacin. The second model is better IMO. > > Note: in both cases, there is no dispatch LFB, we have each > Etherencap using an LFB-port-group to select amongst many > EtherMAC outs. > > cheers, > jamal > > On Thu, Apr 14, 2011 at 7:27 AM, Jamal Hadi Salim wrote: >> Ok, I think i followed the gist of the conversation and i am >> afraid I will have to revive some of that discussion. I apologize. >> >> I need to think a little and see how best to express my view. >> >> cheers, >> jamal >> >> On Wed, Apr 13, 2011 at 7:25 AM, Chuanhuang Li >> wrote: >>> Hi,Jamal >>> >>> Joel and Weiming had discussed About why using a separated dispatch. >>> Please see the email: >>> subject: Re: Definition of EtherEncapsulator LFB >>> time: 2010-10-12 and 2010-10-13 >>> >>> Yours, >>> Chuanhuang >>> >>> >>> ======= 2011-04-13 18:49:37 Jamal Hadi Salim, wrote: ======= >>> >>>> I understand its value as metadata router. But why is it >>>> necessary in figure1? >>>> Could you not have an LFB-port-group at the EtherEncap to select >>>> the egress port EtherMACOut? >>>> >>>> Figure 1 is not consistent in the sense some LFBs are shown as >>>> FE-wide instances and in others as mediaport-specific (refer to my >>>> email to Joel). And then you have BasicMetadataDispatch routing >>> >from FE-wide to mediaport-specifics.. >>>> >>>> cheers, >>>> jamal >>>> >>>> On Wed, Apr 13, 2011 at 6:47 AM, Chuanhuang Li >>>> wrote: >>>>> BasicMetadataDispatch is defined as a general metadata dispatch LFB initially. >>>>> It can be used wherever user wants to dispath packets according some special metadata. >>>>> It has more flexibility. >>>>> >>>>> Yours, >>>>> Chuanhuang >>>>> >>>>> ======= 2011-04-13 18:23:18 Jamal Hadi Salim, wrote: ======= >>>>> >>>>>> Following up after looking at the draft some more.. >>>>>> In Figure1 is the sole purpose of BasicMetadataDispatch to just select >>>>>> a mediaport path? It doesnt seem sensible given we could use >>>>>> LFB-port-groups to select LFB (instances). >>>>>> >>>>>> cheers, >>>>>> jamal >>>>>> >>>>>> On Wed, Apr 13, 2011 at 5:32 AM, Jamal Hadi Salim wrote: >>>>>> >>>>>>> That was my initial thinking - but now that you bring it up again, >>>>>>> you made me look closer at figure1... Other than EtherPHYCop, is there any >>>>>>> need for any other LFB instance to be per-mediaport? Indeed, the reverse >>>>>>> case can be also argued and you have everything per-mediaport. >>>>>>> But we do have ability for grouping of LFB-ports which can be used to mux >>>>>>> to different instances of the same LFB class etc. >>>>>>> Figure1 seems to have have some LFBs FE wide and some mediaport >>>>>>> specific (the mediaencap seems to be port specific). >>>>>>> >>>>>>> cheers, >>>>>>> jamal >>>>>>> >>>>>> . >>>>> >>> >> From wmwang2001@hotmail.com Thu Apr 14 20:21:39 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 11A87E0677 for ; Thu, 14 Apr 2011 20:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.754 X-Spam-Level: * X-Spam-Status: No, score=1.754 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ymGfzVVtWFp for ; Thu, 14 Apr 2011 20:21:38 -0700 (PDT) Received: from blu0-omc4-s37.blu0.hotmail.com (blu0-omc4-s37.blu0.hotmail.com [65.55.111.176]) by ietfc.amsl.com (Postfix) with ESMTP id 2293AE0715 for ; Thu, 14 Apr 2011 20:21:35 -0700 (PDT) Received: from BLU0-SMTP131 ([65.55.111.137]) by blu0-omc4-s37.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Apr 2011 20:21:35 -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-SMTP131.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Apr 2011 20:21:33 -0700 From: "Wang,Weiming" To: "Jamal Hadi Salim" , References: Date: Fri, 15 Apr 2011 11:21:16 +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: 15 Apr 2011 03:21:33.0737 (UTC) FILETIME=[38989190:01CBFB1C] Subject: Re: [forces] LFBLib v3: typos etc X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 03:21:39 -0000 Q2h1YW5odWFuZywgInBha2NldCIgdHlwb2VzIGFyZSBpbiB0aGUgeG1sLiBwbHMgY2hlY2sgdG8g Y29ycmVudCBpdC4gDQoNCkphbWFsLCAgSSBoYXZuJ3QgZm91bmQgdGhlIGxmYiB0eXBvZXMuICBO b3Qgc3VyZSBpZiBpdCBpcyBiZWNhdXNlIG9mIHRoZSB2ZXJzaW9uIGRpZmZlcmVuY2UuDQoNCnRo YW5rcywNCldlaW1pbmcNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJK YW1hbCBIYWRpIFNhbGltIiA8aGFkaUBtb2phdGF0dS5jb20+DQoNCj4gVGhlcmUgYXJlIGEgZmV3 IHR5cG9zLCBidHc6DQo+IA0KPiAxKSBpbmNvbnNpc3RlbmNpZXMgaW4gc3BlbGxpbmcgTEZCIHNv bWV0aW1lIGFzIGxmYiBhbmQgc29tZXRpbWVzDQo+IGluIG1peGVkIHVwcGVyIGFuZCBsb3dlciBj YXNlDQo+IDIpIHNwZWxsaW5nLiBFeGFtcGxlICJwYWNrZXQiIHNvbWV0aW1lcyBzaG93cyB1cCBh cyAicGFrY2V0Ig0KPiANCj4gY2hlZXJzLA0KPiBqYW1hbA0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBmb3JjZXMgbWFpbGluZyBsaXN0DQo+IGZv cmNlc0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Zv cmNlcw0KPg== From wmwang2001@hotmail.com Fri Apr 15 00:26:25 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 3B68EE0755 for ; Fri, 15 Apr 2011 00:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.961 X-Spam-Level: * X-Spam-Status: No, score=1.961 tagged_above=-999 required=5 tests=[AWL=-0.207, BAYES_40=-0.185, J_CHICKENPOX_25=0.6, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RTxLWZHLi7z9 for ; Fri, 15 Apr 2011 00:26:24 -0700 (PDT) Received: from blu0-omc1-s3.blu0.hotmail.com (blu0-omc1-s3.blu0.hotmail.com [65.55.116.14]) by ietfc.amsl.com (Postfix) with ESMTP id E1C1EE06A3 for ; Fri, 15 Apr 2011 00:26:04 -0700 (PDT) Received: from BLU0-SMTP136 ([65.55.116.9]) by blu0-omc1-s3.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 15 Apr 2011 00:26:04 -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-SMTP136.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 15 Apr 2011 00:26:03 -0700 From: "Wang,Weiming" To: "Jamal Hadi Salim" , "Chuanhuang Li" References: <201104131847143284482@mail.zjgsu.edu.cn><201104131925587965227@mail.zjgsu.edu.cn> Date: Fri, 15 Apr 2011 15:25:46 +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: 15 Apr 2011 07:26:03.0480 (UTC) FILETIME=[6071B580:01CBFB3E] Cc: forces , wmwang@zjgsu.edu.cn, "Joel M. Halpern" Subject: Re: [forces] BasicMetadataDispatch WAS(Re: LFB LPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 07:26:25 -0000 SmFtYWwsIA0KDQpXZSBoYXZlIGFscmVhZHkgaGFkIGRpc2N1c3Npb25zIG9uIHdoeSB3ZSBzaG91 bGQgbm90IHJlcGx5IG9uIEV0aGVyZW5jYXAgTEZCIHBvcnQgZ3JvdXBzICB0byBkbyB0aGUgcG9y dCBkaXNwYXRjaC4gVGhlIGtleSBwb2ludCBpcyB3ZSBtYXkgaGF2ZSB0byBjb25zaWRlciBzb21l IGNhc2VzIHdoZXJlIGxvZ2ljYWwgcG9ydCBkaXNwYXRjaCBhY3R1YWxseSBoYXBwZW5zIGJlZm9y ZSBFdGhlcmVuY2FwLiBUaGlzIGFsc28gYWN0dWFsbHkgbWVhbnMgYW4gRXRoZXJlbmNhcCBMRkIg d2UgY3VycmVudGx5IGRlZmluZWQgaXMgY2FwYWJsZSBvZiBlaXRoZXJlIHBlciBwaHlzaWNhbCBw b3J0IHBlciB0aGlzIGluc3RhbmNlIG9yIGFsbCBwaHlzaWNhbCBwb3J0cyBvbmUgdGhpcyBlbmNh cCBMRkIgaW5zdGFuY2UgY2FzZXMuIFdlIHNob3VsZCBub3QgcHJlZGV0ZXJtaW5lIHRoaXMgcmVs YXRpb25zaGlwLiANCg0KUGxzIHNlZSBlbWFpbHMgb24gdGhpcyB0b3BpYyBpbiANClNlbnQ6IGJ5 IEpvZWwgb24gVHVlc2RheSwgT2N0b2JlciAxMiwgMjAxMCAxMDo0MSBQTQ0KU3ViamVjdDogUmU6 IERlZmluaXRpb24gb2YgRXRoZXJFbmNhcHN1bGF0b3IgTEZCDQoNCg0KU2VudDogYnkgd2VpbWlu ZyBvbiBUdWVzZGF5LCBPY3RvYmVyIDEyLCAyMDEwIDg6MjAgUE0NClN1YmplY3Q6IFJlOiBEZWZp bml0aW9uIG9mIEV0aGVyRW5jYXBzdWxhdG9yIExGQg0KDQpCVFcsIGZpZ3VyZSAxIGluIHRoZSBk cmFmdCBpcyBhIGdsb2JhbCBvbmUgRkUtd2lkZS4gQnV0IHRoZSBleGFtcGxlIHRha2VzIHRoZSBj YXNlIHRoYXQgb25seSBvbmUgRXRoZXJlbmNhcCBMRkIgaW5zdGFuY2UgZm9yIGFsbCBwaHlzaWNh bCBwb3J0cy4gSSB0aGluayB3ZSBjYW4gZWFzaWVybHkgZHJhdyBhbiBleGFtcGxlIHdoZXJlIEV0 aGVyZW5jYXAgTEZCIGlzIGluc3RhbmNpYXRlZCBwZXIgcGh5c2ljYWwgcG9ydC4gSW4gdGhpcyBj YXNlLCBhICBNZXRhZGF0YURpc3BhdGNoIExGQiBzaG91bGQgYmUgYXBwbGllZCBhZnRlciBhbiBO SCBMRkIuIE1ldGFkYXRhIHVzZWQgdG8gZGlzcGF0Y2ggd2lsbCB1c3VhbGx5IGJlIGxvZ2ljYWwg cG9ydCBJRC4gQmVjYXVzZSBvZiB0aGlzLCBJIHRoaW5rIHRoZSBOSCBMRkIgc3RpbGwgbmVlZHMg dG8gaGF2ZSBsb2dpY2FsIHBvcnQgSUQgYXMgaXRzIG1ldGFkYXRhIG91dHB1dC4gDQoNCg0KdGhh bmtzLA0KV2VpbWluZw0KDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAi SmFtYWwgSGFkaSBTYWxpbSIgPGhhZGlAbW9qYXRhdHUuY29tPg0KU3ViamVjdDogUmU6IFtmb3Jj ZXNdIEJhc2ljTWV0YWRhdGFEaXNwYXRjaCBXQVMoUmU6IExGQiBMUE0gaXNzdWUNCg0KDQpTbyBt eSB0YWtlIG9uIHRoaXMgaXMgdGhlcmUgaXMgY29uZnVzaW9uIGF0IGxlYXN0IGZvciBtZSBiZWNh dXNlIHdlDQp0YWxrIGFib3V0IEwyIGJ1dCBkb250IGdvIGZ1cnRoZXIgKGdpdmVuIGl0IGlzIG91 dCBvZiBzY29wZSkuIEkgYmVsaWV2ZSB3ZQ0KbmVlZCB0byB0YWxrIGFib3V0IHRoZSByZWxhdGlv bnNoaXAgaW4gdGhlIGRyYWZ0LiBUaGlzIGFwcGxpZXMgdG8NCnR1bm5lbGluZyBsaWtlIEdSRSBv ciBldGhlcm5ldCBNUExTIGV0YyBub3QganVzdCB0byBWTEFOcy4NCg0KSSBoYXZlIGF0dGFjaGVk IGEgdGV4dCBmaWxlIHdpdGggdHdvIGZpZ3VyZXMuIFRoZSBmaXJzdCBvbmUgc2hvd3MNCmEgc21h bGwgY2hhbmdlIHRvIHRoZSBlZ3Jlc3Mgc2lkZSB0byBiZSBhd2FyZSBvZiBMMg0KYXMgd2UgZG8g aW4gRXRoZXJtYWNpbi4gVGhlIHNlY29uZCBtb2RlbCBpcyBiZXR0ZXIgSU1PLg0KDQpOb3RlOiBp biBib3RoIGNhc2VzLCB0aGVyZSBpcyBubyBkaXNwYXRjaCBMRkIsIHdlIGhhdmUgZWFjaA0KRXRo ZXJlbmNhcCB1c2luZyBhbiBMRkItcG9ydC1ncm91cCB0byBzZWxlY3QgYW1vbmdzdCBtYW55DQpF dGhlck1BQyBvdXRzLg0KDQpjaGVlcnMsDQpqYW1hbA0KDQpPbiBUaHUsIEFwciAxNCwgMjAxMSBh dCA3OjI3IEFNLCBKYW1hbCBIYWRpIFNhbGltIDxoYWRpQG1vamF0YXR1LmNvbT4gd3JvdGU6DQo+ IE9rLCBJIHRoaW5rIGkgZm9sbG93ZWQgdGhlIGdpc3Qgb2YgdGhlIGNvbnZlcnNhdGlvbiBhbmQg aSBhbQ0KPiBhZnJhaWQgSSB3aWxsIGhhdmUgdG8gcmV2aXZlIHNvbWUgb2YgdGhhdCBkaXNjdXNz aW9uLiBJIGFwb2xvZ2l6ZS4NCj4NCj4gSSBuZWVkIHRvIHRoaW5rIGEgbGl0dGxlIGFuZCBzZWUg aG93IGJlc3QgdG8gZXhwcmVzcyBteSB2aWV3Lg0KPg0KPiBjaGVlcnMsDQo+IGphbWFsDQo+DQo+ IE9uIFdlZCwgQXByIDEzLCAyMDExIGF0IDc6MjUgQU0sIENodWFuaHVhbmcgTGkNCj4gPGNodWFu aHVhbmdfbGlAbWFpbC56amdzdS5lZHUuY24+IHdyb3RlOg0KPj4gSGksSmFtYWwNCj4+DQo+PiBK b2VsIGFuZCBXZWltaW5nIGhhZCBkaXNjdXNzZWQgQWJvdXQgd2h5IHVzaW5nIGEgc2VwYXJhdGVk IGRpc3BhdGNoLg0KPj4gUGxlYXNlIHNlZSB0aGUgZW1haWw6DQo+PiBzdWJqZWN0OiBSZTogRGVm aW5pdGlvbiBvZiBFdGhlckVuY2Fwc3VsYXRvciBMRkINCj4+IHRpbWU6IDIwMTAtMTAtMTIgYW5k IDIwMTAtMTAtMTMNCj4+DQo+PiBZb3VycywNCj4+IENodWFuaHVhbmcNCj4+DQo+Pg0KPj4gPT09 PT09PSAyMDExLTA0LTEzIDE4OjQ5OjM3IEphbWFsIEhhZGkgU2FsaW0sIHdyb3RlOiA9PT09PT09 DQo+Pg0KPj4+SSB1bmRlcnN0YW5kIGl0cyB2YWx1ZSBhcyBtZXRhZGF0YSByb3V0ZXIuIEJ1dCB3 aHkgaXMgaXQNCj4+Pm5lY2Vzc2FyeSBpbiBmaWd1cmUxPw0KPj4+Q291bGQgeW91IG5vdCBoYXZl IGFuIExGQi1wb3J0LWdyb3VwIGF0IHRoZSBFdGhlckVuY2FwIHRvIHNlbGVjdA0KPj4+dGhlIGVn cmVzcyBwb3J0IEV0aGVyTUFDT3V0Pw0KPj4+DQo+Pj5GaWd1cmUgMSBpcyBub3QgY29uc2lzdGVu dCBpbiB0aGUgc2Vuc2Ugc29tZSBMRkJzIGFyZSBzaG93biBhcw0KPj4+RkUtd2lkZSBpbnN0YW5j ZXMgYW5kIGluIG90aGVycyBhcyBtZWRpYXBvcnQtc3BlY2lmaWMgKHJlZmVyIHRvIG15DQo+Pj5l bWFpbCB0byBKb2VsKS4gQW5kIHRoZW4geW91IGhhdmUgQmFzaWNNZXRhZGF0YURpc3BhdGNoIHJv dXRpbmcNCj4+PmZyb20gRkUtd2lkZSB0byBtZWRpYXBvcnQtc3BlY2lmaWNzLi4NCj4+Pg0KPj4+ Y2hlZXJzLA0KPj4+amFtYWwNCj4+Pg0KPj4+T24gV2VkLCBBcHIgMTMsIDIwMTEgYXQgNjo0NyBB TSwgQ2h1YW5odWFuZyBMaQ0KPj4+PGNodWFuaHVhbmdfbGlAbWFpbC56amdzdS5lZHUuY24+IHdy b3RlOg0KPj4+PiBCYXNpY01ldGFkYXRhRGlzcGF0Y2ggaXMgZGVmaW5lZCBhcyBhIGdlbmVyYWwg bWV0YWRhdGEgZGlzcGF0Y2ggTEZCIGluaXRpYWxseS4NCj4+Pj4gSXQgY2FuIGJlIHVzZWQgd2hl cmV2ZXIgdXNlciB3YW50cyB0byBkaXNwYXRoIHBhY2tldHMgYWNjb3JkaW5nIHNvbWUgc3BlY2lh bCBtZXRhZGF0YS4NCj4+Pj4gSXQgaGFzIG1vcmUgZmxleGliaWxpdHkuDQo+Pj4+DQo+Pj4+IFlv dXJzLA0KPj4+PiBDaHVhbmh1YW5nDQo+Pj4+DQo+Pj4+ID09PT09PT0gMjAxMS0wNC0xMyAxODoy MzoxOCBKYW1hbCBIYWRpIFNhbGltLCB3cm90ZTogPT09PT09PQ0KPj4+Pg0KPj4+Pj5Gb2xsb3dp bmcgdXAgYWZ0ZXIgbG9va2luZyBhdCB0aGUgZHJhZnQgc29tZSBtb3JlLi4NCj4+Pj4+SW4gRmln dXJlMSBpcyB0aGUgc29sZSBwdXJwb3NlIG9mIEJhc2ljTWV0YWRhdGFEaXNwYXRjaCB0byBqdXN0 IHNlbGVjdA0KPj4+Pj5hIG1lZGlhcG9ydCBwYXRoPyBJdCBkb2VzbnQgc2VlbSBzZW5zaWJsZSBn aXZlbiB3ZSBjb3VsZCB1c2UNCj4+Pj4+TEZCLXBvcnQtZ3JvdXBzIHRvIHNlbGVjdCBMRkIgKGlu c3RhbmNlcykuDQo+Pj4+Pg0KPj4+Pj5jaGVlcnMsDQo+Pj4+PmphbWFsDQo+Pj4+Pg0KPj4+Pj5P biBXZWQsIEFwciAxMywgMjAxMSBhdCA1OjMyIEFNLCBKYW1hbCBIYWRpIFNhbGltIDxoYWRpQG1v amF0YXR1LmNvbT4gd3JvdGU6DQo+Pj4+Pg0KPj4+Pj4+IFRoYXQgd2FzIG15IGluaXRpYWwgdGhp bmtpbmcgLSBidXQgbm93IHRoYXQgeW91IGJyaW5nIGl0IHVwIGFnYWluLA0KPj4+Pj4+IHlvdSBt YWRlIG1lIGxvb2sgY2xvc2VyIGF0IGZpZ3VyZTEuLi4gT3RoZXIgdGhhbiBFdGhlclBIWUNvcCwg aXMgdGhlcmUgYW55DQo+Pj4+Pj4gbmVlZCBmb3IgYW55IG90aGVyIExGQiBpbnN0YW5jZSB0byBi ZSBwZXItbWVkaWFwb3J0PyBJbmRlZWQsIHRoZSByZXZlcnNlDQo+Pj4+Pj4gY2FzZSBjYW4gYmUg YWxzbyBhcmd1ZWQgYW5kIHlvdSBoYXZlIGV2ZXJ5dGhpbmcgcGVyLW1lZGlhcG9ydC4NCj4+Pj4+ PiBCdXQgd2UgZG8gaGF2ZSBhYmlsaXR5IGZvciBncm91cGluZyBvZiBMRkItcG9ydHMgd2hpY2gg Y2FuIGJlIHVzZWQgdG8gbXV4DQo+Pj4+Pj4gdG8gZGlmZmVyZW50IGluc3RhbmNlcyBvZiB0aGUg c2FtZSBMRkIgY2xhc3MgZXRjLg0KPj4+Pj4+IEZpZ3VyZTEgc2VlbXMgdG8gaGF2ZSBoYXZlIHNv bWUgTEZCcyBGRSB3aWRlIGFuZCBzb21lIG1lZGlhcG9ydA0KPj4+Pj4+IHNwZWNpZmljICh0aGUg bWVkaWFlbmNhcCBzZWVtcyB0byBiZSBwb3J0IHNwZWNpZmljKS4NCj4+Pj4+Pg0KPj4+Pj4+IGNo ZWVycywNCj4+Pj4+PiBqYW1hbA0KPj4+Pj4+DQo+Pj4+Pi4NCj4+Pj4NCj4+DQo+DQoNCg0KDQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gZm9yY2VzIG1haWxpbmcgbGlzdA0KPiBmb3JjZXNAaWV0 Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9mb3JjZXMNCj4= From hadi@mojatatu.com Fri Apr 15 04:30:14 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 80B8CE0684 for ; Fri, 15 Apr 2011 04:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.555 X-Spam-Level: X-Spam-Status: No, score=-101.555 tagged_above=-999 required=5 tests=[AWL=-0.178, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_47=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jKl6SlKZx1Af for ; Fri, 15 Apr 2011 04:30:13 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfc.amsl.com (Postfix) with ESMTP id C8C4DE0670 for ; Fri, 15 Apr 2011 04:30:13 -0700 (PDT) Received: by vxg33 with SMTP id 33so2515252vxg.31 for ; Fri, 15 Apr 2011 04:30:13 -0700 (PDT) Received: by 10.220.166.84 with SMTP id l20mr514787vcy.248.1302867013139; Fri, 15 Apr 2011 04:30:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.181.77 with HTTP; Fri, 15 Apr 2011 04:29:52 -0700 (PDT) In-Reply-To: References: <201104131847143284482@mail.zjgsu.edu.cn> <201104131925587965227@mail.zjgsu.edu.cn> From: Jamal Hadi Salim Date: Fri, 15 Apr 2011 07:29:52 -0400 Message-ID: To: "Wang,Weiming" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: forces , Chuanhuang Li , wmwang@zjgsu.edu.cn, "Joel M. Halpern" Subject: Re: [forces] BasicMetadataDispatch WAS(Re: LFB LPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 11:30:14 -0000 Weiming, On Fri, Apr 15, 2011 at 3:25 AM, Wang,Weiming wrot= e: > Jamal, > > We have already had discussions on why we should not reply on Etherencap = LFB port groups =A0to do the port dispatch. >The key point is we may have to consider some cases where logical port dis= patch actually happens before Etherencap. That makes sense when a packet is coming from a host (CE/FE) being egressed= , no? Which that should fit in this model depending what you want to do. You may want to inject it before routing decision is made in which case decisions on how it proceeds will be made starting at LPM or you can bypass that and you have to provide the metadata etherencap expe= cts. Did i miss something? >This also actually means an Etherencap LFB we currently defined is capable= of eithere per physical port per > this instance or all physical ports one this encap LFB instance cases. We= should not predetermine this relationship. IMO, thats a different issue. a logical port on top of a physical port or another logical port (infinitum) is well understood and supported by the model. From current LFB, you need to know: i) what the next LFB (instance) - solved by LFB-ports and you also need ii) to pass some metadata the next LFB can use to select some table entry to make its decision. If you are trying to exemplify how one would model a L3 forwarding path, then I think the metadata router to avoid doing the above is an unnecessary optimization and more importantly confusing. > Pls see emails on this topic in > Sent: by Joel on Tuesday, October 12, 2010 10:41 PM > Subject: Re: Definition of EtherEncapsulator LFB > > > Sent: by weiming on Tuesday, October 12, 2010 8:20 PM > Subject: Re: Definition of EtherEncapsulator LFB > I just looked at those author discussions and i am still unsure as above. Note: I already apologized for repeating some of these discussions ;-> >BTW, figure 1 in the draft is a global one FE-wide. >But the example takes the case that only one Etherencap LFB instance for a= ll physical ports. >I think we can easierly draw an example where Etherencap LFB is instanciat= ed per physical port. >In this case, a =A0MetadataDispatch LFB should be applied after an NH LFB. >Metadata used to dispatch will usually be logical port ID. Because of this= , I think the NH LFB still >needs to have logical port ID as its metadata output. > In order for the reader to follow the text it is important to provide good context. Maybe we need more than one example. Maybe we also need a big picture view of how things fit like the diagram i posted... cheers, jamal From hadi@mojatatu.com Fri Apr 15 04:38:31 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 617E2E0678 for ; Fri, 15 Apr 2011 04:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.348 X-Spam-Level: X-Spam-Status: No, score=-102.348 tagged_above=-999 required=5 tests=[AWL=0.629, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EwZNBxgPHGX6 for ; Fri, 15 Apr 2011 04:38:30 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id 9D94AE0670 for ; Fri, 15 Apr 2011 04:38:30 -0700 (PDT) Received: by vws12 with SMTP id 12so2539658vws.31 for ; Fri, 15 Apr 2011 04:38:30 -0700 (PDT) Received: by 10.52.69.140 with SMTP id e12mr2768804vdu.187.1302867510257; Fri, 15 Apr 2011 04:38:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.181.77 with HTTP; Fri, 15 Apr 2011 04:38:09 -0700 (PDT) In-Reply-To: <4DA70A3D.1010302@joelhalpern.com> References: <201104131847143284482@mail.zjgsu.edu.cn> <201104131925587965227@mail.zjgsu.edu.cn> <4DA70A3D.1010302@joelhalpern.com> From: Jamal Hadi Salim Date: Fri, 15 Apr 2011 07:38:09 -0400 Message-ID: To: "Joel M. Halpern" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: forces , Chuanhuang Li Subject: Re: [forces] BasicMetadataDispatch WAS(Re: LFB LPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 11:38:31 -0000 On Thu, Apr 14, 2011 at 10:52 AM, Joel M. Halpern wro= te: > I find the figures the way you labelled them confusing, because the > EtherClassifier is not an L3 element. =A0In particular, for example, it w= ould > demux and hand off bridging control protocols. I struggled with that one - for that moment just wanted to put out a genera= l view of my thoughts but will revisit if get agreement from Weiming. > The other confusing thing is that you are handing the local delivery > determination to the bridging function. =A0I can live with that, but ther= e are > various things that have to be handled locally, and not handed to bridgin= g > logic. > That seemed like the easiest thing to do (an maybe a micro optimization); b= ut I have seen that model used in a few places - in those cases, the L2 table = will need to have a flag which indicates "for this (L2) table entry, you need to have L3 processing". cheers, jamal From hadi@mojatatu.com Fri Apr 15 04:45:26 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4B56BE0684 for ; Fri, 15 Apr 2011 04:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.071 X-Spam-Level: X-Spam-Status: No, score=-102.071 tagged_above=-999 required=5 tests=[AWL=0.306, 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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id smSzWtuZclQu for ; Fri, 15 Apr 2011 04:45:25 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id 6BBC6E066A for ; Fri, 15 Apr 2011 04:45:25 -0700 (PDT) Received: by vws12 with SMTP id 12so2545081vws.31 for ; Fri, 15 Apr 2011 04:45:25 -0700 (PDT) Received: by 10.52.178.196 with SMTP id da4mr2552897vdc.227.1302867925105; Fri, 15 Apr 2011 04:45:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.181.77 with HTTP; Fri, 15 Apr 2011 04:45:05 -0700 (PDT) In-Reply-To: References: From: Jamal Hadi Salim Date: Fri, 15 Apr 2011 07:45:05 -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] LFBLib v3: typos etc X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 11:45:26 -0000 On Thu, Apr 14, 2011 at 11:21 PM, Wang,Weiming wro= te: > Chuanhuang, "pakcet" typoes are in the xml. pls check to corrent it. > > Jamal, =A0I havn't found the lfb typoes. =A0Not sure if it is because of = the version difference. > I grepped v3 and couldnt find the examples of "LFB" with mixed cases. Maybe I was looking at different version. In general please make sure that you are consistent in capitalization choices in everything. I will try to bring them up immediately next time i see one. For the second one: PakcetNoARPOut and PakcetNoNbrOut is where the mispelling i found (but may not be important if we remove ARP). cheers, jamal From wmwang2001@hotmail.com Fri Apr 15 19:20:48 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4350AE0683 for ; Fri, 15 Apr 2011 19:20:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.846 X-Spam-Level: X-Spam-Status: No, score=-0.846 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5FKKWZB+gkst for ; Fri, 15 Apr 2011 19:20:47 -0700 (PDT) Received: from blu0-omc1-s36.blu0.hotmail.com (blu0-omc1-s36.blu0.hotmail.com [65.55.116.47]) by ietfc.amsl.com (Postfix) with ESMTP id 7758DE061E for ; Fri, 15 Apr 2011 19:20:47 -0700 (PDT) Received: from BLU0-SMTP76 ([65.55.116.8]) by blu0-omc1-s36.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 15 Apr 2011 19:20:47 -0700 X-Originating-IP: [125.119.206.152] X-Originating-Email: [wmwang2001@hotmail.com] Message-ID: Received: from WmwangHome ([125.119.206.152]) by BLU0-SMTP76.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 15 Apr 2011 19:20:45 -0700 From: "Wang,Weiming" To: "Jamal Hadi Salim" References: <201104131847143284482@mail.zjgsu.edu.cn> <201104131925587965227@mail.zjgsu.edu.cn> Date: Sat, 16 Apr 2011 10:20:39 +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.6090 X-OriginalArrivalTime: 16 Apr 2011 02:20:45.0917 (UTC) FILETIME=[E4BD28D0:01CBFBDC] Cc: forces , Chuanhuang Li , wmwang@zjgsu.edu.cn, "Joel M. Halpern" Subject: Re: [forces] BasicMetadataDispatch WAS(Re: LFB LPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2011 02:20:48 -0000 SmFtYWwsDQoNCj4gV2UgaGF2ZSBhbHJlYWR5IGhhZCBkaXNjdXNzaW9ucyBvbiB3aHkgd2Ugc2hv dWxkIG5vdCByZXBseSBvbiBFdGhlcmVuY2FwIExGQiBwb3J0IGdyb3VwcyB0byBkbyB0aGUgcG9y dCBkaXNwYXRjaC4NCj5UaGUga2V5IHBvaW50IGlzIHdlIG1heSBoYXZlIHRvIGNvbnNpZGVyIHNv bWUgY2FzZXMgd2hlcmUgbG9naWNhbCBwb3J0IGRpc3BhdGNoIGFjdHVhbGx5IGhhcHBlbnMgYmVm b3JlIEV0aGVyZW5jYXAuDQoNClRoYXQgbWFrZXMgc2Vuc2Ugd2hlbiBhIHBhY2tldCBpcyBjb21p bmcgZnJvbSBhIGhvc3QgKENFL0ZFKSBiZWluZyBlZ3Jlc3NlZCwgbm8/DQpXaGljaCB0aGF0IHNo b3VsZCBmaXQgaW4gdGhpcyBtb2RlbCBkZXBlbmRpbmcgd2hhdCB5b3Ugd2FudCB0byBkby4gWW91 DQptYXkgd2FudCB0byBpbmplY3QgaXQgYmVmb3JlDQpyb3V0aW5nIGRlY2lzaW9uIGlzIG1hZGUg aW4gd2hpY2ggY2FzZSBkZWNpc2lvbnMgb24gaG93IGl0IHByb2NlZWRzDQp3aWxsIGJlIG1hZGUg c3RhcnRpbmcgYXQgTFBNDQpvciB5b3UgY2FuIGJ5cGFzcyB0aGF0IGFuZCB5b3UgaGF2ZSB0byBw cm92aWRlIHRoZSBtZXRhZGF0YSBldGhlcmVuY2FwIGV4cGVjdHMuDQpEaWQgaSBtaXNzIHNvbWV0 aGluZz8NCg0KUmU6IFNvcnJ5IGZvciBteSBwcmV2aW91cyB0ZXh0IHdoZXJlICJyZXBseSIgc2hv dWxkIGJlICJyZWx5Ii4gV2hhdCBJIHRyaWVkIHRvIGV4cGxhaW4gaXMsIHRoZXJlIGFyZSB0d28g cG9zc2libGUgdXNlIGNhc2VzIGZvciBFdGhlcmVuY2FwIExGQi4gT25lIGlzIHRvIG11eCBhbGwg aW5wdXRzIGFuZCBsZXQgb25lIHN1Y2ggTEZCIHdvcmsgIGZvciBhbGwgcGh5c2ljYWwgcG9ydHMs IGp1c3QgbGlrZSB0aGUgZXhhbXBsZXMgaW4gY3VycmVudCBkcmFmdCBmaWd1cmUgMS4gQW5vdGhl ciBwb3NzaWJsZSBjYXNlIGlzLCB0aGUgRXRoZXJuZXQgZW5jYXAgZnVuY3Rpb24gaXMgaW1wbGVt ZW50ZWQgaW4gZGlzdHJpYnV0ZWQgbGluZSBjYXJkcywgd2hpY2ggbWF5IGV2ZW4gaGF2ZSB0byBi ZSBtb2RlbGVkIGFzIG9uZSBFdGhlcmVuY2FwIExGQiBwZXIgcGh5c2ljYWwgcG9ydC4gRm9yIGxh dHRlciBjYXNlcywgYWZ0ZXIgTkggTEZCIHdoZXJlIGEgb3V0cHV0IHBvcnQgSUQgaXMgYXNzaWdu ZWQsIHNob3VsZCBiZSBmb2xsb3dlZCB3aXRoIGEgZGlzcGF0Y2ggdG8gcm91dGUgcGFja2V0cyB0 byBpbmRpdmlkdWFsIG91dHB1dCBwb3J0LCBqdXN0IGxpa2UgaW4gcmVhbGl0eSBhIHN3aXRjaCBm YWJyaWMgZG9lcyBpbiBhIHJvdXRlciBhcmNoaXRlY3R1cmUuIA0KDQo+VGhpcyBhbHNvIGFjdHVh bGx5IG1lYW5zIGFuIEV0aGVyZW5jYXAgTEZCIHdlIGN1cnJlbnRseSBkZWZpbmVkIGlzIGNhcGFi bGUgb2YgZWl0aGVyZSBwZXIgcGh5c2ljYWwgcG9ydCBwZXINCj4gdGhpcyBpbnN0YW5jZSBvciBh bGwgcGh5c2ljYWwgcG9ydHMgb25lIHRoaXMgZW5jYXAgTEZCIGluc3RhbmNlIGNhc2VzLiBXZSBz aG91bGQgbm90IHByZWRldGVybWluZSB0aGlzIHJlbGF0aW9uc2hpcC4NCg0KSU1PLCB0aGF0cyBh IGRpZmZlcmVudCBpc3N1ZS4NCmEgbG9naWNhbCBwb3J0IG9uIHRvcCBvZiBhIHBoeXNpY2FsIHBv cnQgb3IgYW5vdGhlciBsb2dpY2FsIHBvcnQNCihpbmZpbml0dW0pIGlzIHdlbGwgdW5kZXJzdG9v ZCBhbmQgc3VwcG9ydGVkIGJ5DQp0aGUgbW9kZWwuIEZyb20gY3VycmVudCBMRkIsIHlvdSBuZWVk IHRvIGtub3c6DQogaSkgIHdoYXQgdGhlIG5leHQgTEZCIChpbnN0YW5jZSkgLSBzb2x2ZWQgYnkg TEZCLXBvcnRzIGFuZCB5b3UgYWxzbyBuZWVkDQppaSkgdG8gcGFzcyBzb21lIG1ldGFkYXRhIHRo ZSBuZXh0IExGQiBjYW4gdXNlIHRvIHNlbGVjdCBzb21lIHRhYmxlDQplbnRyeSB0byBtYWtlIGl0 cyBkZWNpc2lvbi4NCg0KSWYgeW91IGFyZSB0cnlpbmcgdG8gZXhlbXBsaWZ5IGhvdyBvbmUgd291 bGQgbW9kZWwgYSBMMyBmb3J3YXJkaW5nDQpwYXRoLCB0aGVuIEkgdGhpbmsgdGhlIG1ldGFkYXRh IHJvdXRlcg0KdG8gYXZvaWQgZG9pbmcgdGhlIGFib3ZlIGlzIGFuIHVubmVjZXNzYXJ5IG9wdGlt aXphdGlvbiBhbmQgbW9yZQ0KaW1wb3J0YW50bHkgY29uZnVzaW5nLg0KDQpSZTogdGhpcyBwcm9i bGVtIGlzLCBpZiB3ZSBkbyBub3QgZGVmaW5lIHRoZSBtZXRhZGF0YSByb3V0ZXIgYXMgeW91IHNh aWQsIGhvdyBjYW4gd2UgZGVhbCB3aXRoIHRoZSBzZWNvbmQgY2FzZSBJIG1lbnRpb25lZCBhYm92 ZSB3aGVyZSBhIHN3aXRjaCBmYWJyaWMgbGlrZSBmdW5jdGlvbiBpcyBhZG9wdGVkLiBNb3Jlb3Zl ciwgZXZlbiB5b3UgdHJ5IHRvIGF2b2lkIGEgc2VwYXJhdGUgbWV0YWRhdGEgcm91dGVyIExGQiwg eW91IGhhdmUgdG8gcHV0IHRoZSBmdW5jdGlvbiBvZiBkaXNwYXRjaC1ieS1tZXRhZGF0YSBpbnNp ZGUgdGhlIEV0aGVyZW5jYXAgTEZCLiBJdCBqdXN0IHNhdmVzIG5vdGhpbmcuDQoNCj4gUGxzIHNl ZSBlbWFpbHMgb24gdGhpcyB0b3BpYyBpbg0KPiBTZW50OiBieSBKb2VsIG9uIFR1ZXNkYXksIE9j dG9iZXIgMTIsIDIwMTAgMTA6NDEgUE0NCj4gU3ViamVjdDogUmU6IERlZmluaXRpb24gb2YgRXRo ZXJFbmNhcHN1bGF0b3IgTEZCDQo+DQo+DQo+IFNlbnQ6IGJ5IHdlaW1pbmcgb24gVHVlc2RheSwg T2N0b2JlciAxMiwgMjAxMCA4OjIwIFBNDQo+IFN1YmplY3Q6IFJlOiBEZWZpbml0aW9uIG9mIEV0 aGVyRW5jYXBzdWxhdG9yIExGQg0KPg0KDQpJIGp1c3QgbG9va2VkIGF0IHRob3NlIGF1dGhvciBk aXNjdXNzaW9ucyBhbmQgaSBhbSBzdGlsbCB1bnN1cmUgYXMgYWJvdmUuDQpOb3RlOiBJIGFscmVh ZHkgYXBvbG9naXplZCBmb3IgcmVwZWF0aW5nIHNvbWUgb2YgdGhlc2UgZGlzY3Vzc2lvbnMgOy0+ DQoNCj5CVFcsIGZpZ3VyZSAxIGluIHRoZSBkcmFmdCBpcyBhIGdsb2JhbCBvbmUgRkUtd2lkZS4N Cj5CdXQgdGhlIGV4YW1wbGUgdGFrZXMgdGhlIGNhc2UgdGhhdCBvbmx5IG9uZSBFdGhlcmVuY2Fw IExGQiBpbnN0YW5jZSBmb3IgYWxsIHBoeXNpY2FsIHBvcnRzLg0KPkkgdGhpbmsgd2UgY2FuIGVh c2llcmx5IGRyYXcgYW4gZXhhbXBsZSB3aGVyZSBFdGhlcmVuY2FwIExGQiBpcyBpbnN0YW5jaWF0 ZWQgcGVyIHBoeXNpY2FsIHBvcnQuDQo+SW4gdGhpcyBjYXNlLCBhIE1ldGFkYXRhRGlzcGF0Y2gg TEZCIHNob3VsZCBiZSBhcHBsaWVkIGFmdGVyIGFuIE5IIExGQi4NCj5NZXRhZGF0YSB1c2VkIHRv IGRpc3BhdGNoIHdpbGwgdXN1YWxseSBiZSBsb2dpY2FsIHBvcnQgSUQuIEJlY2F1c2Ugb2YgdGhp cywgSSB0aGluayB0aGUgTkggTEZCIHN0aWxsDQo+bmVlZHMgdG8gaGF2ZSBsb2dpY2FsIHBvcnQg SUQgYXMgaXRzIG1ldGFkYXRhIG91dHB1dC4NCj4NCg0KSW4gb3JkZXIgZm9yIHRoZSByZWFkZXIg dG8gZm9sbG93IHRoZSB0ZXh0IGl0IGlzIGltcG9ydGFudCB0byBwcm92aWRlDQpnb29kIGNvbnRl eHQuDQpSZTogdGhpcyBjYW4gYmUgZG9uZS4NCg0KTWF5YmUgd2UgbmVlZCBtb3JlIHRoYW4gb25l IGV4YW1wbGUuIE1heWJlIHdlIGFsc28gbmVlZCBhIGJpZyBwaWN0dXJlIHZpZXcNCm9mIGhvdyB0 aGluZ3MgZml0IGxpa2UgdGhlIGRpYWdyYW0gaSBwb3N0ZWQuLi4NClJlOiB3aGljaCBhbm90aGVy IGV4YW1wbGUgZG8geW91IHRoaW5rIHdlIGJldHRlciB0byBzaG93PyBJTU8sIEkgdGhpbmsgdGhl IGRpYWdyYW0geW91IHBvc3RlZCBtaWdodCBiZSB3aXRoIHR3byBxdWVzdGlvbnMsIDEpIG5vdCBG RS13aWRlLCBvbmx5IGRpcGljdHMgb25lIHBoeXNpY2FsIHBvcnQsIHNvIGl0IGlzIG5vdCBhIGJp ZyBwaWN0dXJlIHZpZXcuIDIpIHRvIHNob3cgdGhlIEwyIHByb2Nlc3NpbmcgTEZCIGV4cGxpY2l0 bHkgaW4gdGhlIGZpZ3VyZSB3aGlsZSB3ZSBhY3R1YWxseSBkb2VzIG5vdCBkZWZpbmUgdGhlIExG QiB3aWxsIHJlc3VsdCBpbiBjb25mdXNpbmcuIA0KDQp0aGFua3MsDQpXZWltaW5n From hadi@mojatatu.com Sun Apr 17 06:41:39 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 59DDBE068E for ; Sun, 17 Apr 2011 06:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.281 X-Spam-Level: X-Spam-Status: No, score=-101.281 tagged_above=-999 required=5 tests=[AWL=-0.504, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_22=0.6, J_CHICKENPOX_47=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9j4UPiBdAsnM for ; Sun, 17 Apr 2011 06:41:38 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfc.amsl.com (Postfix) with ESMTP id A407CE0769 for ; Sun, 17 Apr 2011 06:41:38 -0700 (PDT) Received: by vxg33 with SMTP id 33so3740620vxg.31 for ; Sun, 17 Apr 2011 06:41:38 -0700 (PDT) Received: by 10.52.187.42 with SMTP id fp10mr1753468vdc.270.1303047698253; Sun, 17 Apr 2011 06:41:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.185.193 with HTTP; Sun, 17 Apr 2011 06:41:17 -0700 (PDT) In-Reply-To: References: <201104131847143284482@mail.zjgsu.edu.cn> <201104131925587965227@mail.zjgsu.edu.cn> From: Jamal Hadi Salim Date: Sun, 17 Apr 2011 09:41:17 -0400 Message-ID: To: "Wang,Weiming" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: forces , Chuanhuang Li , wmwang@zjgsu.edu.cn, "Joel M. Halpern" Subject: Re: [forces] BasicMetadataDispatch WAS(Re: LFB LPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 13:41:39 -0000 Hi Weiming, On Fri, Apr 15, 2011 at 10:20 PM, Wang,Weiming wro= te: > Re: Sorry for my previous text where "reply" should be "rely". What I tri= ed to explain >is, there are two possible use cases for Etherencap LFB. One= is to mux all inputs >and let one such LFB work =A0for all physical ports,= just like the examples in current >draft figure 1. Another possible case i= s, the Ethernet encap function is implemented >in distributed line cards, w= hich may even have to be modeled as one Etherencap >LFB per physical port. = For latter cases, after NH LFB where a output port ID is >assigned, should = be followed with a dispatch to route packets to individual output >port, ju= st like in reality a switch fabric does in a router architecture. Thanks - I understand you better; and I am glad we are having this conversation, because I could never have figured out why you made that decision (me being the reader of the document)! It sounds to me like you are describing a problem that we MUST address in in the text. I dont think this issue is specific to just distributed line cards but also even within a single card, distributed LFB chips which may have intermediate "interconnects". At the minimal we need to have diagrams or text describing that those approaches work with the provided model. To simplify the discussion and build up on what you said above: lets assume the issue is specific to case of an FE making a forwarding deci= sion for a port that sits in a different FE. I now understand why the NH needs t= o point to a logical port mentioned by Joel. Such a port could be an interconnect port (assume it is an ethernet port for simplicity) to the egr= ess FE before the packet is sent out the real port. So it seems etherencap shou= ld be per-port, on the egress port; meaning the NH LFB needs to have entry LFB-port-group in addition to the logical port ID. This LFB-port-group will have the same exact entry for implementations that assume one-etherencap-per-system. Maybe the EncapOutputIndex would suffice. One-etherencap-per-system can handle easily the per-port-etherencap by having LFB-port-groups that point to per-port-ethermacout. So in both cases, i am still missing the need for a dispatch LFB. Side note: It may be important to make the rules that logical port IDs globaly unique per NE. This way i can reference a logical port id in FE1 while it may reside in FE3. Or it may be changed down the LFB stream by some interconnect technology - but we are agnostic to that at LFB level. My only worry is that because this is generic a 32-bit space may be insufficient for logical ports. Since this is a long email - and i am hoping it doesnt go into TL;DR bucket i will wait then respond in another email to the rest of your email later. Chuanhuang, this is also why i am not responding to your other email. I will catch up later with it. cheers, jamal From hadi@mojatatu.com Sun Apr 17 07:18:40 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0F5CCE06BF for ; Sun, 17 Apr 2011 07:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.265 X-Spam-Level: X-Spam-Status: No, score=-101.265 tagged_above=-999 required=5 tests=[AWL=-0.488, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_41=0.6, J_CHICKENPOX_47=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VYb5ms6VMHgD for ; Sun, 17 Apr 2011 07:18:39 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfc.amsl.com (Postfix) with ESMTP id 91953E0675 for ; Sun, 17 Apr 2011 07:18:39 -0700 (PDT) Received: by vxg33 with SMTP id 33so3752887vxg.31 for ; Sun, 17 Apr 2011 07:18:39 -0700 (PDT) Received: by 10.220.157.143 with SMTP id b15mr1090542vcx.217.1303049919111; Sun, 17 Apr 2011 07:18:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.185.193 with HTTP; Sun, 17 Apr 2011 07:18:19 -0700 (PDT) In-Reply-To: References: <201104131847143284482@mail.zjgsu.edu.cn> <201104131925587965227@mail.zjgsu.edu.cn> From: Jamal Hadi Salim Date: Sun, 17 Apr 2011 10:18:19 -0400 Message-ID: To: "Wang,Weiming" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: forces , Chuanhuang Li , wmwang@zjgsu.edu.cn, "Joel M. Halpern" Subject: Re: [forces] BasicMetadataDispatch WAS(Re: LFB LPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 14:18:40 -0000 part 2: After more coffee. On Fri, Apr 15, 2011 at 10:20 PM, Wang,Weiming wro= te: >Re: this problem is, if we do not define the metadata router as you said, = how can >we deal with the second case I mentioned above where a switch fabr= ic like function >is adopted. Moreover, even you try to avoid a separate me= tadata router LFB, you >have to put the function of dispatch-by-metadata in= side the Etherencap LFB. It just >saves nothing. > You may be right, it could be simpler to have a metadata router from a high level description point of view. It may also be optimal. I am just not sure how the model mandates it. > Re: which another example do you think we better to show? IMO, I think th= e >diagram you posted might be with two questions, 1) not FE-wide, only dip= icts one >physical port, so it is not a big picture view. 2) to show the L2= processing LFB >explicitly in the figure while we actually does not define= the LFB will result in >confusing. L2 processing is already mentioned in the draft and the example i gave indi= cates port#N where N is an arbitrary number. So it is not specific to one physical port. cheers, jamal From jmh@joelhalpern.com Sun Apr 17 08:39:13 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id CE46CE06DE for ; Sun, 17 Apr 2011 08:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.312 X-Spam-Level: X-Spam-Status: No, score=-100.312 tagged_above=-999 required=5 tests=[AWL=-2.513, BAYES_00=-2.599, J_CHICKENPOX_29=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_38=0.6, J_CHICKENPOX_41=0.6, J_CHICKENPOX_45=0.6, J_CHICKENPOX_82=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xd32ewkqSXTU for ; Sun, 17 Apr 2011 08:39:13 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes.out.tigertech.net [74.114.88.72]) by ietfc.amsl.com (Postfix) with ESMTP id 04139E06B5 for ; Sun, 17 Apr 2011 08:39:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id BE88A4300D5; Sun, 17 Apr 2011 08:39:11 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-50-206.clppva.btas.verizon.net [71.161.50.206]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id AB7AD43004E; Sun, 17 Apr 2011 08:39:10 -0700 (PDT) Message-ID: <4DAB099A.70303@joelhalpern.com> Date: Sun, 17 Apr 2011 11:39:06 -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: <201104131847143284482@mail.zjgsu.edu.cn> <201104131925587965227@mail.zjgsu.edu.cn> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: forces , Chuanhuang Li , wmwang@zjgsu.edu.cn Subject: Re: [forces] BasicMetadataDispatch WAS(Re: LFB LPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 15:39:14 -0000 We do, as you say, need to put better text in here. Weiming will not be there to remind each reader of the discussion :-) The scope of uniqueness of the port IDs is up to the CE. It assigns them. It builds the table entries. While I tend to like NE-wide uniqueness of logical port IDs, and separation of logical port IDs from physical port IDs, at most this can be a suggested behavior. After all, with a sufficiently (maybe excessively) clever CE, the system will work with duplication of IDs across FEs. Even if one has a meta-data passing interface (which is not yet part of the spec.) The general point is that one comes out of the NH LFB knowing the output. But one could easily have additional common processing after taht, before the ether-encap. (charging, filtering, other policy). As such, there has to be enough meta-data to allow later steering. Now, if one has meta-data to allow later steering, it is pretty useful to have an LFB which can do that steering. We can either define one that is specific, or define a generic one. (The generic has rather more complex information structure, but is MUCH more powerful.) One could also define a generic as if it were, for now, a virtual LFB class and then subclass it immediately to the case that we want. But I don't see much value in that. Yours, Joel On 4/17/2011 10:18 AM, Jamal Hadi Salim wrote: > part 2: After more coffee. > > On Fri, Apr 15, 2011 at 10:20 PM, Wang,Weiming wrote: > > >> Re: this problem is, if we do not define the metadata router as you said, how can>we deal with the second case I mentioned above where a switch fabric like function>is adopted. Moreover, even you try to avoid a separate metadata router LFB, you>have to put the function of dispatch-by-metadata inside the Etherencap LFB. It just>saves nothing. >> > > You may be right, it could be simpler to have a metadata router from a > high level description point of view. It may also be optimal. > I am just not sure how the model mandates it. > >> Re: which another example do you think we better to show? IMO, I think the>diagram you posted might be with two questions, 1) not FE-wide, only dipicts one>physical port, so it is not a big picture view. 2) to show the L2 processing LFB>explicitly in the figure while we actually does not define the LFB will result in>confusing. > > > L2 processing is already mentioned in the draft and the example i gave indicates > port#N where N is an arbitrary number. So it is not specific to one > physical port. > > cheers, > jamal > From hadi@mojatatu.com Sun Apr 17 10:52:30 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id AAE7AE0717 for ; Sun, 17 Apr 2011 10:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.349 X-Spam-Level: X-Spam-Status: No, score=-102.349 tagged_above=-999 required=5 tests=[AWL=0.628, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id moGZpFxnHgDT for ; Sun, 17 Apr 2011 10:52:30 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id 03C5FE06A0 for ; Sun, 17 Apr 2011 10:52:29 -0700 (PDT) Received: by vws12 with SMTP id 12so3841417vws.31 for ; Sun, 17 Apr 2011 10:52:29 -0700 (PDT) Received: by 10.220.157.143 with SMTP id b15mr1131422vcx.217.1303062749105; Sun, 17 Apr 2011 10:52:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.185.193 with HTTP; Sun, 17 Apr 2011 10:52:09 -0700 (PDT) In-Reply-To: <4DAB099A.70303@joelhalpern.com> References: <201104131847143284482@mail.zjgsu.edu.cn> <201104131925587965227@mail.zjgsu.edu.cn> <4DAB099A.70303@joelhalpern.com> From: Jamal Hadi Salim Date: Sun, 17 Apr 2011 13:52:09 -0400 Message-ID: To: "Joel M. Halpern" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: forces , Chuanhuang Li , wmwang@zjgsu.edu.cn Subject: Re: [forces] BasicMetadataDispatch WAS(Re: LFB LPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 17:52:30 -0000 On Sun, Apr 17, 2011 at 11:39 AM, Joel M. Halpern wro= te: > We do, as you say, need to put better text in here. =A0Weiming will not b= e > there to remind each reader of the discussion :-) > Yes, that would help immensely. Even pointing out where the possible "port fanout" points would be sufficient justification to describe the need for the metadata router. Figure 1 points to a fanout after EtherEncap. Weiming pointed of one after NH. I am assuming it is very very uncommon to find anything else in a router. Do we need something in those LFBs to tell the CE that there is a fanout that follows it? it does not seem sufficient for the FE to describe just th= e LFB topology. > The scope of uniqueness of the port IDs is up to the CE. =A0It assigns th= em. > =A0It builds the table entries. > While I tend to like NE-wide uniqueness of logical port IDs, and separati= on > of logical port IDs from physical port IDs, at most this can be a suggest= ed > behavior. =A0After all, with a sufficiently (maybe excessively) clever CE= , the > system will work with duplication of IDs across FEs. =A0Even if one has a > meta-data passing interface (which is not yet part of the spec.) > Ok. It really is upto the CE to mediate all that. > The general point is that one comes out of the NH LFB knowing the output. > But one could easily have additional common processing after taht, before > the ether-encap. =A0(charging, filtering, other policy). =A0As such, ther= e has > to be enough meta-data to allow later steering. And all that can be discovered (niceties of ForCES). > Now, if one has meta-data to allow later steering, it is pretty useful to > have an LFB which can do that steering. =A0We can either define one that = is > specific, or define a generic one. =A0(The generic has rather more comple= x > information structure, but is MUCH more powerful.) =A0One could also defi= ne a > generic as if it were, for now, a virtual LFB class and then subclass it > immediately to the case that we want. =A0But I don't see much value in th= at. It does seem like the current description is trying to be generic. I think i will be fine with leaving the metadata router along with a good description and insisting that figure 1 and at least the two other possibilities are merely examples. cheers, jamal From jmh@joelhalpern.com Sun Apr 17 11:58:52 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1E006E0719 for ; Sun, 17 Apr 2011 11:58:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bG9Nd6zuhTWy for ; Sun, 17 Apr 2011 11:58:51 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes.out.tigertech.net [74.114.88.72]) by ietfc.amsl.com (Postfix) with ESMTP id 7A7B8E06EC for ; Sun, 17 Apr 2011 11:58:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 913C84300D5; Sun, 17 Apr 2011 11:58:50 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-50-206.clppva.btas.verizon.net [71.161.50.206]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id 8F59E4300D1; Sun, 17 Apr 2011 11:58:49 -0700 (PDT) Message-ID: <4DAB3865.7090600@joelhalpern.com> Date: Sun, 17 Apr 2011 14:58:45 -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: <201104131847143284482@mail.zjgsu.edu.cn> <201104131925587965227@mail.zjgsu.edu.cn> <4DAB099A.70303@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: forces , Chuanhuang Li , wmwang@zjgsu.edu.cn Subject: Re: [forces] BasicMetadataDispatch WAS(Re: LFB LPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 18:58:52 -0000 Clarifying one point below: On 4/17/2011 1:52 PM, Jamal Hadi Salim wrote: ... > Even pointing out where the possible "port fanout" points would be > sufficient justification to describe the need for the metadata router. > Figure 1 points to a fanout after EtherEncap. > Weiming pointed of one after NH. I am assuming it is very very uncommon > to find anything else in a router. > Do we need something in those LFBs to tell the CE that there is a fanout > that follows it? it does not seem sufficient for the FE to describe just the > LFB topology. Remember that the ForCES LFB includes the information as to what LFB pair sequences (A followed by B) are allowed. So if the LFB requires that the etherencap or other media encap follow the NH LFB, then it can specify that and the CE will know it. Yours, Joel From hadi@mojatatu.com Sun Apr 17 17:15:02 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B436BE0743 for ; Sun, 17 Apr 2011 17:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.868 X-Spam-Level: X-Spam-Status: No, score=-101.868 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U7HSbriawrlY for ; Sun, 17 Apr 2011 17:15:01 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfc.amsl.com (Postfix) with ESMTP id BA3B8E065F for ; Sun, 17 Apr 2011 17:15:01 -0700 (PDT) Received: by vxg33 with SMTP id 33so3954957vxg.31 for ; Sun, 17 Apr 2011 17:15:01 -0700 (PDT) Received: by 10.220.181.66 with SMTP id bx2mr1202731vcb.147.1303085701144; Sun, 17 Apr 2011 17:15:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.185.193 with HTTP; Sun, 17 Apr 2011 17:14:41 -0700 (PDT) In-Reply-To: <4DAB3865.7090600@joelhalpern.com> References: <201104131847143284482@mail.zjgsu.edu.cn> <201104131925587965227@mail.zjgsu.edu.cn> <4DAB099A.70303@joelhalpern.com> <4DAB3865.7090600@joelhalpern.com> From: Jamal Hadi Salim Date: Sun, 17 Apr 2011 20:14:41 -0400 Message-ID: To: "Joel M. Halpern" Content-Type: multipart/mixed; boundary=90e6ba53a91254216e04a12648ea Cc: forces , Chuanhuang Li , wmwang@zjgsu.edu.cn Subject: Re: [forces] BasicMetadataDispatch WAS(Re: LFB LPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 00:15:03 -0000 --90e6ba53a91254216e04a12648ea Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sun, Apr 17, 2011 at 2:58 PM, Joel M. Halpern wrot= e: > Remember that the ForCES LFB includes the information as to what LFB pair > sequences (A followed by B) are allowed. =A0So if the LFB requires that t= he > etherencap or other media encap follow the NH LFB, then it can specify th= at > and the CE will know it. > Makes sense - but something is still obscuring the view in my mind especially after i tried to put together the attached slide to clarify my understanding. Let me know if this is the intent. If it is, could someone elucidate how one would go about mapping as a NH port something that fits "port x on FE y"? cheers, jamal --90e6ba53a91254216e04a12648ea Content-Type: application/pdf; name="IPpossible-fanout.pdf" Content-Disposition: attachment; filename="IPpossible-fanout.pdf" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gmmnbe050 JVBERi0xLjQKJcOkw7zDtsOfCjIgMCBvYmoKPDwvTGVuZ3RoIDMgMCBSL0ZpbHRlci9GbGF0ZURl Y29kZT4+CnN0cmVhbQp4nL1YTY8bNwy9+1fMOUBcUdQnsFhgvR8FckuzQA9Bb21aBEmB5pK/Xz5S mtGMnY29mxaLtUcjiSIfyUfKbk/T190/k5teuz1PufK+TLFGef7yx/Trq+nvHU34+/LnzmFi+rzD oqzPnyZ7lr1eBm55sNm/dh9eQfieHNV09C0yD487riIhYOPj79NPD3JYmB4/XDm6fvy4u3/cvT1D QtzHp0U42VKSz8FMIS/DieVoD4PiPBCLMAhEOqB0PGoLVzKaqXKK/P3yswL6Vf7fyHEf/5PT3p2B C7m8rxOnIp8KjJ+oCDDvgUy8cv76t8c3DR8R6/aJq6f5W4R40cHPmnvK+zTrYKOuLZMfdLdR132U 8jRS/81552DlAwKZ8xqpK8cuuOiSy2dHo5dzRZdY5HODOgP14qq7cYcV9i6XIGLEVUn8AEGBAvQJ wIFTljTFs1iqzzIrzyF5ydPx2dYsez/tnkL7x51xDsIsVCFeqXQcjQLy9WuBJl6nK8V6xub7QlWN TPK5dtytu3P3ZzstOGQAR5IQW8t5ICfazTyy9y1H5DNCiu+5EpObIzdKPIY5Am3UY1XsG+LYRj1y FxlP58mPP+scD0bvTrPJ7D+X4MFM5DwN7MLIBc5R9U0BSujg0/SuWSgH5DAu8ojGXPeIuzYQzMGY y7ItRpRGEd6V0wd5KqtlaTiqj+ysceX2MCbSyCtInogChOfVQSw8tCzx4OKCDJIMs1FGtUW+9XXb Q0KsKthUjY6Rf8cWReLVMmdUphb1kVk0rtwelsT2ungg2r6jw1Jy47JQkDjdU21kh40rt4d5SqJM VZaH9VHZHQd5ghejfJLOBpGMqM5tlmVddFWQwCxhrTNUMYsTQ4Xb4FpEd6i0N8cgIoTLSrG9Yq7k RqG+10GPkHPbix4o5KR2YTagx8jw22cdCUMK7cQ2C24LyXbibUjUZhxOiXmP1okqsicItLZPxlMI WS2VPMOJ0sZQm4vIZIaWn3UkJ3J3BwnxyYmMIMQsIimwa7bIeAo+qSVUkf2BakOBqlNGT4oCFWRJ UDx1tmRtx6LtLZJBiqbNQQdWvTCn1FtDm2P4ujqzs2iYldptkbgXSbJfbZERZoNGyRBaVBzCRZdk BFIx+CkjdYo9tzVndpeUEMaRw6ZAvL8iIiYpYxSlKlOirORFBUxGKNEFQyYHSlN+k6Ptm+eFUsex yGUX6KatuZUSFtwNYUrE4LEIJ46SOk/aYbfuBlLubD/pXJIHR0G+q3xfUBGbwRQ2lUwMvjdTH2YN KNOdnMNm6jjA+bOpUFTiOKkRskJUKquKrXoWdzBgokkwqIJsJTs3y19xyXsbBlmx9EAzraYkjjdm AC/WgRlkPPMCaxlZeIGT3lwaL7C0UQsrcNIMaKzAEVy1sAI6tTSzAkdkzcIKoPY6swJGaWAFjkE5 w1gBozCwAkdWJrCdyNTOChyVpxorcECeLKzAyqKdFzgkSJl5gYPq0HgBIx54gYPq0HhBRgMrcFCW arzAgbRT6LzAQZmq8QJrzV54gRl3ic4LzEl7uc4MzNCiM4OMZl5gDsoZxgvM8NLCC8xWFY0XMMqn eIFZu7NsIrKSh7mAfVWeMG5Y1p3LDggtnyBLc4WnIppddvv0ID6fQGmrzlES6GwR5aQI6azuOvOA PoRKlG7kYchOqo13pOlCXumM1wsekjK6G88DtRnX2PaM9eyDZa1wnr05YjZbrVl7EJGNGvXRzvWR 6IKmHanrQ+r39eegrp26D0jxI8iKwHUvcOaZk+RKAZPEElfBcI3jxGQUAGXaZnUAxRlccXMrkffb i4rxeL/RJfVTp/UGNM3lQF80AYsTQKrNqZddfQwBn56PYSoqwXc/zBh6hE0adT+3lOG9VoOwLRGF zFAfLNSs4qiDLMYoakSZA3KL9zS/WQuTMhIa/FrDDUq9rHfXsPkFw8P5qBomLvZLznNwVTrzbosq krlHWbsqDZnlAMXYa1idtRDRPG2AwBe+HnciPEvdGI8KDMyGOrxkucKlDNGy2YJf1j7hMDuj66l+ 8zfdFsut+SoYTemZn3zUZRfQhQY6es/8wlAXXU/eXe0HniGXG2ytAdNQXjtsQQaeU+I8iUxjzNZS tky/PcHXFuRNrjw+WCh0ih1II6n3en9muhY6DHzSs4Ipd+a/uTAB8NvjC4hFE0A0Peq5/UHUq/bb jL9twByMM4JTYNwdzJtn/R3dw0RtjvVny/b+XnPCHQS5aLiXVr/8g9WoEZQGU1lT16aa9nI4ePVU OTwfS8MhxJe0FxIlKoSOmgNGeAbcHlxdV+WFU2VSu/qk+Z01mjXE5tBAnCesuQ5VYGaFmK5Ja5dr 1yNXrEkosxdazddl/t7IaeQsUa2aWw7C1Q8X3F/QkpGPvbA/uyUjTx3357ZkxyIubMmO+wVjx6Vf OGrWwCu83NA0/8ELQ5fWmPipLu3CZowcbvYva8bkxTcaiYU3kco+Xb+Wz7n2w/Z+va79+lmW5mzo K05dwJMFaCNxw7wRuv0EHLeXeGvRFNdtb4aXF0JX4gtxk6JE34Ht/2rDBleM3Zi0WmnEz532xLpG WhsRjHNUnSUnlj7lthH72k2XkYX+6vtNH7yd/gWqvvPFCmVuZHN0cmVhbQplbmRvYmoKCjMgMCBv YmoKMTk1NwplbmRvYmoKCjUgMCBvYmoKPDwvTGVuZ3RoIDYgMCBSL0ZpbHRlci9GbGF0ZURlY29k ZS9MZW5ndGgxIDI0MzI+PgpzdHJlYW0KeJztVd1vFFUUP3dmvwq03ZZKm6zCHQYQ2N1uWxFtArKI bFMKUtsCO7iJDMvd3aE7s8t+ENoES/0KrtGExJgIKi1g9EVzV030gZigEl+s8St90Bg18UEfSNTE GGNKPTN7uzRA4j/g7O69v3PO7/zOubNz55YKZQbL4BTIEE2aer6NEMDrMwDSmjxeolXvATTJjzg8 kMqnzcc/vMIAJIo+ns6OpZ5s/+cnAPkLjL+XYfqRZvXSBgDXU2hvzqDjibkDXrQvo70mY5ZOHILE ErRtPV82l9Q3wkGErl9w8Jj6ibxfWoENuH5Dm1q6yRrefPtzALcffWo+Vyy1wdF5gIZNdjxfYPlM 8NOX0R5BO2g3Ck77uCIgHsf+/3oRzsCz8Bb0wwXQIAKbIAQ9cAgeARUeggdBgStwFb6Ej+ESPAMv wSScgyng8AZEAacQh+UDfONgnO86rnFQt3VwTzC+VXN8JzX6DSfLOzvCnITot3xZMMyl0MBQfKeq KWEuh4wOyqODcYVHtTB3hexURVXG498HZrQA8uJzgWtaQFW4OxjnseOaE9A01HOHGhMHw9wTqq4m p7E6PZ1IBDigjDdUXeO4onWXL9TaQnsjYd4QoiftIp+gDOXy2n6Vcte6XRwG4xVW0akN7g8oihao ONZQzbILLql15w/4FVRcGqJfOctZFqIR7g0m4pT2qTH9KI3TI4drEjav0a6MpWmF9lViulqhFdUp p9riPIpMXJ/t4FFmG5jT5FTaOtuhKAE6W8HbgEn92M0+0Zvi0JpDKp0VxVUaHxgOKJxo8QouqF+t qLTSX1F1O6GWYk9hkPD/A3nSk8Id7YWN8A4+AUHumuHeCCczhPsiHGZt2+WvukmQyzPVBhKEru57 WpSWtUqLMinD3IQE18GT+vvspDsF9i76AffghGsKGmGtUPTOLMyEN0W4a5YvncFvtdkRU+jd6/z3 bVZo+wq/1yOHr/9+fmrqPGkmjRcvXLg4PSWtnJqenp77eXoaoLZLyb0fnXm08tdjzVv+hFU+58G9 +sfFXxc/yO4Jj92ND9dYuzDPu39uYhHl5v0uuQAmPQm7f6i9amyGBE1CQ3LeGH7bLc2LnNXktbrO yromgSVoEZHlhfUCy+iPCOxC3CuwG99BOwT2oH9vDePQgbuwhgk0wDGBJWiBcYFl7Oi52l1x+OcE tvnvCizBKrgssAyt8F1tZTgocE1g5JMmgSVoJ+0Cy9BCOh0s43AH2SYwAR8ZERj7IQmBZVhOTAe7 cLiTnBLY1n9FYAlayesCy8h5H+8McTWgvYV8LTCBNqlZYPwPJFVgGf3dArsQ7xTYDR2SJrAH/cfW JzfQnq6uXjpctugeI1nIFceKJWYWab+V7NybZ9bwmHk4lx1i6XJWL9xw3ED7WaFo5Cza3dnTfcO7 PZulI2P5XLqg5zNGksaYXioXWHG3ka4BQWD1yI6caaJMnRDLWckSChdpqa5zrLxIYSRXLrEiTf0X j+4rllk265RkC6SUUUxmGK75bDprJDOjzCgxayHFcpjby8VxhjGrbKWLegHjD+cKpo6ROi9Wtsax tEFHDKGKortZLTpSLpUYRfoCayFA88arFJdbtoxbW6KjzDJZYfTmbpDE6qE+ZjJmIV3P51nWODq6 qCfcSEnYABSPpC789CIahjJYOO8BA2MFyEERxvBXAgYmzhSPMgsjnbip8uizMGMMI4eRmYUh9KRR IQs65t6OcTvffvQUUNtAy67djeo9ON6Oi0+kc82noe2W0xavD8j805w8DwPcNxivEvKCVo3ZJwv3 46HZNoTglHYXngCJuAb/AjIw9mcKZW5kc3RyZWFtCmVuZG9iagoKNiAwIG9iagoxMzY0CmVuZG9i agoKNyAwIG9iago8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL0RBQUFBQStPcGVuU3lt Ym9sCi9GbGFncyA0Ci9Gb250QkJveFstMTc5IC0zMTIgMTA4MiA5MTZdL0l0YWxpY0FuZ2xlIDAK L0FzY2VudCA3OTkKL0Rlc2NlbnQgLTIwMAovQ2FwSGVpZ2h0IDkxNgovU3RlbVYgODAKL0ZvbnRG aWxlMiA1IDAgUj4+CmVuZG9iagoKOCAwIG9iago8PC9MZW5ndGggMjIyL0ZpbHRlci9GbGF0ZURl Y29kZT4+CnN0cmVhbQp4nF2QQWuEMBCF7/kVc9w9LFGhNxGKZcFDu6W2PyAmow3USRjjwX/fMWtb 6CGBl/e+5E102z115JN+5WB7TDB6coxLWNkiDDh5UmUFztt0qLzb2USlhe23JeHc0RjqWuk38ZbE G5weXRjwrPSNHbKnCU4fbS+6X2P8whkpQaGaBhyOcs+ziS9mRp2pS+fE9mm7CPIXeN8iQpV1ea9i g8MlGotsaEJVF0UD9fXaKCT3zzuIYbSfhiVZSrJ6aO/Z43Sn9rF+2oBdmaVJnj1X2B/3hL/fE0Pc qby+AYr0baMKZW5kc3RyZWFtCmVuZG9iagoKOSAwIG9iago8PC9UeXBlL0ZvbnQvU3VidHlwZS9U cnVlVHlwZS9CYXNlRm9udC9EQUFBQUErT3BlblN5bWJvbAovRmlyc3RDaGFyIDAKL0xhc3RDaGFy IDEKL1dpZHRoc1s1MDAgNzk0IF0KL0ZvbnREZXNjcmlwdG9yIDcgMCBSCi9Ub1VuaWNvZGUgOCAw IFIKPj4KZW5kb2JqCgoxMCAwIG9iago8PC9MZW5ndGggMTEgMCBSL0ZpbHRlci9GbGF0ZURlY29k ZS9MZW5ndGgxIDIxMjYwPj4Kc3RyZWFtCnic3Xx9fFPHsejO7jmSjmRZR7L8bVmS5W8JyVjYYBvZ B7CFHEIQYINtYmyDbTABbGwDMbTBJISAIYEQSkJICm1pbsgXghACTVN8W27StGlD07T35ab34dub 5t20oXB7aV4TsP1mj2Q+kjS/997v/fVk65zd2dnZ2dnZ2Zndtft713eQODJIGFGWr2nraSz3Oggh bxMCluUb+h2Xg//pxPQIIdTa2bNiTb7/gz8Twq4SohVXrB7oDPYfXUmI/johFU+s7Ghr//Rvx9yE BPcjjdKVCBgcu1+LeaRHsleu6b93QeLcH2D+CubfWN29vC2vs6SdkNlnMN+5pu3enmmaGYyQEOfB sbZtTccDJ/fVYV7B9n7V093Xf4AUjhMStvLynt6OntKlP63E/BTk7zcIA/zhnzhManieMkHUaHWS 3hBnjDfJZkuCNTEpOSU1LT3Dlml3OLNc2Tm5efkFhW7PJK+vaDL5/+wjvi2+Tb4pbiWJZEB93vYR yomVbCRk/BOeu/kcW/z/lgtd9HWKvE6OkyO3Fe0g9+Hzhdtg58hPyPNq6hB5+GvIniXPxVL7yUHy 0N/FW0UeQDpHsf2bn1aEDpAnsOUz5B9QUbLAj63eEyv9gLz11aTg3+Atso88i5j7yKv4PISat5n+ heyjC8ha+s9sK7mf7MQ+HoYusgfxW8lRWEKWIjT6WUo6SPcXiA6RveT7ZBPOwhsfcev4fxHj9X9A zncinQOki6y7pcaz8Bl/MTvy/hJ5RYVtnSjUhtgqeprS0ccw8yhZgd82eB/5fJjNINWiWalpbKiv W7hgfnjeXXPvnHNHbWh2sKZ61swZSlVlYHpFedm0qaUlk4t83kme/LzcnGxXltOeYjXLpnijQS/p tBpRYBSIp8YVbHVEclsjQq4rFJrE8642BLTdAmiNOBAUvB0n4mhV0Ry3YyqI2fkFTCWKqdzABNkx nUyf5HHUuByRX1S7HGegaX4Dph+udjU6IpfU9Fw1LeSqGSNmnE6s4ahJWVntiECroyYS3LByqKa1 GumdMOhnuWZ16Cd5yAm9AZMGTEXyXT0nIL8S1ATNryk/QYnOyJuNsJyatvZIeH5DTXW609k4yVMb iXdVq0VklkoyopkV0aokHV2cdbLLccIzPLT7jEyWtbrj2l3tbXc3RFgb1h1iNUNDD0XM7kiBqzpS sOnDFOx5R8Tjqq6JuDnVOQtutDPnZpMQEXNkl2PorwS747r0ye2QthhEkyP/lfBkEMU7NBR0OYJD rUNtZ8YHl7kcsmvoRFzcUE8NSpiEG7DWmfEf7EqPBHc3RuTWlVAe62xwwZxIwvwlDRGaE3SsbEMI /la5nNPSnebGCZzw3ysmKAgUB8rU6eQd33VGIcswExmc3xDNO8iy9JNE8bkbI7SVlwxPlCTW85LB iZIb1VtdOJpzFjYMRYSc2nZXDcp4V1tkcBnq0yo+FC45Ev9putM1ZDE7ynyNKq4Duapt73JExFwU C9a6tQJqCq8yJKuZ+E+jr0vp2ECu2eIocyEZTqfGVdMa+92wMgUJOCZ5IiF3dOjrGiJKNSaUttgY 1Zwo8mGNtlYcoq5qdfgiPldPxOqaeWM8OVs1XQsb1CqxahHrrAhpXR6rFfHVVPOWHTVDrdVRFjgt 1/yGs8Q/PnJiiiP9ZT+ZQhqrOXLSLNSr3JqhhvbOiL01vR1nWqejId0ZURpxgBtdDR2NXNFQQgUj 2JxTbTFCZ9U1zFnomjO/qWFajJFoAScn5NR8gYyrIT1KBlUuosvRORpoOmtERBkBjiAmXDOn4zOi zdHhV0aBq1CuqjOnOxognUxgIxuRAkdNR3UMj+dvIypydZoVmqCm4VmkMyuU7mx0Rj+TPBSLHbGG sYaOCzU0UcRy0BIgjCIZFcRlmcJ13tHg6nA1ulY6Ikq4gfeNi0eVckwYqsxjY1V3W+4WYaGYiBOL JzJcmJGgO/1W4UZmq/kb2dAXimsnih1DOtechUOcuCtGkCDntRHCVViZZk5XZz+fz65gG05inNHq fB46oSh8Lq/k03bIVds+5FrYMF3FRgvyzfRNvC0LmQNz6mZO8qAxm3nCBTvmn1Bgx8KmhrMyulM7 6hpOUqCzWmc2nsjGsoazDkIUFUo5lAN5xsEznNICzOhU/PSzCiGDaqmgAtT88jNAVJhuAgZk+Rka hckTMIowIQpTVBj/4CilrEQZo/2ucbTz8flG48qh1kau4yQJJYK/EAFXJUrHVXkCqCYuond1zIwY XDM5vIrDq6JwDYdrUTMgCSZ5Ng3JNa6/pkziCyUl1fhoF+vR+9US7wkgvukntYLuUvEJjfi76ScZ xSQ5wThY5OCTWo10ffpJ4HC/2WnOcZqd1dQxlg1PjK0U6z9/vlr4BXcS0D8gogP9rQRy/izRj48o eXHuUKk+qKfEgakCUkZqCTPINmfI4LBkhA4YnjHQAgPAmfErLyMQ3yNKCRY8Cc+hD5sLkHA3qZbr 5P0yG5GBErlIVuQeeVi+IGtkJRGUxOHEC4kjiULimfFhRY43h/Tau4lO1ik6ptWBCrS5Q2aQmEHB hIHoLKTK73fzL/iWNl8qdjev8zW3NK/zX5pcRDDhdjfjF5rdzW4nJCVnQqLZZfZDbp4XSsx+s1A+ Gk8ZZc/9d/o5Y1R4QYhMLipY4rreIG69Fpo8uXD5JPbU51vIbfIwkBWKzdCk6PaQw+gKXiQCMQ4q RlCMw8YLxhGjYOSc5iD7WtZEBFlQBKYVaEtYCxHtiJaatKDTaiWRCQTZL67ylyHrzesu3ehBmvy7 5uI07AGODGcXn8hq26jm3Dn6+Tn68GifuHX0BVqnMqbyJYypfM19Rcu0jOjV9rWGkF5vFKUmQmSi EKYlDiPoWraIIIqS0AJMauHtX6q6ZCnzYevNavNmv89tKcOlYnIRtpvojH2fFSZd38eKr/+SPS5u fWps+pNjiU/xtu3jV2ih6CFJZLOyOD8euuIH4nfGs3wjdBkHjDuNbJcAgkMyhlYL3xCeQvkKmIsL dSdtSaJJccYkJgcl3R4RiCijbBVR0IqDKWDShOOq9KCXTAlhlsR5/EWz/1KxyuI6v/9ScrGvGcfX 3Qw4vOua1+XEgyurxOwq8U/1J/oTXWZrkr+4dCotLKif9t++ua3k3p/+1F+VNtmmMxj/St994C9/ eWC0/q4qnSY6ro+gD/pnjDCcZM1ZokPRZaPoDEElHAeH48bjaJxrkLiGXRdcIy5h2AUmFwy6wMVl 7EhIDmWkBIdTgaTKqUWpI6lXUkVdahpJNSQSS1iUkXUc3yo+suvUoV3Xywd3HR9cN1Qyf3Em5Ro5 xUtdWfFq0m+2xlMtBDKDde2VKx+ca3vFXNQQVFbU5p86haoKbOvUucXJ0zp214366Es1K2tc3rp7 54zeL749dp9z5rQ8rWoTFo9/IqQId5EMkkPuUbxNrlUu2pS5KpPWsw60CLWSlD5bsdtgrw1seYM5 ZLbdDOaivOG8C3ksj3ctIdMV0ulEEs7JER3hJFkMxydNKMslc5kP3DjRLhXHelPsww41k+ZmsGZS LvrkeObKouYplZR30QY433gHtWB11faG1z+c+m1zoPPg6ivX7twWad/xarfvB6a9D01aXlcuwP+s 37OibGlo0qQltT7IhLQnfr2touHQu5tShp5/2nbHlmXqmO3ATu7A/tlJpZIvJxYl0sREZ5w9OMxj Z5kUkRFyhYg6kpqfkBRKjbPIWhPGjVVVVf5fuGOjgZrezJUcZZ/nz2SJfj4cScmJUU4TzY8ApWi4 GAMhwV0eLkvKN1iKMisXT01jlVmzZ5YnJ1dUllkrl1TYtOz7ojht+c75o2/HeGN/Rt5yuD5loQ3k +pSD+kTgMBnHwckbJKqkR/KE4Tww5cFgHuRN6FNqXHDYCMQoG4vQllwxijpjqiZslxNMRt6D4ipU qa/WJ+etanRbr7iSsbLkKfVVqh5FO8btXlrlglXBpvvr8uhL81bNSJ9U/835ow+zhVlzZhVpRU9Z hdV3Z4nNc/ej7aO+6FxBvWI/w77lkfXK/AEZBpJheQ4sZ+AI2u264BEJJKkAtSkBElzhNLtji2OP 46JDcDjSZIeuRzeou6AbQa1Cm96qZocRoEU9Q+2yF0AzahiOyroqfMhoD5svmf3f9K1LQSDXr+Yv 6JeXlkypFHj3krXRUYOEdKVrbutW02lp+or9bVtOdhdnz2hY0Vu+5JEVivFsfG/X3BVKOs1qfmpd 5crVcbO+sbRs0eO/uHfNP3yz3p9cvHhDdXzTKv+Kp8iNOdSHfS0mM8h3lOKBwM4AHYjbGUdpPho0 vZgmUneKZA6JGYkZNCcnM6h4pe5pW6btmcamzRq0zlZXMWtiRigxsWq2nQErmjU8ix6ZBbPUscYJ 5pyfn1Q2X5LS/C1W8Fn3WKnVagqnyV5/mCSptkMVh5nPuapLoC5uCHFfUleIYj7vUCy4tuHME7Ny URq0CkpiWqDNUxU6MWYME7mNRKVwxbO84koaAG08S7Qmwbe/d3T+A88u/q+M8sUVU+oqczU/1E9b cWjt278srDBlxmfNyvXXelOYxlZz93rXoq31hf80c2NTSYv1hQP37LwrkwoVs5aWp5vyZvnNyj13 uV87MeYNzxdYj06XPnV+6ZS6CsdDVcv6SxoFMBc31Ta0crluG1ss2IS5JJeUk/2K3DVtYBrtKhwo pNuzD2TTbO41JGj1oVp7o53Wahu1dDs7gLrK4VUIJ7OVIzhfpg9OzjAFiSyjF3FFFnRyZDpUTYee 6XunU/t0GJ8Ow9NHptMMTzhLTjKZ0nWlYTEqU3UGNfO506sueaoRU2cQKphbVbJ4lGBungvnz5en knZilqmqWEkFW37zwZ7+l7wi4EedXC+h1WBCqrKgo6rnYHP+6ykVy+6YvmqeN7d2dXDO8ooUmrX5 woH6hnbqKKqwjTWKmrxQRaHEsv3laVNqfYnhR3+xtf2p1dOyWo891Hd4mbt87eHYOq+huM57qEeJ e6IAHrdDnGxJCcVxf8toDqHbcUVJRwCuvmg+zKFChzMHH+iBFTpQTzNRgi8jRH0jkL+VcSwwxmVn p3vuLszGEIy+R2AXOUSoQEBHvLu80O+FCi/83AunvGDwwjvPe2GKFxxesHqBeOGqFy544bwXIhx1 m/eol7V6oc4Lioone0HwwuNXePXz3g+97AhH2++lYS9Ue6GIF2d7KVIZ4SjveeleL2zzQg+vXe1t 97JoS9Fmog2c9wqtvLjOS6PkV3CKUfpiOEqx2sus3iiFbV5O96pXx2te9bJdHIPX7vcKU5WFH6qd 4zWiVETsJEenr3mBV6ZzOAM46Ne8cDTah0EvUMUb9vZ4WRUXgsNLM9PvJhlKBtVmaBKj7qsFZZ9o Y3Oy0Zhnswx0tZL9zdxTRf9T1TvUtJZmrofruCr29i7lmdi7eaJgorD3loIbhUujCfl3aqIY1+aA z+9HRY5+mvm3GZeF0qmlUzXaeNCCC7wsLzfvpiecyZIr2VTwm8VFGCGxeJPRbhrbv31sj8ZoMmnN 6KZT+tw12Ki1WkyMyYlWHfT8lb3gX+XxF/mL3W151xU2bMqf5EsuKZs21bci73qduPW6z1o1s0KW p8+stLJfRf1nim4yEReg/mqJFSzKLzvpBrqdss6EDQnbE1gXDMBOYF3WAetOK+vTPKChHRr4hrhb pKtE2ESGCC0jjaSLsPXsQUZL2SLWyViTACEB6rUwWwsJlIGVJGpyNCUaptHAR5pPNTRNLBTLRSaJ 8LH4mUg1otEopJFCtDxMIvAx+Qz5krUObZGWObSg1SYlshxWwpiGwUfsU7Q6x4VzAhXCSZEkWpTU mrQ3aTjpSpLoSwKgLdaEhA041W468s1lPn/Utvia/Tgy3MVYxxPRgcGEmi7D3+hyduvHyZzMBX6J j1A8uvFOYc93Ru/77hu06n1aOvqSbEsyAY1PtplOURM8NdYubv18i0DzF8yaJIre6gX5Y5PRRqwc /0QcEA/g+vyiMo+74nS98UEj3ZyzK4euyoVvZO/OpquyYVUGF1oTg0LbKhvdngyFyauSqahL1FGR JlIqLgmntabR42nn0qgjDUxpkJYlc60u1BpDslzgKIB56AO7SItdICbZRItMiqnHNGgaNl0waUwm fUtiwsRazp/QzOMKTPA4J9Z17i3eeMMtBjW6uGfn4upuKc32Fwu4ujOWcu/Zbyo1W19bv+ChNYuc T+X2PH5uw/Nj4y8uWnIcyNF/A+/sV6zVnTuFz8P7L2zZ8usn6tx33TPjrnk72svW/ATiDn8f9K91 RF6cXrwkWIhj3oZy+meUUwJKarVyx5IcSMsBKQcWOCHRCVon1KVDYjosSYbUZOg0w8o4IEsUkxWs BYOOgsECmrnkuP6cnjr0YNLb9VSf2mISXC1iguojA+/opWZcV1TP7NZRBivVCLf1LsnyxRVF/OeW U2PXv//S2OcvNdx9EsRjz4J44u6fzNjyw833/WhL1Ywtr2/edm5zBX3z+2N/GV55s3udPxz79Htb LuwPR0VwsH7RQbTm5EH02f4klKM/OqDUHGCQ5ix0ljtZanxQ8Rn2GOg5A+wxHDaMG5ghbxCCF7Mv Z1OSLWcXZV/JFnTZkWhUEMm7kkfH86An5qsaua+KjmlSQmIcMU04pjwe61W9U9Uv7U275OeBeDOY Y33jUTcmk11eVuKKOXFmKP863xSD9AUT3intu/7iF73TvR30V9y+8Dj4j2hf4kkyeqcLj1F4LBkO yc/LVM/SWCFjYlxiXE4cI02KKXVQSQX8tWqbYhsMOk2L3eqzzrO2WLdYRZP1Heu4lWmtCq6PVqs2 oUViWpzkavzjXqpG69yE81g9Td1raJ5wHHjI7lT9hFxMO4tLhT8GBk4PjC07R+d/8wffqBw+enTs QXjg+4fY+3cfXl89+oG4NdD9dNv2XaPv7VN97EloJwuwHzq6ULFmaiEODVNKnClkFoGJIDPxzPh/ KOMIEAX0eHXx2i7dMR3V6JJ0pbqgTojXaaAply6iByjbQD+itIzWUqqhINOD+mP6t/RskR4kfZme puob9Tv1n+kFjR5+9pkePuLwVP1ZxBHe0EOjfgDxWakeChD7rP5jvWDQw0FEfEP/Wz09qYejejig h/v10K+HRfpOPZ2ph2z9FD216EHQw1WV5Hn9e3r6jP60nu7TwzY9bNDDMj3U6UHdSsrWQ5KK/Bc9 wAX9iJ6e18MRfURP9+uhRw/telD0YNVzsozooetD/VU9vaBXTmPrp/Tn9WxQv1dPkYGwvlVPq/Xg 4OSseoqtj8Raj/D22vX9+v36o3qxSK+o7RJeisT2Ritk66v1dYizTa8tG+GcHsWqrIcX8sY5AVFt fFgPp/QQq8ULtunF9/Qf6ulrqkSwBi3ivJj0Pj0lrILNYZvRHwSdwICrkN9ShuYQoqv/F5b/L6z4 tyz5LTf9gdswokhRSDThUymNlv0S38VuSJHnflSMPkHLUtW7BVRPvsr4mfSj0d+/Cy/C8+/S0OgZ GmJlo230cHStXoSxjw1jn3iSRfqVigHHTgftz9iWQTckbU+iA5adFnog7pk4KsRZ46hBSpeoQUwX qUCtlGrRQ99rAlP2YFE2ZKtBEMY6F7MhdbZdBzprWC9nxrZ11FnU7F434YHf7C5qq2obZOdXutyf /3ndyc0z4A/3vbp+2ut5c1ZX13TfVeCZ21VZ03NXIc0c+3Dsj9W7f72HFgV3v7v7vqPL8gqWH918 3/eX5ecte4bPsTK0iaeFOWQqeV2p514l7U7ckrgnkd2TBDmlUIjWfwqoS6EhMz2TZtfiWhfC+Lwo ge5NOJIQSWAJZYOGWr2SmhnS6z2hebYWG3XYwNZaNlxGB8ugTF0t8wpDVWUgl0GCRywIO0g27EWj SrOzHXJ8WGw19BjooAEMBh6Z8MVSvhR7oYcAfLjQkVh3I+K7sdGCayaoC2csVMEAZWomqOaVByto WqeU8r0MXDddWRouteRMkZ2u6Ple19LHe+daDifvHSxvC+Z5F6wPzhhcofz6Zy//OuO7UlF1vXdT v3vu6hnupvo505zgvnPjfLdN6brTvni+nDejaHJVoT3BXFjTOXf/oft2WQvLXKY75njK8myyIdXl m9kQ1Z2dKOCA+La6H92nGJk2SPguaJHAdIIqlcSUkCDopHEJRiS4KEFEGpboYQl6pEGJ2iUgElxR CySObs7KCc2TAOGiSUgkC4FwzamC5nXum9PAHDXL6H1NLkoo8ScyXGZ2njp1SnS88MLnI0L5tTei vG3jeo282Ymf7FOkrskDk+mAC+w8FErB4HJ75oFMWpvemE5rhUaBbocDQOHWyNMBjpLBQjEhSCyy pchyxSLoLJESqCqBnpK9JdReAuMlMFwyUkJTc8I22ULiEkVfmP5vRJ7q5JSdPO7kO4CuSqaulRqt RuuvxMG1sC/NgrHezd/zU25bXuLr5ikegArF39/0i398PaOytWb2mtpcHnLObFXsNGv0Z43L06YV ZQmSe3ooT7g01pg5NTE1aWXT2Cdjv+85sqLI2/nMvf3fXu72dn5PXYeG8FGpjmO3MoXxrbULE7tr V4igIyPiFZFeFCEiDov0sAg94qBITaJdpFdEQLjIRy+dj54I49HiYfGCOCIiCiAhvh/HPcCb48gd h95LfFPObx46Jb79+RTOhw0Hbrr4M5JOvqMYmD5B79fP0gtGPR+WVbq4UJpJhng5VYagSChYqN3m s/H5uMW2x3bYpjXZqjB53HbOdtF22aataMEUjZYxm7KoPWRT8jwhh63I1mpjx1UkptjAhFRoQjiO EBZO1ZiAc+vnOzJRlt3r0NpyU4uwYv7i+9FLVevqKvGXqBufNzYTbeBPhK5TTzyRVNE531GTZp5k yffbDL9mr16vZa8+sKmiY45bo9nJxKSC6XltD6CevoYdvw99Nj6HSpVspj2Ac2ivQBUhLIwIVwRM H8G4RDHKIUF8SiBPAbpgl3xoT9Fm9N6cBvh97Sc/+Qm75513rn/rnXcmbDu7HJsDm5XF9VkdWbSp eFUxLYNaoOqqLAmpwoCwUxA02iTtBu12rZAQVArJHstlC7WUDDpm2zWg+ZLCJ1qIwRfWySQnat6L VZ1XFR7N/MSe1YSz1Kzu2lMzWvikZP8UDOhv9Q1hwl+MKT0rUfUaHtl8tJjGtlleQNWno/9yQ9Xv uEdV9ZdWNoEVUmhp0zK921cowfeuJeSFprslfU5RSRr0qLq+4pl7+dbKhK7vIETjwvWugv74LCkc H3lZZwg51P0RTGRVoAUzeoPv+z7z0dM+KPA1+nb6mMYHz/hO+37r+8gn7PTBBh80+kDjS/IFfUzr S40LvmEEjTHJWGr8yPgp38e9FoC3Au8HPg6w1wJwMAC7AtAVGAjQJQGoDYA7UBGgnwXgTwF4PwA/ D8DrN5EAUQoCZQGaHgApAD/7U+BagHYFdgYOBs4G3gqIWDz3JkaUCG+K3mjomwHAFuYElgTuCQj2 AAi8iT8F6PHAuQDF8i2B24oNAXhynJNRxuFiAJDMcU7mUIBu4czcE6DzAlARgGwVFVu7gXSI09oT oO0BmBOAKk4WTAF7gEaRNgd2BZ4PvBYQutX60aZWvRbgzDC1DVBbAKSPXbnGK13m/fg55xXaA/t5 FzmrDLtwlVd4PvBBgGGlewIwRa1kCkDZawi8FmBHAtDPq0T7xqLN8baw7ChH5uDNAQEJXQgAbQ3s DRwJDAcEbL0oAL4AECUhALqsknC+HNuG90X34dV4h9vzpTH3rPmGV/aFDZzer4R+hRM3UdxyW/Gt uz43K0dPAHxLb0DVg5kyboW+5iAAJ9pXHDoxgpHU1LK7Z7hevhl+pUyb06Zs3pPBUqaH25UFG+/M PjmB9XWHBcvuuXlkEMVz1923cPRhnGPi2GJ2HW2anb6jVDzG4DEKB2U4QOBh+WmZPkyeJnSTbcj2 pI112eDpTMiU0brtS4DtCdCbAIsSOhPoPgswC9/mzMYimaTo8MecaZcP2mG7HRrtELRDqh00dtDZ LWYV0axxgsaZ6yx1Bp2dzg3O7c5nnKedbzg/cn7qjHuTP6mTL1Tj738cOu8EXki33V5F83fra5xJ WBR0LsIiXhAFGx6/6oQRJ/zY+a6TnnLCESfc79znpP1OaHXCTOcCJ53iBIcTqNPipB86rzqpinrU ecpJVcx2Z7+TqojZzilO+vV4izhNUBGTOE1YoaL+ljMAKu4BzgB8NfIErvIMYiOrEd79/U7a6uxx 0mpnnZM6nEVOKjitTjrivOKk553vOenX403FzsfQIIYEMRSIEfpSOSVOTiDsFMLOQede57BT8DmB OGUn1eJIE0em2RQXFtO584f+Af6qMy82Wb4UL0VnScvfmWRfFWqpxWrWrS7t0/yx2dU8DSO2soAv xWdWN1fVsE09KJjYwnLyjYzcvBLug5dWAfgTotuqCX56d+68ZffelVWOoYN53g6/eWzh8Id6uz2F smRbpv69Hy17urtC0D7E2IatbqFk9Ln0pqaQZJgRXpBJV8XO9n3iViKSaUo+96Epd6UdgiK0CoPo AlwRMKq8ecIPjMUO9dUtZgweos6UM/HZc/Sn4tZr6U+RCd9OYOgDGMg1pe4bFDbpYIMWFkmd0nbp gCSoJwB8t3WAMB4R79czjKxBrzcU6oDpJLmfH/QRg1xn6DfsNzD+OGV4z/Ch4apBU2QAauBTqgt9 ZoOWBaPePzotOsFurDJS/mgxjhsFkzGa3GIUy4zKwkWhVuOg8Yh6jUK8yA9Bo3khehqqxAr5qaik paDVCzqTSDAmUE92q5LLUCNwQPn2TNS/9vGxWjfNjzHVNH9Lr7nM7L+x+Qj4dYJWPXHn8TArGtu3 7dQp+ODXY7XwS/jzmrEt4tvX26hxzDf6uCqzyegKnkb7JYFBuetp+iKluyg00i5K92m/q6X92m1a GtQu0nZqWT6XEt2sAUFj1WRrjmpOad7TfKjRoi/PDFABS4DpQcmbGgLFbA2BKq38u9tDwwY4ZYAj BthvAAwM+w3QaoA6AygGmGKoNrQbthkEFdlRuyDkMIDVAMQAVdGSowZBMGSraCrSy/7KkIpsseeF RnBQiMFhCGPMKWhVsFG2hjQsLJhAG+YijC5nKD1+bWadOlfcNxcct8/NAyx/9ApGy7qJbU1/CThL nIngTJxMvzX6GJs2uoq+tpPl7tp5/V92cbmNj/Ib3Ci3QnZCyf5DMpQX3FFANxUMFTxZwErkGpmu lx+UvyWzUlvQRksxhuZ2O8loDpVl1GbQsgzI4IdZpSSIvisvkgyYMwaNVD3w8mNOdVxB5qn4WvQV 42XJHIo3JtkytEBc+S5ocEGS1uXSJjFTQaFcyHtf6ysO1RbClELILYTPCuGNwo8K6dFCOFAIA4VQ Whgs7CxkqYVwtRBO86JthfsLaWfhhkJaplaxFoKmEHSFsolzMS6ZGk1dpgGToDe94fnI86mHHfXA AQ8MeKDTA3UeKPUEPTTVA1c98JEHznvgtAcOemC7B/pVlDIPWD3ZHqrxwM8+41VPezghoStWVfKk eijWPOuBRZ5Oz3YPwxpuXgmwyoce+O0E1e96YL9KuNcD7RwbpniqPTRrAvfgpx74seddDz3lgWc8 sM0DGziH7R46k6NCkifXQwUP/N7zFw99zwNveAD7sk/F7PRs8NCJ3mRzXBB4n5TfxHp1UkXm/B3w sGpPnYeWTrTb9SmnCe9NdI71e7bx4iB2h2VzlCQPvcq78JGH7vcc9VDsQ5fagWpeWuqhN7r5DFKg O9UuQivnIRubYtOOes573vNc9QiDqljneKAoJtZrarUjqmg2RyXS7mHpHriiCu/nXFTbPPs9pzxC lQenikf2UJ2WRwD58ebQTC1M0UKWFrQZBcxkcuXHmUOTUKfUdxJAkovFJ6oHfO5mN3/h1IGl0Q2+ 293ApbFtvy8vQF+xNn1hfbrNE7yd7peOBqMu4s017FZ0Ny5oybig+XzretWV1B9b2DASV3+a+S// Wed0MS/k5eapp4f8eCohE5KTkkunVgKubrdlhAO/elFn1uklSa9L0J28MPark69q47VanU7SyZrz //i6Vsa0Tqc1ac9F6A/Sw7ke3yRP7gL76B1C+agzeZYjJy83264k0v8xmpo205blwtysNHqR295k tL1/RBtioL9VQvspbKfwsO5pHR3Qwf2afRq6QQOqAzlAYKp+o55m6GGTAAkCsBS4F3bAEyAkax/S Pq5lGp0etIIgSbLIJ26FKIkSw5WswFBmoILBii0YPjJ8amDnDcBvNJ42sG0G0BhyDUFDp2G7gcPe QAxJx43oKyn2kIHfTbiiGCQGEitjVM/QMA0q/Rc/Dm0wQrsRFhmh2gilRsg2QpIRBCPwgJC+a4Rh I5w0wjbjfuNRI/t7yG9+aoQPjfBbI5w3wmkjHOVhZdC4yLjdeMD4jPEN428xwJQOYIKqNw9fe3U4 tI0T6jRuMDIkloshKEVCj/MEBz5jPI3YnAnpI948bOCN1hnbjezWhr/c7ga1TdYeDWxzVS7EFTe5 ifKiO2h830i/si+/VVtl5zkBzk3QKEztVPlRY2SV/9LAzFCZEbKMoF6Dole5nPjFSnbKCIPGvegE sH4jtBqhjl+6hClGcBhBrZplSQkdMeL0xXphY4+RY2vQTxC0wKhOYyIUZ6m/iqs/LvrqSnfLTGuJ un63TM2lX5pUMZC7+auisxtYbpx2vTj5uCuizjnVhfT5pk3DlotjR2Itt9Z0SuCS1H15dEWcY/86 9sGPYevYo29CPMS9NfYobIcfjlVTD40fWwLfH706+m7Uj9PivPgM54VMlyhT1WXwIIC6VG4nBwgt N91hok+agK9MO02shNUw+i0GbAXbyNDnjOcLq8CVtxITQCSJmmTZLW+WqSBbow9+YXebvF8+L78n 6z6Q4WZeTJdBkEEnM6ougQa6hNJCarCkW9THHMsSyy7LIcvPLR9YdOMWOG95z0KPWGCbZb+Ftlqg 2lJnoQ4LCBarhb45chOBA3ghR9RMJHihJp0XwgccFQ5xSrCE04Eo/PEvtRp9McT7YnsjX+Znollh xa0McCzd32sxCo82qyyPNqyZeisLmioLfE2bt/H0xUIatoDPAnynmWpN1CRBVHvVwKflNq384vnR 0lv18bao6PYoqfeWRSKmphNXSPiJU3N0GXC6bg1pOn4ztnH4z9oEq1mjSbAm6j49h/ZbSaqqrkpM rJpZlUR/HDtDwnj/sjAH/eYa8r4S2jR5aDLle4m0oxLq4zriaFP5qnKay0oZzbVAgROk5NTkgeSd yYLGlmTbYNtuEyRfUCnOKoqHLfEX42n87EFNUN1Vnp+cERLF6bNNaaBPc8xWZtN3ZgOZ7Zi9d3Zk thC+OBuGZ8O82TA4+8hsaprtm00vzL7CU6ArMGVNDdtl04xwYpIULtFArgY0BMPK4ubmS7E9S1ga 3aRXD9R4JHHjBCa2gXnLrIdbTl8C4LpxL1Hd//Xje6o/niWarZqEL2zf0+zmvZ1K/CuWze2B9mAu tVbU94RWPIa+d9uh7r5jXsqYQJ/nGzIXPZPDK0prls+w25Vl1aUrFhSPLc6dvWx62pz5WXPuXfRS wZxyV83QLx66/8Kjc7vaUiun5jPJPb027/o//fsf2BvrvtNZVLTiOz3rDy8r9LZ/O2o3XsfHNzCu ZGSTEmRNJgL8r00DMnGQC4S1kh4cPzWoDJMIEbXkOL+ifUSMiIzf1FbEsJoZFq+IOoe4F1/8VHr4 5WmBkPqeVKS+TxvlEDAekFYBv4u0rle9wY1iRZlGI9PXz/F7LDfusT+KPEmk6yyhvHZKiFKNjg94 uTYupNMZQGwiGlmjaJiWh5lCy2UAE1RBN2yBw3Ac3oGLoNOBkpwZAhBJi5aJtx/a33rJ3eeeXATq /XYXPmEFs1z/8zn2sfCH0avfHv0ncetTKJ2JOwVJxEm85JCy+lDK8yn0MQc86IDHJsH6SQ9Oopuy h7KfzGaiIdGQY2AamkRzKXveAoctcI9lM1oCZskwNiUraGKTkwtIk2LP8mXR41mQVTSYUXCzQ5b8 li0Y7GQUpCPfBS2aWy7nl0VvjMUOATnrl8xlqHzRs8CoHkbvHvDj0kR+fpTJIHYBoZKqqhdNCn+s e+SHK0fPU7L+zOAs56yOWfUPNHjH/vzU/rFzMKOuP+SYP/nureGxp6CvdnNjMTx8z+MtHnFrXt3W poqV9QGTvrxpI53Zu2xspjOwaPRHs5ZOzxgTUqa34/h5UVan+P0ueA/jIQnekt6XPpPYaxLUSo3S gLRTEir4tkGqRD+V4KD0lkR3RfO1UpckvPm+9LFEfy7BaQkKsEIXVjgoiekSaCRIlQpUGgelY0hV +zESph9IcEyCAxKUIS6dJAEYJHj8HmmztEt6XnpN+pN0TdLWYbQuuaUKzsc1iR6VoEKagygsW4Jd 0iFE+znCxS0S0HlSi0SLJEA7u+Id6aJEIzzNoXsk4YoEh6XjEocLPRK0SKCoZ5J2qQoRuqXDWHBZ 0hIJpl6WYFBplvZKFyTWLUFYAp96pnlBguMS7JWgW9oiUVlySIoUloToMeg5TrAVKx2RhCoJHCob qL5CPDRRhWrje7RHtBF+S21QS7V8SpjQBmodFJ0doUWM3izgN8Ob3+buO6SlyHNHPyxuuW3X+dbr AusmDFxs6zqam4hNbnFuoqh8quA0wUifXvjRWIawXfjDtXThD0/F9pOWwAU6j/bgjHEqVoIM91CG FuS1wzglqQ/Qk/Opd2b4lfsEJLIErsKFI0fUuu3klDBb+DYxkNmK99cGeNAAvxNgSAAJntPI1EEp fZ/CNLoDE0R4UfqtFqaiL0+14su4HDarJ3Co/77o6a86F6Ksqhtf9PBjYw3w7GPwLG0dq4MX9sEL Y3X7eLvN458IfxMPkCrye2XtgUqoroRnKmB7KWybDI/nwzEnGJzpTrfzkFNotB2z0V1m2KWFAxTU Ww7byqG1FLoSYYMZCpsK+LyOJEDCjEGpSafICWitpjQRu2xX7ExrT5ATkkL3JuxIeCKBVSTAFO4v +RC0ccpDUx6fwsqnQMIU0dfSXQiNhTBH3VkozBbiW1olWCBBNc4SfrOMh5WX1GczvyCg7kFG/+5p Yn2KXRBQTQLc5pmq5sGRjSsVu3lPQCyJ/YFG9KZAdG1KzhSFv9Xs/eDA2Gdj/5J/Nr58+b7O+kc6 y6p6v91asXFNazB//t7zvQ/8YHBu8g/jSxZtXrjswfmuqtWPhGds3bDiTjc82HhgTeDMSzlTm2Zk 26a3zKxZNC03yWh3l8+/J9i+5+7CggUDYac/XJrhmj7fVzW/NNtiwsK6XlUXzox9DlvJBySO3HWW COMjrxrMIf3j5ICq8UmSOaQdjNsbR5W4cFwkju2NOxJH43hRfG5BKI6fhsZpnyWHDMQ3+iH41BXH 7x7lB+w5idFDdShxlcBWyWqzbp40ueGDZ0sWz5npmLFtxgdRPZYIEeeiDZPJn5RX7ohvil8Vz2qE eqFDYLtNUG5qMq0ybTIJDzAoYfxPadYzoZ9sI1QisBtgM4AGIA0KoRwY2qOP4TPAiCOHlBCmIfAR +ZRQ1ctOMxWayk2M6UzwH6a/oWs3Bb1q6pCByjIUya3yXnlYviKL8peuo9JzOAsclrCFFllaLXst w5YrFhGdRBNlA6gm3AzwW8Y376D61C1yP3/eegv1tluJ3L+Dm7E8+Fn8G6P/+BZsN2XGxRvj4uNs Ztj2lrj1umNSo6sgL6fA1VDERri8tow10G+Lb+P6OFOZ9JARHpKgwQoNFMwp8eaQyB+yRpY1gxqq MfyFuxQOtBFyuki4T+BrvvR287Ri1dvET8KEtzRxCLylsGl320tLdza43Q07l77UtrupkFp3jf3x d11d//qnsV27xj7B1O/+OLpbHbs45MWt8hJSjDuMsEOCxVZYjLycGf+Plzk7+D6lcsTnn2zX7EGu yF/2GMAgE36ywDkavZUjmLiJMXGKRt1fwZK8e5Sz9LtPOEt/+lfO0tiuqA/M/2awA/UpjqSSdiV4 LAU2p8ALyZCe7E6uSN6cLByTIR0jrgqMuYTNJjjIYABVpEnxYUSbPqikg/Wmg5CAfoF1wi9Q5/2X r5iClcaDutZPXCyNrvtix6oz1x4d/U9493uQ8Eb38IL9v9w89p9Q3v360F30ncjYf73SLG6df2zs +qk9P78/cO1E6JH3JvhfifybSSZ5V6k8ZoQh65PW56xsvw3W2x600ZcIPI2uJNlN6B2kiawijB0B 6IX7YR+G3MsBFEDdghwAJp8Z71EWm2t75EHUb1Ynt8t0Jqq8S/bLFGQ51dJkMBBiLjIr5lbzXvMR s8asOPY6jjhY6i1/SCnTFl9qS2p36p5UITWVpLTcuH/NHaPm6F9HXSpuRvUv8yFI3fPn61r04KYl FjqpNtIJE7c1VfMA7BZHaffYvrHac/Txe8/eNzOv7v4lsPdvnrp77xyrgF8suHduDq0dfVXcOnXl gaWz7l99lzz6HfaJsrTKPvq3gtCyqC3Br5j59NlFL7aYpv+V2KP/P+TN+udfnfgfF+OjY4s1LpH/ Xxkd97dJrJ62cuwuMuvG/8kAcvtnMv2EVItvkmfV7yLyLC0jdqGPPILfxfQ5sgPfOwRCFvM8frdp nlPxBMRfqSkjbQh7kNfD7yRML0LcMniT7OS4+B5Cevy2vQ2/r/FyzXMqPRHTz+J7CL+TxTfHR/Gd jF8tx0Hc14V/j/KDby/ysUR4gbRjvhnLzuBbQtgW/MZxvrlm4cdDTgGBSjhC9XQT/SnGgi8IDcJV TZ1Wo31SJ+u26f5DX6h/0hAyHIjzxPXgzx+NKcbvmurkP5vTzKcsYWtv4ljynSlpKe0pL6VWp81M a017Kr0z/ZmMyoxtGb+0eW1vxyRYTIJoeaKzUiY+1FXCvi0OI4yXZsCiG3JWbsgciIkosTQlWjIv lmYkjUzgC4jTE0uLOM+3xNIaEk92xdJasokcjKV1xAoJsbRE4iEvljYgDyU3/vOPF+bH0kayBSZo xhM3jHGOBVynyCAtiKWBZNJjsTQl8fTNWJqRKfQ3sbRAMpkUS4skheXF0hqSwapiaS25ypbE0jqS L8yLpSWSIWyMpQ1kmvBYLB1H7hZ+HksbyZg4QTMedSanumtFV3/Xpo52R3tbf5vjmKO4qGiqY0bf 8o617R29jlndvT3dvW39Xd1rvY4Zq1c7ertWrOzvc/R29HX0buho997ZtawjWu5Y2La2b0HHivWr 23pv1J/k+ALCF7KLOnr7eHqyt6j4ZtEXELv6HG2O/t629o41bb33OLo7HQuQ31Bbv8dRu3a5F5lZ 0dXX39GLwK61jnrvQq8j3Nbfsbbf0ba23VF3o+K8zs6u5R0qcHlHb38bInf3r0QuV63v7epr71rO W+vzflXnF/Z3bOhwzG3r7+/o6167sr+/p9zn27hxo7cthrwccb3Lu9f4vq6sf6Cno72jr2vFWuy2 d2X/mtX1fR28P/0rsY+39LizG5nv6+7s39jW28H737d+2aqO5f2O/m7E7XCsxn6sxaptK3o7Otbw nq5XOd64smv5SsdA93pH2/LlHT39KBGO/vcoe7+O2dU3KqmckmrSRVbgtx+/m0gHBgQO/LZhvg1T x/BbTIrwZyqmZpA+shxx1iJGB+lFyCzSje8e9dmm0ujGUq+Kuxp/HAjn9FdiWZ+a68A3r7tBbctL 7sTyZSrkZn0HWYi5tYi5AEtWkPVIqQ0xvtz+JPx+PYWvL12klvTdgE9Gjoqwx19V6+spdqn94zLr V0s4h2tUru9BWDfpxOeCmHxDak0Ppmqx7nJVXr1qTzmVfpV2FLNLpV2PGAtVrLBak0ugX21trYpV 9xUtzsMWO7E+l9dNzOUqbT62UcrdmF4Zk+UqlHOvykG7Wm+ib33Y8v/uyC9UudugtjlXhferI87L Vqq5HlKOC4CPbFR/vIhzO+XlMbpeNbUGMf9v6/WTAcx3qOV9qhaujY22V6W5BrWqXtXGifHhsoiO 41ePcaf65pLvU2v0Iydt6lhNjH8fynAZSrJDlR+n2B2jy3FWx8ZjbazVNuSJ1+bjNjGm62+R8UaV n+X4dGBfurGM11mu0uhRJdt+C/X/U569/9eSXf0VLd2UqbpGR32sPHKAfMXnhKT8CLT8P1ioz8Mg KI/A8CgcHwUyCvp518BxDf4azrf/JZhv/89gof1K0G1vubzlMjVdnne55fKey8cvi4Y/fJhp//ff B+2m34Py+2CS/d9GgvZ3Ri6OXB5hyoi/NDgSTLH/a+Bi/X8PsPqLwOp/x8btpt/Yf0PVh/KzlPTg Oz+G14en2/8xnGv/4Y/y7eNnIXym58zgGaZeSjtjKQ7aX616dd6r3a9uefXwq8df1facPHIycpKZ TsLeVyDyCpheAZ3p5aqXL7/MBiN7IzQSGY5ciDDf8arj9MiLkRfp8IsXXqS+F6peoIefh+HnLjxH 5x3bc4z6jnUfO3ds/Jjw1KFse/gQdB+AcwfgQNBm/9b+ZPuW/Xv2j+9nRY8qj9LBR6Fnz+AeuncP DO+5sIfO292yu3s32x4ctx9+ELY9MNne31dl78MedK+dbl8bLLGnQUp9qj+lXutn9RrscyuWteD3 7uBk+5KmkL0J3wnFlnoRZSIUs/puBiZWxejl+ePzqTK/ZFpQmZ+TH3xHqQtDbdBhDyHN2fg9HoSL wctBOhiEpOLEejOY6uViUz1GTPXoRtrtpipTi2mLSTCZfKZ5pm7THtNF07hJW4WwyybWTWAwCUQ4 A3tP1C10u+ec0Y4vmBPRhpdEYEckZyF/KvObIpodEVLftKThBMAjjQ8+/DCZaZsTKV7YEGm1Nc6J tGNC4YlBTMi2Exj6Nvb39a9X/+QWognS73b39fEU3/cm0T/HBTUF7j4sRrS+/j7M9K8nfe6+fujr w9WpH+F9sBTTfX0c3AdYA7997ih5pICElyIBfPRHSff1IX4f1u9LWYp6/b8ABg4+wAplbmRzdHJl YW0KZW5kb2JqCgoxMSAwIG9iagoxNDIxNwplbmRvYmoKCjEyIDAgb2JqCjw8L1R5cGUvRm9udERl c2NyaXB0b3IvRm9udE5hbWUvQ0FBQUFBK0xpYmVyYXRpb25TYW5zCi9GbGFncyA0Ci9Gb250QkJv eFstMjAzIC0zMDMgMTA0OSA5MTBdL0l0YWxpY0FuZ2xlIDAKL0FzY2VudCA5MDUKL0Rlc2NlbnQg LTIxMQovQ2FwSGVpZ2h0IDkxMAovU3RlbVYgODAKL0ZvbnRGaWxlMiAxMCAwIFI+PgplbmRvYmoK CjEzIDAgb2JqCjw8L0xlbmd0aCA0MzcvRmlsdGVyL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnicXZPL boMwEEX3fIWX7aICD2AaCSGlSSNl0Yea9gMIOClSY5BDFvn7eua6rdRFomN8Z3ywhnS1XW/dMKev fux2dlaHwfXenseL76za2+PgEk2qH7o5ruS/O7VTkoba3fU829PWHca6TtK3sHee/VXdLPtxb2+T 9MX31g/uqG4+Vruw3l2m6cuerJtVljSN6u0h9Hlqp+f2ZFOputv2YXuYr3eh5C/wfp2sIllrqHRj b89T21nfuqNN6ixrVL3ZNIl1/b+9YoGS/aH7bH2I6hDNsuKxCUzge+YcXDIXwlXBXAobyRiwZCpk iPkez6XnApwzL8Ga+QH5jHmFs9bMa7BkHsFSuwGHl6p1hlo+V8O/5D4a/uWCGf5G8tGf++joL5no z84a/mbFDH+SntHfMMM/XzLD3/CdaPgb9tfwr6R/9Jee8DcPgSn6cx+Cf1Uxw7/iuyX4V3wuwd9I Bv4F9yf4F5KBf8HvQvAv2Y3gT+xG8CdxgH/Jd0LwJ/Yk+JfSE/4kPvAnPjeHf8H983j/JMMWp4rH jr+Ln3FW3cX7MMry8cgM8/QOzv5+X9M4cZX8vgEBVN4bCmVuZHN0cmVhbQplbmRvYmoKCjE0IDAg b2JqCjw8L1R5cGUvRm9udC9TdWJ0eXBlL1RydWVUeXBlL0Jhc2VGb250L0NBQUFBQStMaWJlcmF0 aW9uU2FucwovRmlyc3RDaGFyIDAKL0xhc3RDaGFyIDQ5Ci9XaWR0aHNbMzY1IDcyMiA3MjIgNjY2 IDI3NyA1NTYgNTU2IDMzMyA1NTYgNTAwIDU1NiA1NTYgODMzIDY2NiA3MjIgNzc3CjU1NiA2NjYg NjY2IDU1NiA1MDAgMjIyIDU1NiAyMjIgMjc3IDI3NyAyNzcgNTU2IDgzMyA1MDAgNTU2IDUwMAo1 MDAgNzIyIDUwMCA1MDAgNTU2IDI3NyA2MTAgNjY2IDYxMCAzMzMgNTgzIDY2NiAyNzcgNjY2IDMz MyAzMzMKNzIyIDcyMiBdCi9Gb250RGVzY3JpcHRvciAxMiAwIFIKL1RvVW5pY29kZSAxMyAwIFIK Pj4KZW5kb2JqCgoxNSAwIG9iago8PC9MZW5ndGggMTYgMCBSL0ZpbHRlci9GbGF0ZURlY29kZS9M ZW5ndGgxIDU3MTY+PgpzdHJlYW0KeJzlV31sU9cVP/c9f5FA7FDKUrnF13uEJnNiB9IPYGkxie0k BBbnw8wOHfjFfolNE9vyewmFDZG1aosMtKzTaFmZ2F9bu3biGbYpTKyk2qZq0qpuf0xT12aNtP43 MhgrldYWsnOvn0PCQrtV+2/Pfte/8zsf95xz77OvtfyYAsthAkTwJ0bl3CpCAK/fApCViXGNzm09 6kI8AyCsGsoNj9Y1v/M3APEDAKt5eGT/0C//8MN6gIpP0CeaUuRk3T8v1QFU9qP8QAqJjhv7rSgf RXltalR7LACXTCjrKNtGsgm5ARoQVk7iYBmVH8uploNMP4Uyzcijime97TmUcX7rdC6raklYOwdw B9fn8kru2sDzNpRZfhpyBHj6WBEQC5f/zy/zMbgTOswPgR1yfFx0ia/CXexz7tLi8cb2uY/+l1nY Sh8vwA/gJ3AM3oavGYoQhCENY8gsvF6H3yPLrjAMwI+gcJuwr8Ik6kt2cXgWTt7GLgzPwzl4Y9Es YRiFr2MuP4W3yXr4DW6VLFwlNvgm/BqjXkVux1KhhCochjgcWsC+Ay8KR2Cb8D4KJ5lG8AkO+BWc IrsxsoZ1HpuvuOXfgj4NB3HsgxSMI+aX+aFP/gTL5v6BVR2EbfA4bIWRBR4XyGmxAtevH05jT1/n nK+stHaIe4WfCcL1b6PwLRjGWyZYu3BM3AoBc7U/GItG+vt6e8LdX9mxvWtbZ0d7KBhoa93q3/Lw Qy1f3rxp44MP3L++yedtbKi7d13tWumLblfNqmqHvWpFZcUym9ViNokCgYagFIpTfV1cN62TOjoa mSzJSMgLiLhOkQotttFpnJvRxZZ+tBy6xdJfsvTPWxIHbYGWxgYalKj+ZkCik2SgJ4r4WECKUX2W 4x0cm9ZxYQUKbjd60GBNKkB1EqdBPTSeKgTjAYxXrKxok9qUisYGKFZUIqxEpNdJuSKpe5hwINQF NxcFsK1g0+pibVBO6uGeaDDgdLtjjQ2depUU4Cpo4yF1S5tu5SFpmqUOR2ixYapwdNIBg3HP8qSU lB+J6qKMvgUxWCg8rVd79HopoNcfeL8GK1f0BikQ1D0salfv/DxdN6ckurnWIdHCNcBypNlLixnZ YCy1jmvAYAjbWyiEJBoqxAvy5NzEoEQdUqG4fHkhF8QOQziKXpNzPz/i1ENHY7ojniKbjWJDvV36 HT27orpQG6IpGRl8b5HcG53u6ljZJnw7NWAjsB3YU7ebFX5k0g+DKOgTPdGSTGHQeRb8Pk9MF+JM M1XW3BlhmomyZt49LuFqdvVFC7qptjMpBbHHR2R9YhD30162FJJDr/rQ6ZYKK6vpJl+M21LMqjOZ prp5HbYFvRY64E5hLgUHF6o+LH3MOnGCddUr6SYJw7A4QSkYN97jqRoMQBsb9A5Paen7o7o/gMAv G2sULDb50EOO4xKlA3z5dJ+U01dJrfPrydIKpvui3MVw01e16RBPGF66LxhgM9NgIR4opcBiST3R 89A8N1O8jzrPNcN9EAsw49VtuK/WBQvR5JDuijuT+KQN0ajTrftjuMAxKarE2EbDDtXP4HRuPqMu tPVHu/qkrp6B6EYjkZKChTPVBm8JI0WdpTC45XRbrY1GBacYQ0MHEjSEQGptwVG31trwdmDDOcu2 amsLjRInlK0xDb2eBpWAYcfkRUHNbDu1dZSjWZiIcdo6nO6Yu3Q1NgiopsbE6GFjTe0oq8Ra/CZA TsAwnGK9rGF7nkYlRYpJKar7w1FWG2sP77LRDN5zY636F0kLmoVtAjeqywJrph7yOBc2V2/n8rzY cYu6s6ymBZvU1VdgwSUjIGDmnTqwLezfWO3kTz97nqWQjA8xPtH8eS4U/X72LKfYY1uQOpMFqS/a wq3xG+Sg8wCbayV0ka7+1sYG/DJrLUrkcE/RTw73DUTPO/A4dbg/elYgQlu8NVZci7roeQrg56zA WEYygTKBRepFwcbtnef9ABNca+IElxOTBDhnK3MEEpNCiXOUOQE5U4nzc45duEo1Kewxfn8HaZKt zzdiqUI8xvY4rMaO4JvoRHoYuyM9XCSCZbleISmteqXUyvgtjN9S4i2Mt+LOIKtJY8OBgiMoXatp 5D/bEMAhaY7g6dcK3iIBX8tZq8k2u6FoMb/bclYUEEJRZLSZ0WetlmWftJwljG+udlfXuqvdAYHe WEteuJEyRz56JWB6E0qnTmJe0/7hY/v32Fuugat0/nkj8srkorMEm5kdjgSDQD+r+0YQvjpvcuv5 VRAuQcAwLx2dCa+jHEMAB54D8ExkqrRswqqY9m6ycz6Ofz4mQUu/gQWsPmxgEZw4fwmb0CZvYDOe qR83sAXPkc8Y2AoH4HsGtsEq8gUDL4Mq4jFwJeawaf5k7iURA6+AQ+QJA1eBRxBYxqZlKE0IjQYm QIUfG1iAKuFNA4vwAJ66StgEVKw2sBlqxPUGtsAasdPAVvhAHDawDepMuwy8DO42PWHgSthoOm3g 5fCI6Y8GXgE3zM0GroKdlvWB9HBaSx9QkjQpazJ9mW5oanqQblUTSiap5GlbNp/L5mUtnc146daR EZpPD6c0leYVVcmPK0nv9vSgUtLTPiWfHupVhsdG5Px8gEZ6q8Wt8k4lrzJhvbdpw03draZpFU9f Wl5OKqNy/lGaHaK9mHOHrDXQzkzCiwkNp1VNySOZztCIt89Lw7KmZDQqZ5K0f96xe2gonVA4mVDy mozGWS2Fie4dy6fVZDrBZlO9SzWgT1PGFbpD1jRFzWZSmpbb7PPt27fPKxvGCbT1JrKjvk/Taftz SlJR08MZrNub0kZHIqrC6tFSWOOCioeymLyaHdL2yXmF1a+ODe5VEhrVsmir0BGsI4Ou8nBeUUZZ pWM8432pdCJF92fHqJxIKDkNO8LMbxfZ+2nJjsw78UzxSyaNh/A0aHgfAAWSQPGWUZYRvYz3BmjC 14OItoIKCbTJoIWCDx+FNsjiZ46PMo+RRa2X247giyLP4qdQp3JJwU/mO87n8sJ21A9y5qY/xb8b Cvccgl5Ew/gnbAT1+SUyaMT7s2J8ln4nR+q8Zj3m1YR1L+X3WVHTvE7WO41rWJ6jPPdHkcuiH+U1 sT53cM8GRJ3om+B9y/N6WRSNxy5ZpnnsCFr0casw92R90PhsGW7Vv8SM3TjjEPqzrt20TPDYbI1L kbOIU0ZH92K38zyDJPcr16bizP/pDujj2Y3zOXdwXuMrz3QpLuVgM/4Y+GAff3nRZnHkhBHXy9Eo Wn5ePw32o6xwvcp3Y8ZYby+POYp7K8J3ZXl9WC9K67j0Gg/xT9Z5lXtomInM16q8/ir2cBA7qfD+ sYhZIy6zGTHWI2PMKmNOzJutW3lNxxb0eB/PJ4EjxVqyqGM+CR4jxzubXBD9v83Z+7k7O7LETDd7 yn+v+TXnxhBLXMVl8deIFX9Ft/DxIjH5Y2TmOnnrOqHXyaGPSfhjMnH1+FXh71fqXWeuXLwidF/e c/nMZbHpMrFfJjaYdcyGZ+Ozudnvz1oq7JfIcvgrqf7LzEbXe83TkT83vxuBadISnp6Y1qfFybkp /8C0rTI0TcTIu+Jql2OKTjVN5aYmpn43NTN1Zco28drx14RfXPC57BdcFwTXue5zh86J8ZeI/SXX S0L4xfiLwvFTxH7Kdcp3SvzuSa/rZPsa1/Mn7nXNnLhyQmDh7z+xojq05zvk0HPPPifknpp46vhT 4sSTx58UzoxfHBfUcL0rm/G4Mu1fct3VXBOxNosRizjnYp6Bwdq6UHyP37UHjXYNNLkG2utddzSv jJgxWRMa2kWXuEXsFrPis+JF0WrrDa9x9eA9E74SFuzdrm5fN1Y445e73BhoW27bxDaxM1Tv6mjf 6LK3u9p97W+1v9d+ud2yp52cxnfoTOhiSPSH6n0hf2iNO3R3hzOyuvnOiKPZHhEIREgzRHz2Obtg t++xH7KLdtgCwsRqYiaT5Hixv8/j6Zq0zuG/b1t4l04O67V9bPT3DOiWwzpEBnZFi4Q8E3vy2DFo vadL39AX1eP3xLr0JAI/AxMIHPcUV0NrTFU1D7uIx4NwDEfwjCG1Wy2R4CmrwaMSVQVVJR6m4xAZ UD2MZgzzIei5WwU2MK2HWzGkqjW7/wV9RBAnCmVuZHN0cmVhbQplbmRvYmoKCjE2IDAgb2JqCjMw ODQKZW5kb2JqCgoxNyAwIG9iago8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL0JBQUFB QStMaWJlcmF0aW9uU2VyaWYKL0ZsYWdzIDQKL0ZvbnRCQm94Wy0xNzYgLTMwMyAxMDA1IDk4MV0v SXRhbGljQW5nbGUgMAovQXNjZW50IDg5MQovRGVzY2VudCAtMjE2Ci9DYXBIZWlnaHQgOTgxCi9T dGVtViA4MAovRm9udEZpbGUyIDE1IDAgUj4+CmVuZG9iagoKMTggMCBvYmoKPDwvTGVuZ3RoIDIy MS9GaWx0ZXIvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJxdkEFPxCAQhe/8ijnuHjbQnpsmZs0mPega qz+AwrSS2IFM6aH/3ilWTTxA8njvgzfoa/fYUcj6haPrMcMYyDMucWWHMOAUSFU1+ODyocruZpuU FrbfloxzR2NsGqVfxVsyb3B68HHAs9J39siBJji9X3vR/ZrSJ85IGYxqW/A4yj1PNj3bGXWhLp0X O+TtIshf4G1LCHXR1XcVFz0uyTpkSxOqxpgWmtutVUj+n3cQw+g+LEuykqQxtSnZ43Sn9rF+2oBb maVJmb1U2B8PhL/fk2LaqbK+AH1ZbXUKZW5kc3RyZWFtCmVuZG9iagoKMTkgMCBvYmoKPDwvVHlw ZS9Gb250L1N1YnR5cGUvVHJ1ZVR5cGUvQmFzZUZvbnQvQkFBQUFBK0xpYmVyYXRpb25TZXJpZgov Rmlyc3RDaGFyIDAKL0xhc3RDaGFyIDEKL1dpZHRoc1szNjUgMjUwIF0KL0ZvbnREZXNjcmlwdG9y IDE3IDAgUgovVG9Vbmljb2RlIDE4IDAgUgo+PgplbmRvYmoKCjIwIDAgb2JqCjw8L0YxIDE5IDAg Ui9GMiAxNCAwIFIvRjMgOSAwIFIKPj4KZW5kb2JqCgoyMSAwIG9iago8PC9Gb250IDIwIDAgUgov UHJvY1NldFsvUERGL1RleHRdCj4+CmVuZG9iagoKMSAwIG9iago8PC9UeXBlL1BhZ2UvUGFyZW50 IDQgMCBSL1Jlc291cmNlcyAyMSAwIFIvTWVkaWFCb3hbMCAwIDc5NCA1OTVdL0dyb3VwPDwvUy9U cmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCL0kgdHJ1ZT4+L0NvbnRlbnRzIDIgMCBSPj4KZW5kb2Jq CgoyMiAwIG9iago8PC9Db3VudCAxL0ZpcnN0IDIzIDAgUi9MYXN0IDIzIDAgUgo+PgplbmRvYmoK CjIzIDAgb2JqCjw8L0NvdW50IDAvVGl0bGU8RkVGRjAwNTMwMDZDMDA2OTAwNjQwMDY1MDAyMDAw MzE+Ci9EZXN0WzEgMCBSL1hZWiAwIDU5NSAwXS9QYXJlbnQgMjIgMCBSPj4KZW5kb2JqCgo0IDAg b2JqCjw8L1R5cGUvUGFnZXMKL1Jlc291cmNlcyAyMSAwIFIKL01lZGlhQm94WyAwIDAgNzk0IDU5 NSBdCi9LaWRzWyAxIDAgUiBdCi9Db3VudCAxPj4KZW5kb2JqCgoyNCAwIG9iago8PC9UeXBlL0Nh dGFsb2cvUGFnZXMgNCAwIFIKL09wZW5BY3Rpb25bMSAwIFIgL0ZpdEggODQyXQovVmlld2VyUHJl ZmVyZW5jZXM8PC9GaXRXaW5kb3cgdHJ1ZQo+PgovT3V0bGluZXMgMjIgMCBSCj4+CmVuZG9iagoK MjUgMCBvYmoKPDwvQXV0aG9yPEZFRkYwMDRBMDA0ODAwNTMwMDIwPgovQ3JlYXRvcjxGRUZGMDA0 OTAwNkQwMDcwMDA3MjAwNjUwMDczMDA3Mz4KL1Byb2R1Y2VyPEZFRkYwMDRGMDA3MDAwNjUwMDZF MDA0RjAwNjYwMDY2MDA2OTAwNjMwMDY1MDAyRTAwNkYwMDcyMDA2NzAwMjAwMDMzMDAyRTAwMzI+ Ci9DcmVhdGlvbkRhdGUoRDoyMDExMDQxNzIwMDMxMy0wNCcwMCcpPj4KZW5kb2JqCgp4cmVmCjAg MjYKMDAwMDAwMDAwMCA2NTUzNSBmIAowMDAwMDIzNTE0IDAwMDAwIG4gCjAwMDAwMDAwMTkgMDAw MDAgbiAKMDAwMDAwMjA0NyAwMDAwMCBuIAowMDAwMDIzODIyIDAwMDAwIG4gCjAwMDAwMDIwNjgg MDAwMDAgbiAKMDAwMDAwMzUxNiAwMDAwMCBuIAowMDAwMDAzNTM3IDAwMDAwIG4gCjAwMDAwMDM3 MjYgMDAwMDAgbiAKMDAwMDAwNDAxNyAwMDAwMCBuIAowMDAwMDA0MTc1IDAwMDAwIG4gCjAwMDAw MTg0NzkgMDAwMDAgbiAKMDAwMDAxODUwMiAwMDAwMCBuIAowMDAwMDE4Njk3IDAwMDAwIG4gCjAw MDAwMTkyMDQgMDAwMDAgbiAKMDAwMDAxOTU2MiAwMDAwMCBuIAowMDAwMDIyNzMyIDAwMDAwIG4g CjAwMDAwMjI3NTQgMDAwMDAgbiAKMDAwMDAyMjk1MCAwMDAwMCBuIAowMDAwMDIzMjQxIDAwMDAw IG4gCjAwMDAwMjM0MDcgMDAwMDAgbiAKMDAwMDAyMzQ1OSAwMDAwMCBuIAowMDAwMDIzNjU3IDAw MDAwIG4gCjAwMDAwMjM3MTMgMDAwMDAgbiAKMDAwMDAyMzkyMSAwMDAwMCBuIAowMDAwMDI0MDU0 IDAwMDAwIG4gCnRyYWlsZXIKPDwvU2l6ZSAyNi9Sb290IDI0IDAgUgovSW5mbyAyNSAwIFIKL0lE IFsgPDY0NUE2MjA1MDkyNTlDRUVFQkMzRUUzQzY3NzIwODAzPgo8NjQ1QTYyMDUwOTI1OUNFRUVC QzNFRTNDNjc3MjA4MDM+IF0KL0RvY0NoZWNrc3VtIC8yMDlCODI5OEFBMEUxRUM3MERCQTdEQzE1 NkM3Q0YyMQo+PgpzdGFydHhyZWYKMjQyNzUKJSVFT0YK --90e6ba53a91254216e04a12648ea-- From joel@stevecrocker.com Sun Apr 17 17:19:27 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id EFC21E0687 for ; Sun, 17 Apr 2011 17:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1DwQR6fPjmg for ; Sun, 17 Apr 2011 17:19:25 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfc.amsl.com (Postfix) with ESMTP id 84F5DE0743 for ; Sun, 17 Apr 2011 17:19:25 -0700 (PDT) Received: from [71.161.50.206] (helo=[10.10.10.101]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1QBcBW-0005Bg-OD; Sun, 17 Apr 2011 20:19:23 -0400 Message-ID: <4DAB8386.7040707@stevecrocker.com> Date: Sun, 17 Apr 2011 20:19:18 -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: <201104131847143284482@mail.zjgsu.edu.cn> <201104131925587965227@mail.zjgsu.edu.cn> <4DAB099A.70303@joelhalpern.com> <4DAB3865.7090600@joelhalpern.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050800020400070107060707" X-ELNK-Trace: 9f083ca8aeb2d326d5a073bfd238dd844d2b10475b571120ad0d66affdf31dd123abe69a94f392dad1ca0e3be97fa7bb350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 71.161.50.206 Cc: "Joel M. Halpern" , Chuanhuang Li , wmwang@zjgsu.edu.cn, forces Subject: Re: [forces] BasicMetadataDispatch WAS(Re: LFB LPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 00:19:27 -0000 This is a multi-part message in MIME format. --------------050800020400070107060707 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I am not sur ehow the slide relates to the question. Remember that the design is explicitly constrained. We do not currently support passing metadata between FEs. Therefore, there is no way to say 'send this to some other specified FE, and preserve this metadata information for that FE.' Clearly, we can do so later, if we want to. For now, you can only specify the output port as understood by this FE. Note: That does not prohibit the CE from configuring the dispatch logic to know that logical ports 1-100 are actually physical port A, which is an inter-FE port. All sorts of games the CE can play under the covers. Yours, Joel On 4/17/2011 8:14 PM, Jamal Hadi Salim wrote: > On Sun, Apr 17, 2011 at 2:58 PM, Joel M. Halpern wrote: > >> Remember that the ForCES LFB includes the information as to what LFB pair >> sequences (A followed by B) are allowed. So if the LFB requires that the >> etherencap or other media encap follow the NH LFB, then it can specify that >> and the CE will know it. >> > Makes sense - but something is still obscuring the view in my mind > especially after i tried to put together the attached slide to clarify > my understanding. > Let me know if this is the intent. If it is, could someone elucidate how > one would go about mapping as a NH port something that fits > "port x on FE y"? > > cheers, > jamal > > > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces --------------050800020400070107060707 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I am not sur ehow the slide relates to the question.
Remember that the design is explicitly constrained.  We do not currently support passing metadata between FEs.  Therefore, there is no way to say 'send this to some other specified FE, and preserve this metadata information for that FE.'  Clearly, we can do so later, if we want to.  For now, you can only specify the output port as understood by this FE. 

Note: That does not prohibit the CE from configuring the dispatch logic to know that logical ports 1-100 are actually physical port A, which is an inter-FE port.  All sorts of games the CE can play under the covers.

Yours,

Joel
On 4/17/2011 8:14 PM, Jamal Hadi Salim wrote: 
On Sun, Apr 17, 2011 at 2:58 PM, Joel M. Halpern <jmh@joelhalpern.com> wrote:


Remember that the ForCES LFB includes the information as to what LFB pair
sequences (A followed by B) are allowed.  So if the LFB requires that the
etherencap or other media encap follow the NH LFB, then it can specify that
and the CE will know it.


Makes sense - but something is still obscuring the view in my mind
especially after i tried to put together the attached slide to clarify
my understanding.
Let me know if this is the intent. If it is, could someone elucidate how
one would go about mapping as a NH port something that fits
"port x on FE y"?

cheers,
jamal


_______________________________________________
forces mailing list
forces@ietf.org
https://www.ietf.org/mailman/listinfo/forces

--------------050800020400070107060707-- From hadi@mojatatu.com Sun Apr 17 17:31:12 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 800D6E0744 for ; Sun, 17 Apr 2011 17:31:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.872 X-Spam-Level: X-Spam-Status: No, score=-101.872 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w7gb9FU9ybxG for ; Sun, 17 Apr 2011 17:31:12 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfc.amsl.com (Postfix) with ESMTP id E914FE0687 for ; Sun, 17 Apr 2011 17:31:11 -0700 (PDT) Received: by vxg33 with SMTP id 33so3960405vxg.31 for ; Sun, 17 Apr 2011 17:31:11 -0700 (PDT) Received: by 10.52.176.134 with SMTP id ci6mr5122349vdc.190.1303086671721; Sun, 17 Apr 2011 17:31:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.185.193 with HTTP; Sun, 17 Apr 2011 17:30:51 -0700 (PDT) In-Reply-To: <4DAB8386.7040707@stevecrocker.com> References: <201104131847143284482@mail.zjgsu.edu.cn> <201104131925587965227@mail.zjgsu.edu.cn> <4DAB099A.70303@joelhalpern.com> <4DAB3865.7090600@joelhalpern.com> <4DAB8386.7040707@stevecrocker.com> From: Jamal Hadi Salim Date: Sun, 17 Apr 2011 20:30:51 -0400 Message-ID: To: "Joel M. Halpern" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Joel M. Halpern" , Chuanhuang Li , wmwang@zjgsu.edu.cn, forces Subject: Re: [forces] BasicMetadataDispatch WAS(Re: LFB LPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 00:31:12 -0000 On Sun, Apr 17, 2011 at 8:19 PM, Joel M. Halpern wr= ote: > I am not sur ehow the slide relates to the question. > Remember that the design is explicitly constrained.=A0 We do not currentl= y > support passing metadata between FEs.=A0 Therefore, there is no way to sa= y > 'send this to some other specified FE, and preserve this metadata > information for that FE.'=A0 Clearly, we can do so later, if we want to.= =A0 For > now, you can only specify the output port as understood by this FE. > > Note: That does not prohibit the CE from configuring the dispatch logic t= o > know that logical ports 1-100 are actually physical port A, which is an > inter-FE port.=A0 All sorts of games the CE can play under the covers. > ok. Does the metadata router as i had it describe to the intended use? cheers, jamal From wmwang2001@hotmail.com Mon Apr 18 06:36:01 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6D224E070E for ; Mon, 18 Apr 2011 06:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1N9oXJj4ccGT for ; Mon, 18 Apr 2011 06:36:00 -0700 (PDT) Received: from blu0-omc1-s35.blu0.hotmail.com (blu0-omc1-s35.blu0.hotmail.com [65.55.116.46]) by ietfc.amsl.com (Postfix) with ESMTP id CDD83E06AD for ; Mon, 18 Apr 2011 06:36:00 -0700 (PDT) Received: from BLU0-SMTP84 ([65.55.116.8]) by blu0-omc1-s35.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 18 Apr 2011 06:36:00 -0700 X-Originating-IP: [60.186.207.195] X-Originating-Email: [wmwang2001@hotmail.com] Message-ID: Received: from WmwangHome ([60.186.207.195]) by BLU0-SMTP84.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 18 Apr 2011 06:35:58 -0700 From: "Wang,Weiming" To: "Jamal Hadi Salim" , "Joel M. Halpern" References: <201104131847143284482@mail.zjgsu.edu.cn> <201104131925587965227@mail.zjgsu.edu.cn> <4DAB099A.70303@joelhalpern.com> <4DAB3865.7090600@joelhalpern.com> <4DAB8386.7040707@stevecrocker.com> Date: Mon, 18 Apr 2011 21:35:52 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" 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.6090 X-OriginalArrivalTime: 18 Apr 2011 13:35:59.0352 (UTC) FILETIME=[8D743F80:01CBFDCD] Cc: "Joel M. Halpern" , Chuanhuang Li , wmwang@zjgsu.edu.cn, forces Subject: Re: [forces] BasicMetadataDispatch WAS(Re: LFB LPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 13:36:01 -0000 SmFtYWwsIA0KDQpJIHRoaW5rIHRoZSB1c2Ugb2YgdGhlIG1ldGFkYXRhIGRpc3BhdGNoIGFzIHlv dSBwcmVzZW50ZWQgYnkgdGhlIHNsaWRlIGFyZSB3aGF0IHdlIGludGVuZGVkLg0KDQpXaGlsZSBz b21ldGhpbmcgSSBub3cgY2FuIG5vdCBmb2xsb3cgaXMgeW91ciBkZXNjcmlwdGlvbiBhcyBiZWxv dzogDQoNCuKXjyBFdGhlcmVuY2FwIHVzZXMgdGhlIGxvZ2ljYWwgcG9ydCBpZCBmcm9tIE5IIHRv IGxvb2t1cCBhIHRhYmxlIGFuZCByZXNvbHZlOg0KICAgU3JjTUFDLCBkc3RNQUMsIFZMQU4gKG9w dGlvbmFsKSBhbmQgYW4gb3V0cHV0IGxvZ2ljYWwgcG9ydA0K4pePIERzdG1hYyBhbmQgcG9ydCBt YXkgYmUgcmVzb2x2ZWQgYnkgQVJQIHVzaW5nIE5ISVAgKG91dCBvZiBzY29wZSkNCg0KV2hpY2gg aXMgYWN0dWFsbHkgZXhhY3RseSB3aGF0IHdlIGRvIGluIGN1cnJlbnQgdmVyc2lvbi4gIEFzIGEg cmVzdWx0LCB3aGF0IGlzIHRoZSB1c2Ugb2YgIE5IRW5jYXBJbmZvSW5kZXggYXMgd2UgYXJlIG5v dyBkaXNjdXNzaW5nIHJlY2VudGx5IGNvbnNpZGVyaW5nIHRoYXQgd2UndiB1c2VkIHRoZSBsb2dp Y2FsIHBvcnQgaWQgYXMgdGhlIGxvb2t1cCBpbmRleCBpbiBFdGhlcmVuY2FwPyANCg0KQW5vdGhl ciBwb2ludCB0aGF0IEkgY2FuIG5vdCBmb2xsb3cgeW91ciBkaXNjdXNzc2lvbiB3aXRoIEpvZWwg YW5kIENodWFuaHVhbmcgaXMsIHdoYXQgaXMgZXhhY3RseSB0aGUgbWVhbmluZyAiQVJQIGJlaW5n IG91dCBvZiBzY29wZSBvZiB0aGlzIGxpYnJhcnkiPyAgU2hhbGwgd2Ugbm90IGRlZmluZSB0aGUg QVJQIExGQiBvciBqdXN0IHdlIG5vdCBkZXNjcmliZSB0aGUgQVJQIGZ1bmN0aW9uIHRvdGFsbHkg aW4gdGhlIGxpYnJhcnkgZG9jdW1lbnQ/DQoNCnRoYW5rcywNCldlaW1pbmcNCg0KLS0tLS0gT3Jp Z2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJKYW1hbCBIYWRpIFNhbGltIiA8aGFkaUBtb2ph dGF0dS5jb20+DQoNCk9uIFN1biwgQXByIDE3LCAyMDExIGF0IDg6MTkgUE0sIEpvZWwgTS4gSGFs cGVybiA8am9lbEBzdGV2ZWNyb2NrZXIuY29tPiB3cm90ZToNCj4gSSBhbSBub3Qgc3VyIGVob3cg dGhlIHNsaWRlIHJlbGF0ZXMgdG8gdGhlIHF1ZXN0aW9uLg0KPiBSZW1lbWJlciB0aGF0IHRoZSBk ZXNpZ24gaXMgZXhwbGljaXRseSBjb25zdHJhaW5lZC4gV2UgZG8gbm90IGN1cnJlbnRseQ0KPiBz dXBwb3J0IHBhc3NpbmcgbWV0YWRhdGEgYmV0d2VlbiBGRXMuIFRoZXJlZm9yZSwgdGhlcmUgaXMg bm8gd2F5IHRvIHNheQ0KPiAnc2VuZCB0aGlzIHRvIHNvbWUgb3RoZXIgc3BlY2lmaWVkIEZFLCBh bmQgcHJlc2VydmUgdGhpcyBtZXRhZGF0YQ0KPiBpbmZvcm1hdGlvbiBmb3IgdGhhdCBGRS4nIENs ZWFybHksIHdlIGNhbiBkbyBzbyBsYXRlciwgaWYgd2Ugd2FudCB0by4gRm9yDQo+IG5vdywgeW91 IGNhbiBvbmx5IHNwZWNpZnkgdGhlIG91dHB1dCBwb3J0IGFzIHVuZGVyc3Rvb2QgYnkgdGhpcyBG RS4NCj4NCj4gTm90ZTogVGhhdCBkb2VzIG5vdCBwcm9oaWJpdCB0aGUgQ0UgZnJvbSBjb25maWd1 cmluZyB0aGUgZGlzcGF0Y2ggbG9naWMgdG8NCj4ga25vdyB0aGF0IGxvZ2ljYWwgcG9ydHMgMS0x MDAgYXJlIGFjdHVhbGx5IHBoeXNpY2FsIHBvcnQgQSwgd2hpY2ggaXMgYW4NCj4gaW50ZXItRkUg cG9ydC4gQWxsIHNvcnRzIG9mIGdhbWVzIHRoZSBDRSBjYW4gcGxheSB1bmRlciB0aGUgY292ZXJz Lg0KPg0KDQpvay4NCkRvZXMgdGhlIG1ldGFkYXRhIHJvdXRlciBhcyBpIGhhZCBpdCBkZXNjcmli ZSB0byB0aGUgaW50ZW5kZWQgdXNlPw0KDQpjaGVlcnMsDQpqYW1hbA== From jmh@joelhalpern.com Mon Apr 18 06:42:30 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 30219E0755 for ; Mon, 18 Apr 2011 06:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.937 X-Spam-Level: X-Spam-Status: No, score=-101.937 tagged_above=-999 required=5 tests=[AWL=-0.538, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_47=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vm7hPUBGyIW3 for ; Mon, 18 Apr 2011 06:42:29 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes.out.tigertech.net [74.114.88.72]) by ietfc.amsl.com (Postfix) with ESMTP id 1B799E070E for ; Mon, 18 Apr 2011 06:42:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id CEBCB4300EC; Mon, 18 Apr 2011 06:42:27 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-50-206.clppva.btas.verizon.net [71.161.50.206]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id 9BB6D4300E1; Mon, 18 Apr 2011 06:42:26 -0700 (PDT) Message-ID: <4DAC3FBD.3030906@joelhalpern.com> Date: Mon, 18 Apr 2011 09:42:21 -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: "Wang,Weiming" References: <201104131847143284482@mail.zjgsu.edu.cn> <201104131925587965227@mail.zjgsu.edu.cn> <4DAB099A.70303@joelhalpern.com> <4DAB3865.7090600@joelhalpern.com> <4DAB8386.7040707@stevecrocker.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: forces , Chuanhuang Li , wmwang@zjgsu.edu.cn Subject: Re: [forces] BasicMetadataDispatch WAS(Re: LFB LPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 13:42:30 -0000 The logical output port is not enough information to select the dst mac. There is NOT a separate logical output port per neighbor. We had be using the next-hop IP address, whcih has several limitations. Therefore, we use a new table index metadatum instead. Yours, Joel On 4/18/2011 9:35 AM, Wang,Weiming wrote: > Jamal, > > I think the use of the metadata dispatch as you presented by the slide are what we intended. > > While something I now can not follow is your description as below: > > ● Etherencap uses the logical port id from NH to lookup a table and resolve: > SrcMAC, dstMAC, VLAN (optional) and an output logical port > ● Dstmac and port may be resolved by ARP using NHIP (out of scope) > > Which is actually exactly what we do in current version. As a result, what is the use of NHEncapInfoIndex as we are now discussing recently considering that we'v used the logical port id as the lookup index in Etherencap? > > Another point that I can not follow your discusssion with Joel and Chuanhuang is, what is exactly the meaning "ARP being out of scope of this library"? Shall we not define the ARP LFB or just we not describe the ARP function totally in the library document? > > thanks, > Weiming > > ----- Original Message ----- > From: "Jamal Hadi Salim" > > On Sun, Apr 17, 2011 at 8:19 PM, Joel M. Halpern wrote: >> I am not sur ehow the slide relates to the question. >> Remember that the design is explicitly constrained. We do not currently >> support passing metadata between FEs. Therefore, there is no way to say >> 'send this to some other specified FE, and preserve this metadata >> information for that FE.' Clearly, we can do so later, if we want to. For >> now, you can only specify the output port as understood by this FE. >> >> Note: That does not prohibit the CE from configuring the dispatch logic to >> know that logical ports 1-100 are actually physical port A, which is an >> inter-FE port. All sorts of games the CE can play under the covers. >> > > ok. > Does the metadata router as i had it describe to the intended use? > > cheers, > jamal From hadi@mojatatu.com Mon Apr 18 07:24:47 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 826BFE07E1 for ; Mon, 18 Apr 2011 07:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.275 X-Spam-Level: X-Spam-Status: No, score=-101.275 tagged_above=-999 required=5 tests=[AWL=-0.498, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_21=0.6, J_CHICKENPOX_47=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vpdZ7tsyOIVu for ; Mon, 18 Apr 2011 07:24:46 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfc.amsl.com (Postfix) with ESMTP id DB6ABE07E0 for ; Mon, 18 Apr 2011 07:24:46 -0700 (PDT) Received: by vxg33 with SMTP id 33so4441612vxg.31 for ; Mon, 18 Apr 2011 07:24:46 -0700 (PDT) Received: by 10.220.128.17 with SMTP id i17mr1383380vcs.182.1303136686219; Mon, 18 Apr 2011 07:24:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.185.193 with HTTP; Mon, 18 Apr 2011 07:24:26 -0700 (PDT) In-Reply-To: <4DAC3FBD.3030906@joelhalpern.com> References: <201104131847143284482@mail.zjgsu.edu.cn> <201104131925587965227@mail.zjgsu.edu.cn> <4DAB099A.70303@joelhalpern.com> <4DAB3865.7090600@joelhalpern.com> <4DAB8386.7040707@stevecrocker.com> <4DAC3FBD.3030906@joelhalpern.com> From: Jamal Hadi Salim Date: Mon, 18 Apr 2011 10:24:26 -0400 Message-ID: To: "Joel M. Halpern" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: forces , Chuanhuang Li , wmwang@zjgsu.edu.cn Subject: Re: [forces] BasicMetadataDispatch WAS(Re: LFB LPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 14:24:47 -0000 To followup on Joel: Yes, I meant "some index to be used for lookup". I find it confusing sometimes with the term "logical port id " because the term "port" could be used to mean both an LFB port as well as a port that is eventually going over some media. Which is the correct meaning of "logical port id " ? Weiming: I didnt want to revisit the discussion with Chuanhuang yet; i just wanted to settle on the big picture then we could go into details. So if what i described is sufficient we could go into the details cheers, jamal On Mon, Apr 18, 2011 at 9:42 AM, Joel M. Halpern wrot= e: > The logical output port is not enough information to select the dst mac. > =C2=A0There is NOT a separate logical output port per neighbor. =C2=A0We = had be using > the next-hop IP address, whcih has several limitations. Therefore, we use= a > new table index metadatum instead. > > Yours, > Joel > > On 4/18/2011 9:35 AM, Wang,Weiming wrote: >> >> Jamal, >> >> I think the use of the metadata dispatch as you presented by the slide a= re >> what we intended. >> >> While something I now can not follow is your description as below: >> >> =E2=97=8F Etherencap uses the logical port id from NH to lookup a table = and >> resolve: >> =C2=A0 =C2=A0SrcMAC, dstMAC, VLAN (optional) and an output logical port >> =E2=97=8F Dstmac and port may be resolved by ARP using NHIP (out of scop= e) >> >> Which is actually exactly what we do in current version. =C2=A0As a resu= lt, >> what is the use of =C2=A0NHEncapInfoIndex as we are now discussing recen= tly >> considering that we'v used the logical port id as the lookup index in >> Etherencap? >> >> Another point that I can not follow your discusssion with Joel and >> Chuanhuang is, what is exactly the meaning "ARP being out of scope of th= is >> library"? =C2=A0Shall we not define the ARP LFB or just we not describe = the ARP >> function totally in the library document? >> >> thanks, >> Weiming >> >> ----- Original Message ----- >> From: "Jamal Hadi Salim" >> >> On Sun, Apr 17, 2011 at 8:19 PM, Joel M. Halpern >> =C2=A0wrote: >>> >>> I am not sur ehow the slide relates to the question. >>> Remember that the design is explicitly constrained. We do not currently >>> support passing metadata between FEs. Therefore, there is no way to say >>> 'send this to some other specified FE, and preserve this metadata >>> information for that FE.' Clearly, we can do so later, if we want to. F= or >>> now, you can only specify the output port as understood by this FE. >>> >>> Note: That does not prohibit the CE from configuring the dispatch logic >>> to >>> know that logical ports 1-100 are actually physical port A, which is an >>> inter-FE port. All sorts of games the CE can play under the covers. >>> >> >> ok. >> Does the metadata router as i had it describe to the intended use? >> >> cheers, >> jamal > From jmh@joelhalpern.com Mon Apr 18 07:31:54 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 493BAE07EC for ; Mon, 18 Apr 2011 07:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.904 X-Spam-Level: X-Spam-Status: No, score=-101.904 tagged_above=-999 required=5 tests=[AWL=-0.505, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_47=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id atnofaZhb7jh for ; Mon, 18 Apr 2011 07:31:53 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes.out.tigertech.net [74.114.88.72]) by ietfc.amsl.com (Postfix) with ESMTP id D1806E077A for ; Mon, 18 Apr 2011 07:31:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2EA664300F5; Mon, 18 Apr 2011 07:31:52 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-50-206.clppva.btas.verizon.net [71.161.50.206]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id DD5B743002C; Mon, 18 Apr 2011 07:31:50 -0700 (PDT) Message-ID: <4DAC4B51.8070908@joelhalpern.com> Date: Mon, 18 Apr 2011 10:31:45 -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: <201104131847143284482@mail.zjgsu.edu.cn> <201104131925587965227@mail.zjgsu.edu.cn> <4DAB099A.70303@joelhalpern.com> <4DAB3865.7090600@joelhalpern.com> <4DAB8386.7040707@stevecrocker.com> <4DAC3FBD.3030906@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: forces , Chuanhuang Li , wmwang@zjgsu.edu.cn Subject: Re: [forces] BasicMetadataDispatch WAS(Re: LFB LPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 14:31:54 -0000 We have noted repeatedly that using port for the connections between LFBs was probably a mistake. But we could not find a better term. Which is why I try to remember to refer to the piece of port information produced as an output metadatum by the NH LFB as an "L3 logical port ID", i.e. it represents the single or bridged collection of physical / VLAN exits from the FE. Yours, Joel On 4/18/2011 10:24 AM, Jamal Hadi Salim wrote: > To followup on Joel: > > Yes, I meant "some index to be used for lookup". > I find it confusing sometimes with the term "logical port id " because > the term "port" could be used to mean both an LFB port as well > as a port that is eventually going over some media. > Which is the correct meaning of "logical port id " ? > > Weiming: I didnt want to revisit the discussion with Chuanhuang yet; > i just wanted to settle on the big picture then we could go into details. > So if what i described is sufficient we could go into the details > > cheers, > jamal > On Mon, Apr 18, 2011 at 9:42 AM, Joel M. Halpern wrote: >> The logical output port is not enough information to select the dst mac. >> There is NOT a separate logical output port per neighbor. We had be using >> the next-hop IP address, whcih has several limitations. Therefore, we use a >> new table index metadatum instead. >> >> Yours, >> Joel >> >> On 4/18/2011 9:35 AM, Wang,Weiming wrote: >>> >>> Jamal, >>> >>> I think the use of the metadata dispatch as you presented by the slide are >>> what we intended. >>> >>> While something I now can not follow is your description as below: >>> >>> ● Etherencap uses the logical port id from NH to lookup a table and >>> resolve: >>> SrcMAC, dstMAC, VLAN (optional) and an output logical port >>> ● Dstmac and port may be resolved by ARP using NHIP (out of scope) >>> >>> Which is actually exactly what we do in current version. As a result, >>> what is the use of NHEncapInfoIndex as we are now discussing recently >>> considering that we'v used the logical port id as the lookup index in >>> Etherencap? >>> >>> Another point that I can not follow your discusssion with Joel and >>> Chuanhuang is, what is exactly the meaning "ARP being out of scope of this >>> library"? Shall we not define the ARP LFB or just we not describe the ARP >>> function totally in the library document? >>> >>> thanks, >>> Weiming >>> >>> ----- Original Message ----- >>> From: "Jamal Hadi Salim" >>> >>> On Sun, Apr 17, 2011 at 8:19 PM, Joel M. Halpern >>> wrote: >>>> >>>> I am not sur ehow the slide relates to the question. >>>> Remember that the design is explicitly constrained. We do not currently >>>> support passing metadata between FEs. Therefore, there is no way to say >>>> 'send this to some other specified FE, and preserve this metadata >>>> information for that FE.' Clearly, we can do so later, if we want to. For >>>> now, you can only specify the output port as understood by this FE. >>>> >>>> Note: That does not prohibit the CE from configuring the dispatch logic >>>> to >>>> know that logical ports 1-100 are actually physical port A, which is an >>>> inter-FE port. All sorts of games the CE can play under the covers. >>>> >>> >>> ok. >>> Does the metadata router as i had it describe to the intended use? >>> >>> cheers, >>> jamal >> > From hadi@mojatatu.com Mon Apr 18 07:38:35 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 61AE5E0774 for ; Mon, 18 Apr 2011 07:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.261 X-Spam-Level: X-Spam-Status: No, score=-101.261 tagged_above=-999 required=5 tests=[AWL=-0.484, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_21=0.6, J_CHICKENPOX_47=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lStOWZo74hqs for ; Mon, 18 Apr 2011 07:38:34 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfc.amsl.com (Postfix) with ESMTP id 9D077E06D9 for ; Mon, 18 Apr 2011 07:38:34 -0700 (PDT) Received: by vxg33 with SMTP id 33so4455385vxg.31 for ; Mon, 18 Apr 2011 07:38:34 -0700 (PDT) Received: by 10.52.176.134 with SMTP id ci6mr721095vdc.190.1303137514195; Mon, 18 Apr 2011 07:38:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.185.193 with HTTP; Mon, 18 Apr 2011 07:38:14 -0700 (PDT) In-Reply-To: <4DAC4B51.8070908@joelhalpern.com> References: <201104131847143284482@mail.zjgsu.edu.cn> <201104131925587965227@mail.zjgsu.edu.cn> <4DAB099A.70303@joelhalpern.com> <4DAB3865.7090600@joelhalpern.com> <4DAB8386.7040707@stevecrocker.com> <4DAC3FBD.3030906@joelhalpern.com> <4DAC4B51.8070908@joelhalpern.com> From: Jamal Hadi Salim Date: Mon, 18 Apr 2011 10:38:14 -0400 Message-ID: To: "Joel M. Halpern" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: forces , Chuanhuang Li , wmwang@zjgsu.edu.cn Subject: Re: [forces] BasicMetadataDispatch WAS(Re: LFB LPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 14:38:35 -0000 It would be useful if we fixed this doc to prefix the port with "LFB" when that is what it is meant (readers of this document will be the type that understand port to mean media-port). cheers, jamal On Mon, Apr 18, 2011 at 10:31 AM, Joel M. Halpern wro= te: > We have noted repeatedly that using port for the connections between LFBs > was probably a mistake. =C2=A0But we could not find a better term. > > Which is why I try to remember to refer to the piece of port information > produced as an output metadatum by the NH LFB as an "L3 logical port ID", > i.e. it represents the single or bridged collection of physical / VLAN ex= its > from the FE. > > Yours, > Joel > > On 4/18/2011 10:24 AM, Jamal Hadi Salim wrote: >> >> To followup on Joel: >> >> Yes, I meant "some index to be used for lookup". >> I find it confusing sometimes with the term =C2=A0"logical port id " =C2= =A0because >> the term "port" could be used to mean both an LFB port as well >> as a port that is eventually going over some media. >> Which is the correct meaning of =C2=A0"logical port id " ? >> >> Weiming: I didnt want to revisit the discussion with Chuanhuang yet; >> i just wanted to settle on the big picture then we could go into details= . >> So if what i described is sufficient we could go into the details >> >> cheers, >> jamal >> On Mon, Apr 18, 2011 at 9:42 AM, Joel M. Halpern >> =C2=A0wrote: >>> >>> The logical output port is not enough information to select the dst mac= . >>> =C2=A0There is NOT a separate logical output port per neighbor. =C2=A0W= e had be >>> using >>> the next-hop IP address, whcih has several limitations. Therefore, we u= se >>> a >>> new table index metadatum instead. >>> >>> Yours, >>> Joel >>> >>> On 4/18/2011 9:35 AM, Wang,Weiming wrote: >>>> >>>> Jamal, >>>> >>>> I think the use of the metadata dispatch as you presented by the slide >>>> are >>>> what we intended. >>>> >>>> While something I now can not follow is your description as below: >>>> >>>> =E2=97=8F Etherencap uses the logical port id from NH to lookup a tabl= e and >>>> resolve: >>>> =C2=A0 =C2=A0SrcMAC, dstMAC, VLAN (optional) and an output logical por= t >>>> =E2=97=8F Dstmac and port may be resolved by ARP using NHIP (out of sc= ope) >>>> >>>> Which is actually exactly what we do in current version. =C2=A0As a re= sult, >>>> what is the use of =C2=A0NHEncapInfoIndex as we are now discussing rec= ently >>>> considering that we'v used the logical port id as the lookup index in >>>> Etherencap? >>>> >>>> Another point that I can not follow your discusssion with Joel and >>>> Chuanhuang is, what is exactly the meaning "ARP being out of scope of >>>> this >>>> library"? =C2=A0Shall we not define the ARP LFB or just we not describ= e the >>>> ARP >>>> function totally in the library document? >>>> >>>> thanks, >>>> Weiming >>>> >>>> ----- Original Message ----- >>>> From: "Jamal Hadi Salim" >>>> >>>> On Sun, Apr 17, 2011 at 8:19 PM, Joel M. Halpern >>>> =C2=A0wrote: >>>>> >>>>> I am not sur ehow the slide relates to the question. >>>>> Remember that the design is explicitly constrained. We do not current= ly >>>>> support passing metadata between FEs. Therefore, there is no way to s= ay >>>>> 'send this to some other specified FE, and preserve this metadata >>>>> information for that FE.' Clearly, we can do so later, if we want to. >>>>> For >>>>> now, you can only specify the output port as understood by this FE. >>>>> >>>>> Note: That does not prohibit the CE from configuring the dispatch log= ic >>>>> to >>>>> know that logical ports 1-100 are actually physical port A, which is = an >>>>> inter-FE port. All sorts of games the CE can play under the covers. >>>>> >>>> >>>> ok. >>>> Does the metadata router as i had it describe to the intended use? >>>> >>>> cheers, >>>> jamal >>> >> > From wmwang2001@hotmail.com Mon Apr 18 20:07:05 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 02AE5E071D for ; Mon, 18 Apr 2011 20:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.281 X-Spam-Level: X-Spam-Status: No, score=0.281 tagged_above=-999 required=5 tests=[AWL=1.680, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_47=0.6] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 58zkQCMMAv8i for ; Mon, 18 Apr 2011 20:07:00 -0700 (PDT) Received: from blu0-omc2-s21.blu0.hotmail.com (blu0-omc2-s21.blu0.hotmail.com [65.55.111.96]) by ietfc.amsl.com (Postfix) with ESMTP id 48633E06A0 for ; Mon, 18 Apr 2011 20:06:57 -0700 (PDT) Received: from BLU0-SMTP105 ([65.55.111.71]) by blu0-omc2-s21.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 18 Apr 2011 20:06:57 -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-SMTP105.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 18 Apr 2011 20:06:55 -0700 From: "Wang,Weiming" To: "Wang,Weiming" , "Jamal Hadi Salim" , "Joel M. Halpern" References: <201104131847143284482@mail.zjgsu.edu.cn> <201104131925587965227@mail.zjgsu.edu.cn> <4DAB099A.70303@joelhalpern.com> <4DAB3865.7090600@joelhalpern.com> <4DAB8386.7040707@stevecrocker.com> <4DAC3FBD.3030906@joelhalpern.com> <175201685E034B1999A365234861B8D9@ZJGSUIEE> Date: Tue, 19 Apr 2011 11:06:51 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" 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: 19 Apr 2011 03:06:56.0080 (UTC) FILETIME=[D71FBD00:01CBFE3E] Cc: forces , Chuanhuang Li Subject: Re: [forces] BasicMetadataDispatch WAS(Re: LFB LPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 03:07:05 -0000 SmFtYWwgYW5kIGFsbCwNCiANCiBCeSBmb2xsb3dpbmcgcmVjZW50IGRpc2N1c3Npb25zLCBJIGFu ZCBDaHVhbmh1YW5nIGFyZSBhIGxpdHRsZSBib3RoZXJlZCBieSB0aGUgc3RhdHVzIHRoYXQgaXQg aXMgaGFyZCBmb3IgYm90aCB1cyB0byBhbGxvY2F0ZSB0aGUgZGlzY3Vzc2lvbnMgIGludG8gc3Bl Y2lmaWMgZGVmaW5pdGlvbnMgb2YgcmVsYXRlZCBMRkJzLCBhbHRob3VnaCBzb21lIG5ldyB0aG91 Z2h0cyBoYXZlIGJlZW4gcHJlc2VudGVkLCBpLmUuLCBzb21lIHRob3VnaHRzIGFyZSBzdGlsbCB0 b28gdmFndWUgdG8gYmUgcmVmbGVjdGVkIGluIHRoZSBtb2RpZmljYXRpb24gb2YgTEZCIGRlZmlu aXRpb25zLg0KIA0KIENodWFuaHVhbmcgaGF2ZSBwcm9wc2VkIGEgbW9kaWZpY2F0aW9uIG9uIHRo ZSBtb2RpZmljYXRpb24gb2YgTkggYW5kIEV0aGVyZW5jYXAgTEZCcyBpbiBtZXNzYWdlIG9mIA0K IFNlbnQ6IFRodXJzZGF5LCBBcHJpbCAxNCwgMjAxMSAxMDo0MyBQTQ0KIFN1YmplY3Q6IFJlOiBb Zm9yY2VzXSBMRkIgTFBNIGlzc3VlDQogDQogSSBkbyBob3BlIHRvIGdldCByZXBseSBmcm9tIHRo aXMgbW9kaWZpY2F0aW9ucywgb3IgcGxzIGp1c3QgcHJlc2VudCB5b3VyIG1vZGlmaWNhdGlvbnMg b2YgdGhlIGRpZmluaXRpb25zIGFzIHdlbGwgYXMgeW91ciB0aG91Z2h0cy4NCiANCiB0aGFua3Ms DQpXZWltaW5nDQoNCj4gDQo+IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQo+IEZyb206 ICJKYW1hbCBIYWRpIFNhbGltIiA8aGFkaUBtb2phdGF0dS5jb20+DQo+IA0KPiBUbyBmb2xsb3d1 cCBvbiBKb2VsOg0KPiANCj4gWWVzLCBJIG1lYW50ICJzb21lIGluZGV4IHRvIGJlIHVzZWQgZm9y IGxvb2t1cCIuDQo+IEkgZmluZCBpdCBjb25mdXNpbmcgc29tZXRpbWVzIHdpdGggdGhlIHRlcm0g ICJsb2dpY2FsIHBvcnQgaWQgIiAgYmVjYXVzZQ0KPiB0aGUgdGVybSAicG9ydCIgY291bGQgYmUg dXNlZCB0byBtZWFuIGJvdGggYW4gTEZCIHBvcnQgYXMgd2VsbA0KPiBhcyBhIHBvcnQgdGhhdCBp cyBldmVudHVhbGx5IGdvaW5nIG92ZXIgc29tZSBtZWRpYS4NCj4gV2hpY2ggaXMgdGhlIGNvcnJl Y3QgbWVhbmluZyBvZiAgImxvZ2ljYWwgcG9ydCBpZCAiID8NCj4gDQo+IFdlaW1pbmc6IEkgZGlk bnQgd2FudCB0byByZXZpc2l0IHRoZSBkaXNjdXNzaW9uIHdpdGggQ2h1YW5odWFuZyB5ZXQ7DQo+ IGkganVzdCB3YW50ZWQgdG8gc2V0dGxlIG9uIHRoZSBiaWcgcGljdHVyZSB0aGVuIHdlIGNvdWxk IGdvIGludG8gZGV0YWlscy4NCj4gU28gaWYgd2hhdCBpIGRlc2NyaWJlZCBpcyBzdWZmaWNpZW50 IHdlIGNvdWxkIGdvIGludG8gdGhlIGRldGFpbHMNCj4gDQo+IGNoZWVycywNCj4gamFtYWwNCj4g T24gTW9uLCBBcHIgMTgsIDIwMTEgYXQgOTo0MiBBTSwgSm9lbCBNLiBIYWxwZXJuIDxqbWhAam9l bGhhbHBlcm4uY29tPiB3cm90ZToNCj4+IFRoZSBsb2dpY2FsIG91dHB1dCBwb3J0IGlzIG5vdCBl bm91Z2ggaW5mb3JtYXRpb24gdG8gc2VsZWN0IHRoZSBkc3QgbWFjLg0KPj4gVGhlcmUgaXMgTk9U IGEgc2VwYXJhdGUgbG9naWNhbCBvdXRwdXQgcG9ydCBwZXIgbmVpZ2hib3IuIFdlIGhhZCBiZSB1 c2luZw0KPj4gdGhlIG5leHQtaG9wIElQIGFkZHJlc3MsIHdoY2loIGhhcyBzZXZlcmFsIGxpbWl0 YXRpb25zLiBUaGVyZWZvcmUsIHdlIHVzZSBhDQo+PiBuZXcgdGFibGUgaW5kZXggbWV0YWRhdHVt IGluc3RlYWQuDQo+Pg0KPj4gWW91cnMsDQo+PiBKb2VsDQo+Pg0KPj4gT24gNC8xOC8yMDExIDk6 MzUgQU0sIFdhbmcsV2VpbWluZyB3cm90ZToNCj4+Pg0KPj4+IEphbWFsLA0KPj4+DQo+Pj4gSSB0 aGluayB0aGUgdXNlIG9mIHRoZSBtZXRhZGF0YSBkaXNwYXRjaCBhcyB5b3UgcHJlc2VudGVkIGJ5 IHRoZSBzbGlkZSBhcmUNCj4+PiB3aGF0IHdlIGludGVuZGVkLg0KPj4+DQo+Pj4gV2hpbGUgc29t ZXRoaW5nIEkgbm93IGNhbiBub3QgZm9sbG93IGlzIHlvdXIgZGVzY3JpcHRpb24gYXMgYmVsb3c6 DQo+Pj4NCj4+PiDil48gRXRoZXJlbmNhcCB1c2VzIHRoZSBsb2dpY2FsIHBvcnQgaWQgZnJvbSBO SCB0byBsb29rdXAgYSB0YWJsZSBhbmQNCj4+PiByZXNvbHZlOg0KPj4+IFNyY01BQywgZHN0TUFD LCBWTEFOIChvcHRpb25hbCkgYW5kIGFuIG91dHB1dCBsb2dpY2FsIHBvcnQNCj4+PiDil48gRHN0 bWFjIGFuZCBwb3J0IG1heSBiZSByZXNvbHZlZCBieSBBUlAgdXNpbmcgTkhJUCAob3V0IG9mIHNj b3BlKQ0KPj4+DQo+Pj4gV2hpY2ggaXMgYWN0dWFsbHkgZXhhY3RseSB3aGF0IHdlIGRvIGluIGN1 cnJlbnQgdmVyc2lvbi4gQXMgYSByZXN1bHQsDQo+Pj4gd2hhdCBpcyB0aGUgdXNlIG9mIE5IRW5j YXBJbmZvSW5kZXggYXMgd2UgYXJlIG5vdyBkaXNjdXNzaW5nIHJlY2VudGx5DQo+Pj4gY29uc2lk ZXJpbmcgdGhhdCB3ZSd2IHVzZWQgdGhlIGxvZ2ljYWwgcG9ydCBpZCBhcyB0aGUgbG9va3VwIGlu ZGV4IGluDQo+Pj4gRXRoZXJlbmNhcD8NCj4+Pg0KPj4+IEFub3RoZXIgcG9pbnQgdGhhdCBJIGNh biBub3QgZm9sbG93IHlvdXIgZGlzY3Vzc3Npb24gd2l0aCBKb2VsIGFuZA0KPj4+IENodWFuaHVh bmcgaXMsIHdoYXQgaXMgZXhhY3RseSB0aGUgbWVhbmluZyAiQVJQIGJlaW5nIG91dCBvZiBzY29w ZSBvZiB0aGlzDQo+Pj4gbGlicmFyeSI/IFNoYWxsIHdlIG5vdCBkZWZpbmUgdGhlIEFSUCBMRkIg b3IganVzdCB3ZSBub3QgZGVzY3JpYmUgdGhlIEFSUA0KPj4+IGZ1bmN0aW9uIHRvdGFsbHkgaW4g dGhlIGxpYnJhcnkgZG9jdW1lbnQ/DQo+Pj4NCj4+PiB0aGFua3MsDQo+Pj4gV2VpbWluZw0KPj4+ DQo+Pj4gLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KPj4+IEZyb206ICJKYW1hbCBIYWRp IFNhbGltIjxoYWRpQG1vamF0YXR1LmNvbT4NCj4+Pg0KPj4+IE9uIFN1biwgQXByIDE3LCAyMDEx IGF0IDg6MTkgUE0sIEpvZWwgTS4gSGFscGVybjxqb2VsQHN0ZXZlY3JvY2tlci5jb20+DQo+Pj4g d3JvdGU6DQo+Pj4+DQo+Pj4+IEkgYW0gbm90IHN1ciBlaG93IHRoZSBzbGlkZSByZWxhdGVzIHRv IHRoZSBxdWVzdGlvbi4NCj4+Pj4gUmVtZW1iZXIgdGhhdCB0aGUgZGVzaWduIGlzIGV4cGxpY2l0 bHkgY29uc3RyYWluZWQuIFdlIGRvIG5vdCBjdXJyZW50bHkNCj4+Pj4gc3VwcG9ydCBwYXNzaW5n IG1ldGFkYXRhIGJldHdlZW4gRkVzLiBUaGVyZWZvcmUsIHRoZXJlIGlzIG5vIHdheSB0byBzYXkN Cj4+Pj4gJ3NlbmQgdGhpcyB0byBzb21lIG90aGVyIHNwZWNpZmllZCBGRSwgYW5kIHByZXNlcnZl IHRoaXMgbWV0YWRhdGENCj4+Pj4gaW5mb3JtYXRpb24gZm9yIHRoYXQgRkUuJyBDbGVhcmx5LCB3 ZSBjYW4gZG8gc28gbGF0ZXIsIGlmIHdlIHdhbnQgdG8uIEZvcg0KPj4+PiBub3csIHlvdSBjYW4g b25seSBzcGVjaWZ5IHRoZSBvdXRwdXQgcG9ydCBhcyB1bmRlcnN0b29kIGJ5IHRoaXMgRkUuDQo+ Pj4+DQo+Pj4+IE5vdGU6IFRoYXQgZG9lcyBub3QgcHJvaGliaXQgdGhlIENFIGZyb20gY29uZmln dXJpbmcgdGhlIGRpc3BhdGNoIGxvZ2ljDQo+Pj4+IHRvDQo+Pj4+IGtub3cgdGhhdCBsb2dpY2Fs IHBvcnRzIDEtMTAwIGFyZSBhY3R1YWxseSBwaHlzaWNhbCBwb3J0IEEsIHdoaWNoIGlzIGFuDQo+ Pj4+IGludGVyLUZFIHBvcnQuIEFsbCBzb3J0cyBvZiBnYW1lcyB0aGUgQ0UgY2FuIHBsYXkgdW5k ZXIgdGhlIGNvdmVycy4NCj4+Pj4NCj4+Pg0KPj4+IG9rLg0KPj4+IERvZXMgdGhlIG1ldGFkYXRh IHJvdXRlciBhcyBpIGhhZCBpdCBkZXNjcmliZSB0byB0aGUgaW50ZW5kZWQgdXNlPw0KPj4+DQo+ Pj4gY2hlZXJzLA0KPj4+IGphbWFsDQo+Pg== From hadi@mojatatu.com Tue Apr 19 05:51:55 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 66D12E0663 for ; Tue, 19 Apr 2011 05:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.747 X-Spam-Level: X-Spam-Status: No, score=-101.747 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_21=0.6, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e+Rwli5Pm7ZU for ; Tue, 19 Apr 2011 05:51:54 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id A1D63E065A for ; Tue, 19 Apr 2011 05:51:54 -0700 (PDT) Received: by vws12 with SMTP id 12so5341887vws.31 for ; Tue, 19 Apr 2011 05:51:54 -0700 (PDT) Received: by 10.220.128.17 with SMTP id i17mr1707726vcs.182.1303217514161; Tue, 19 Apr 2011 05:51:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.185.193 with HTTP; Tue, 19 Apr 2011 05:51:34 -0700 (PDT) In-Reply-To: <175201685E034B1999A365234861B8D9@ZJGSUIEE> References: <201104131847143284482@mail.zjgsu.edu.cn> <201104131925587965227@mail.zjgsu.edu.cn> <4DAB099A.70303@joelhalpern.com> <4DAB3865.7090600@joelhalpern.com> <4DAB8386.7040707@stevecrocker.com> <4DAC3FBD.3030906@joelhalpern.com> <175201685E034B1999A365234861B8D9@ZJGSUIEE> From: Jamal Hadi Salim Date: Tue, 19 Apr 2011 08:51:34 -0400 Message-ID: To: "Wang,Weiming" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "Joel M. Halpern" , Chuanhuang Li , wmwang@zjgsu.edu.cn, forces Subject: Re: [forces] BasicMetadataDispatch WAS(Re: LFB LPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 12:51:55 -0000 Weiming, I will do writeup to summarize things hopefully by end of today my time now that we seem to all agree on the big picture at least. cheers, jamal On Mon, Apr 18, 2011 at 11:04 PM, Wang,Weiming w= rote: > Jamal and all, > > By following recent discussions, I and Chuanhuang are a little bothered b= y the status that it is hard for both us to allocate the discussions =C2=A0= into specific definitions of related LFBs, although some new thoughts have = been presented, i.e., some thoughts are still too vague to be reflected in = the modification of LFB definitions. > > Chuanhuang have propsed a modification on the modification of NH and Ethe= rencap LFBs in message of > Sent: Thursday, April 14, 2011 10:43 PM > Subject: Re: [forces] LFB LPM issue > > I do hope to get reply from this modifications, or pls just present your = modifications of the difinitions as well as your thoughts. > > thanks, > Weiming > > ----- Original Message ----- > From: "Jamal Hadi Salim" > > To followup on Joel: > > Yes, I meant "some index to be used for lookup". > I find it confusing sometimes with the term =C2=A0"logical port id " =C2= =A0because > the term "port" could be used to mean both an LFB port as well > as a port that is eventually going over some media. > Which is the correct meaning of =C2=A0"logical port id " ? > > Weiming: I didnt want to revisit the discussion with Chuanhuang yet; > i just wanted to settle on the big picture then we could go into details. > So if what i described is sufficient we could go into the details > > cheers, > jamal > On Mon, Apr 18, 2011 at 9:42 AM, Joel M. Halpern wr= ote: >> The logical output port is not enough information to select the dst mac. >> There is NOT a separate logical output port per neighbor. We had be usin= g >> the next-hop IP address, whcih has several limitations. Therefore, we us= e a >> new table index metadatum instead. >> >> Yours, >> Joel >> >> On 4/18/2011 9:35 AM, Wang,Weiming wrote: >>> >>> Jamal, >>> >>> I think the use of the metadata dispatch as you presented by the slide = are >>> what we intended. >>> >>> While something I now can not follow is your description as below: >>> >>> =E2=97=8F Etherencap uses the logical port id from NH to lookup a table= and >>> resolve: >>> SrcMAC, dstMAC, VLAN (optional) and an output logical port >>> =E2=97=8F Dstmac and port may be resolved by ARP using NHIP (out of sco= pe) >>> >>> Which is actually exactly what we do in current version. As a result, >>> what is the use of NHEncapInfoIndex as we are now discussing recently >>> considering that we'v used the logical port id as the lookup index in >>> Etherencap? >>> >>> Another point that I can not follow your discusssion with Joel and >>> Chuanhuang is, what is exactly the meaning "ARP being out of scope of t= his >>> library"? Shall we not define the ARP LFB or just we not describe the A= RP >>> function totally in the library document? >>> >>> thanks, >>> Weiming >>> >>> ----- Original Message ----- >>> From: "Jamal Hadi Salim" >>> >>> On Sun, Apr 17, 2011 at 8:19 PM, Joel M. Halpern >>> wrote: >>>> >>>> I am not sur ehow the slide relates to the question. >>>> Remember that the design is explicitly constrained. We do not currentl= y >>>> support passing metadata between FEs. Therefore, there is no way to sa= y >>>> 'send this to some other specified FE, and preserve this metadata >>>> information for that FE.' Clearly, we can do so later, if we want to. = For >>>> now, you can only specify the output port as understood by this FE. >>>> >>>> Note: That does not prohibit the CE from configuring the dispatch logi= c >>>> to >>>> know that logical ports 1-100 are actually physical port A, which is a= n >>>> inter-FE port. All sorts of games the CE can play under the covers. >>>> >>> >>> ok. >>> Does the metadata router as i had it describe to the intended use? >>> >>> cheers, >>> jamal >> From hadi@mojatatu.com Thu Apr 21 05:08:33 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id BA565E06DA for ; Thu, 21 Apr 2011 05:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.348 X-Spam-Level: X-Spam-Status: No, score=-102.348 tagged_above=-999 required=5 tests=[AWL=0.629, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GcUIB50n9e1E for ; Thu, 21 Apr 2011 05:08:33 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id E0D0DE0698 for ; Thu, 21 Apr 2011 05:08:32 -0700 (PDT) Received: by vws12 with SMTP id 12so1562773vws.31 for ; Thu, 21 Apr 2011 05:08:32 -0700 (PDT) Received: by 10.220.181.66 with SMTP id bx2mr2379356vcb.147.1303387712388; Thu, 21 Apr 2011 05:08:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.185.193 with HTTP; Thu, 21 Apr 2011 05:08:12 -0700 (PDT) From: Jamal Hadi Salim Date: Thu, 21 Apr 2011 08:08:12 -0400 Message-ID: To: "Wang,Weiming" Content-Type: multipart/mixed; boundary=90e6ba53a9129a00a504a16c99ea Cc: "Joel M. Halpern" , Chuanhuang Li , wmwang@zjgsu.edu.cn, forces Subject: [forces] NH review WAS(Re: BasicMetadataDispatch WAS(Re: LFB LPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 12:08:33 -0000 --90e6ba53a9129a00a504a16c99ea Content-Type: text/plain; charset=ISO-8859-1 On Tue, Apr 19, 2011 at 8:51 AM, Jamal Hadi Salim wrote: > Weiming, > > I will do writeup to summarize things hopefully by end of today my time > now that we seem to all agree on the big picture at least. > Sorry - busyed-out by unexpected chaos, so i didnt get around to this as promised. I was hoping to do both NH and EtherEncap but instead of waiting for completion of both, here's a write up of NH suggestions. When i get time next I will do Etherencap. cheers, jamal --90e6ba53a9129a00a504a16c99ea Content-Type: text/plain; charset=US-ASCII; name="NH-suggested.txt" Content-Disposition: attachment; filename="NH-suggested.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gmrnbxch0 CkdlbmVyYWwKPT09PT09PQoxKSBXZSBuZWVkIHRvIGJlIGNvbnNpc3RlbnQgYW5kIGFjdHVhbGx5 IGRlZmluZSByaWdodCBhdCB0aGUgCmJlZ2luaW5nIHdoYXQgInVwc3RyZWFtIiBhbmQgImRvd25z dHJlYW0iIExGQiBtZWFucy4KSW4gbXkgdmlldyBiZWxvdywgYnkgZG93bnN0cmVhbSBJIG1lYW4g d2hlcmUgdGhlIHBhY2tldCBmbG93IGlzCmdvaW5nLgoKMikgR2VuZXJhbCBxdWVzdGlvbjoKPG91 dHB1dFBvcnQgZ3JvdXA9InRydWUiPiBhcyBpbmRpY2F0ZWQgaW4gdGhlIE5IIExGQjoKd2hlbiBp biBnZW5lcmFsIGRvZXMgaXQgbWFrZSBzZW5zZSB0byBoYXZlIGl0IGFzICJ0cnVlIiB2cyAiZmFs c2UiCmFuZCB3aGVyZSBpcyB0aGlzIGRlc2NyaWJlZD8KCgpMRkI6IElQdlhOZXh0SG9wCj09PT09 PT09PT09PT09PT0KCjEpSSBkb250IHRoaW5rIE5leHRob3BJRCAoY29tcG9uZW50SUQ9IjEiKSBz aG91bGQgYmUgcGFydCBvZiB0aGUgdGFibGUuClRoZSBwYXNzZWQgTmV4dGhvcElEIGlzIGFuIF9p bmRleF8gaW50byB0aGUgTmV4dEhvcFRhYmxlIGFuZCBkb2VzIG5vdApuZWVkIHRvIGJlIHBhcnQg b2YgdGhlIHRhYmxlLgoKMilSZW5hbWluZyBPdXRwdXRMb2dpY2FsUG9ydElEIHRvIE91dHB1dExv Z2ljYWxQb3J0SW5kZXggZm9yIHJlYWRhYmlsaXR5LgoKCSAgICA8Y29tcG9uZW50IGNvbXBvbmVu dElEPSIxPyI+CiAgICAgICAgICAgICAgICA8bmFtZT5PdXRwdXRMb2dpY2FsUG9ydEluZGV4PC9u YW1lPgogICAgICAgICAgICAgICAgPHN5bm9wc2lzPlRoZSBpbmRleCBvZiB0aGUgTG9naWNhbCBP dXRwdXRQb3J0CiAgICAgICAgICAgICAgICAgICAgICAgICAgdGhhdCB3ZSBwYXNzIG9udG8gdGhl IG5laWdoYm9yaW5nIExGQiBpbnN0YW5jZS4KICAgICAgICAgICAgICAgICAgICAgICAgICBUaGlz IGluZGV4IGlzIHVzZWQgdG8gbG9va3VwIGEgdGFibGUgCiAgICAgICAgICAgICAgICAgICAgICAg ICAgZnVydGhlciBkb3duc3RyZWFtLgogICAgICAgICAgICAgICAgPC9zeW5vcHNpcz4KICAgICAg ICAgICAgICAgIDx0eXBlUmVmPnVpbnQzMjwvdHlwZVJlZj4KICAgICAgICAgICAgIDwvY29tcG9u ZW50PgoKCjMpUmVuYW1pbmcgRW5jYXBPdXRwdXRJbmRleCB0byBMRkJPdXRwdXRTZWxlY3RJbmRl eCB0byBpbmRpY2F0ZQp3aGljaCBMRkIgcG9ydCB3ZSBhcmUgc2VsZWN0aW5nIHRvIGdvIHRvIHRo ZSBkb3duc3RyZWFtIExGQiBpbnN0YW5jZS4KCiAgICAgICAgICAgICA8Y29tcG9uZW50IGNvbXBv bmVudElEPSI/Ij4KICAgICAgICAgICAgICAgIDxuYW1lPkxGQk91dHB1dFNlbGVjdEluZGV4PC9u YW1lPgogICAgICAgICAgICAgICAgPHN5bm9wc2lzPkxGQiBHcm91cCBvdXRwdXQgcG9ydCBpbmRl eCB0byBzZWxlY3QKICAgICAgICAgICAgICAgICAgICAgICAgICBkb3duc3RyZWFtIExGQiBwb3J0 LiBTb21lIHBvc3NpYmlsaXRpZXMKICAgICAgICAgICAgICAgICAgICAgICAgICBvZiBkb3duc3Ry ZWFtIExGQiBpbnN0YW5jZXMgYXJlOgoJCQkgIGEpIEV0aGVyRW5jYXBzdWxhdG9yCgkJCSAgYikg QSBtZXRhZGF0YSBEaXNwYXRjaGVyCgkJCSAgVHlwaWNhbGx5LCB0aGVyZSB3aWxsIGJlIG9ubHkg b25lIExGQiBwb3J0CiAgICAgICAgICAgICAgICA8L3N5bm9wc2lzPgogICAgICAgICAgICAgICAg PHR5cGVSZWY+dWludDMyPC90eXBlUmVmPgogICAgICAgICAgICAgPC9jb21wb25lbnQ+Cgo0KURl ZmluZSBhIHNjaGVtZSB0byBpbmRpY2F0ZSB0aGF0IEV0aGVyRW5jYXAgZGV0YWlscyBhcmUgdW5y ZXNvbHZlZCAKYXQgdGhpcyBwb2ludC4gTWV0aG9kcyB0aGF0IGhhdmUgYmVlbiBkaXNjdXNzZWQg c28gZmFyOgoKYSlDRSBzZXRzIE91dHB1dExvZ2ljYWxQb3J0SW5kZXggcG9ydCB0byBhIHZhbHVl IHRoYXQgaXMgbm90IGFsbG9jYXRlZAppbiBFdGhlckVuY2FwIEVuY2FwVGFibGUuIEV0aGVyRW5j YXAgbG9va3VwIHdpbGwgZmFpbCB0byBmaW5kIGl0LgpXaGljaCBpcyBpbmRpY2F0aW9uIHNvbWUg b3RoZXIgd2F5IHRvIHJlc29sdmUgaXQgbWF5IGJlIG5lZWRlZC4KCmIpIGVsZW1lbnQgbmFtZWQg c3VjaCBhcyAiRmlsbEZsYWciIHRvIGluZGljYXRlIHdoZXRoZXIgdGhlIHRhYmxlIAplbnRyeSBo YWQgYmVlbiBmaWxsZWQuIEJ1dCB0aGVuIHdlIG5lZWQgdG8gcGFzcyB0aGlzIGluZm8gYXMgbWV0 YWRhdGEuCgo1KSBPdGhlciBjb21tZW50cyBhYm91dCBJUHZ4TmV4dEhvcDoKCmEpTWF4T3V0cHV0 UG9ydHMgLSB3aGF0IGlzIHRoZSBzZW1hbnRpY3Mgb2YgdGhhdCBnaXZlbiB0aGF0IHdlCm9ubHkg aGF2ZSBvbmUgIlN1Y2Nlc3NPdXQiIExGQiBwb3J0PwpJYW0gYXNzdW1pbmcgb25lICJTdWNjZXNz T3V0IiBMRkIgcG9ydCBidXQgbWFueSBkaWZmZXJlbnQgdmFsdWVzCmluIExGQk91dHB1dFNlbGVj dEluZGV4IHdoaWNoIGFyZSBwYXNzZWQgdG8gdGhlIGVpdGhlciBFdGhlckVuY2FwCm9yIEJhc2lj TWV0YWRhdGFEaXNwYXRjaCB0byBtYWtlIGZ1cnRoZXIgZGVjaXNpb24uCkNhbiB5b3UgcGxlYXNl IGRvdWJsZSBjaGVjayB0aGlzPyBpdCBuZWVkcyB0byBnbyBpbiB0aGUgdGV4dC4KCmIpIGNhbiB3 ZSBjaGFuZ2UgImZvciBhcHBsaWNhdGluZyBuZXh0IGhvcCBhY3Rpb24iIAp0byBzb21ldGhpbmcg bGlrZSAiZm9yIHNlbGVjdGluZyBuZXh0IGhvcCBhY3Rpb24iCgpEYXRhIEhhbmRsaW5nCi0tLS0t LS0tLS0tLS0KCkluY29taW5nIE5leHRob3BpZCBtZXRhZGF0YSBpcyB1c2VkIGFzIGFuIGluZGV4 IHRvIGxvb2t1cCB0aGUgdGFibGUuCkRhdGEgcHJvY2Vzc2luZyBpbnZvbHZlcyB0aGUgZm9yd2Fy ZGluZyBUVEwgZGVjcmVtZW50IGFuZCBjaGVja3N1bSAKcmVjYWxjdWxhdGlvbi4gT24gc3VjY2Vz c2Z1bCBkYXRhIHByb2Nlc3NpbmcgdGhlIHBhY2tldCBpcyBzZW50IG91dAp0aGUgIlN1Y2Nlc3NP dXQiIExGQiBwb3J0IHRvIGEgZG93bnN0cmVhbSBMRkIgaW5zdGFuY2UgYWxvbmdzaWRlIAp0d28g bmV3IG1ldGFkYXRhOiBUaGUgTEZCT3V0cHV0U2VsZWN0SW5kZXggYW5kIE91dHB1dExvZ2ljYWxQ b3J0SW5kZXguCklmIGRhdGEgcHJvY2Vzc2luZyBmYWlscywgdGhlIHBhY2tldCBpcyBzZW50IG91 dCBvbiB0aGUgImV4Y2VwdGlvbiIgCm91dHB1dCBhbG9uZyB3aXRoIGFuIGFkZGl0aW9uYWwgZXhj ZXB0aW9uSUQgbWV0YWRhdGEuCgpEb3duc3RyZWFtIG5laWdoYm9yaW5nIExGQiBpbnN0YW5jZXMg Y291bGQgYmUgZWl0aGVyIGFuIEV0aGVyRW5jYXAgCnR5cGUgb3IgYSBCYXNpY01ldGFkYXRhRGlz cGF0Y2ggdHlwZS4KCkp1c3RpZmljYXRpb24gZm9yIGNob2ljZSBvZiBkb3duc3RyZWFtIExGQiBp bnN0YW5jZQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT0KCkluIHNjZW5hcmlvcyB3aGVyZSB0aGUgZmluYWwgcGFja2V0IEwyIHByb2Nlc3NpbmcgaXMg cG9zc2libGUgdG8gCmJlIG9uIHBlci1tZWRpYS1wb3J0IGJhc2lzIG9yIG9uIGEgZGlmZmVyZW50 IEZFIHRoZSBtb2RlbCBtYWtlcyBzZW5zZQp0byB1c2UgYSBCYXNpY01ldGFkYXRhRGlzcGF0Y2gg TEZCIHRvIGZhbm91dCB0byBkaWZmZXJlbnQgTEZCIGluc3RhbmNlcy4KKHJlZmVyIHRvIGZpZ3Vy ZSBYWFggd2hpY2ggc2hvd3MgaG93IHRoaXMgd291bGQgd29yaykuCkluIHNjZW5hcmlvcyB3aGVy ZSB0aGVyZSBpcyBhIGNlbnRyYWxpemVkIEwyIGhlYWRlciBlbmNhcHN1bGF0aW9uCnBvaW50LCB0 aGVuIHRoZSBtb2RlbCBtYWtlcyBzZW5zZSB0byBoYXZlIGEgZG93bnN0cmVhbSBMRkIgaW5zdGFu Y2UKYmUgYW4gRXRoZXJFbmNhcCAoYXMgZGVtb25zdHJhdGVkIGluIEZpZ3VyZSAxKS4KWFhYOiBF eHBsYWluIGluIHN1bW1hcnkgaG93IHRoZSBMRkJPdXRwdXRTZWxlY3RJbmRleCBhbmQgCk91dHB1 dExvZ2ljYWxQb3J0SW5kZXggYXJlIHVzZWQgaW4gYm90aCBMRkJzLgpYWFg6IHRleHQgaGVyZSB0 byBkZXNjcmliZSB0aGUgZGlmZmVyZW50IGV4Y2VwdGlvbnMgdGhhdCBjb3VsZAoK --90e6ba53a9129a00a504a16c99ea-- From hadi@mojatatu.com Thu Apr 21 11:13:55 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D5628E06C9 for ; Thu, 21 Apr 2011 11:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.765 X-Spam-Level: X-Spam-Status: No, score=-101.765 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_37=0.6, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCp0dpuzJT9F for ; Thu, 21 Apr 2011 11:13:55 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id 03A8AE06A0 for ; Thu, 21 Apr 2011 11:13:54 -0700 (PDT) Received: by vws12 with SMTP id 12so1840481vws.31 for ; Thu, 21 Apr 2011 11:13:54 -0700 (PDT) Received: by 10.220.181.66 with SMTP id bx2mr68813vcb.147.1303409634495; Thu, 21 Apr 2011 11:13:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.185.193 with HTTP; Thu, 21 Apr 2011 11:13:34 -0700 (PDT) From: Jamal Hadi Salim Date: Thu, 21 Apr 2011 14:13:34 -0400 Message-ID: To: "Wang,Weiming" Content-Type: multipart/mixed; boundary=90e6ba53a91242cecb04a171b4d8 Cc: "Joel M. Halpern" , Chuanhuang Li , wmwang@zjgsu.edu.cn, forces Subject: [forces] EtherEncap review WAS(Re: BasicMetadataDispatch WAS(Re: LFB LPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 18:13:56 -0000 --90e6ba53a91242cecb04a171b4d8 Content-Type: text/plain; charset=ISO-8859-1 EtherEncap summary attached. cheers, jamal On Thu, Apr 21, 2011 at 8:08 AM, Jamal Hadi Salim wrote: > I was hoping to do both NH and EtherEncap but instead of waiting for > completion of both, here's a write up of NH suggestions. > When i get time next I will do Etherencap. --90e6ba53a91242cecb04a171b4d8 Content-Type: text/plain; charset=US-ASCII; name="ee-suggested.txt" Content-Disposition: attachment; filename="ee-suggested.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gms0ep2g1 CkxGQjogRXRoZXJFbmNhcAo9PT09PT09PT09PT09PT0KCjApIE5vdGUgZGlzYXBwZWFyYW5jZSBv ZiBBUlAvTkQgZnJvbSB0aGlzIGRyYWZ0LiBBbHNvCm5vdGUgdGhpcyBMRkIgaXMgYWdub3N0aWMg b2YgSVBWNCBvciBJUHY2LgoKMSkgRml4IDxtZXRhZGF0YUV4cGVjdGVkPiB0byBsb29rIGZvciBP dXRwdXRMb2dpY2FsUG9ydEluZGV4CihhcyBwYXNzZWQgZnJvbSBOSCkgaW5zdGVhZCBvZiBMb2dp Y2FsUG9ydElEIGFuZCBub3RlIHRoYXQKaXQgaXMgbm90IG9wdGlvbmFsLgoKMikgV2UgaGF2ZSBh biBhbHRlcm5hdGl2ZSB0YWJsZSBrbm93biBhcyBFbmNhcFRhYmxlIHdoaWNoIGlzIHZlcnkgY2xv c2UgdG8KQXJwVGFibGUvTmJyVGFibGUuIFdlIG9ubHkgbmVlZCBvbmUgdGFibGUgZm9yIGJvdGgg SVBWNCBhbmQgSVBWNi4KU28gYXNzdW1lIGFzIGEgc3RhcnRpbmcgcG9pbnQgb25lIG9mIHRoZXNl LgoKaSAgKSBJIGRvbnQgdGhpbmsgTG9naWNhbFBvcnRJRCAoY29tcG9uZW50SUQ9IjEiKSBzaG91 bGQgYmUgcGFydCBvZiB0aGUgCnRhYmxlLgpUaGUgcGFzc2VkIE91dHB1dExvZ2ljYWxQb3J0SW5k ZXggaXMgYW4gX2luZGV4XyBpbnRvIHRoZSBFbmNhcFRhYmxlIAphbmQgdGhlcmVmb3JlIGRvZXMg bm90IG5lZWQgdG8gYmUgcGFydCBvZiB0aGUgdGFibGUuCgppaSApIERzdElQdnhBZGRyZXNzIGlz IG5ldmVyIHVzZWQgaW4gdGhpcyBMRkIuCgppaWkpIFdlIG1lcmdlIHRoZSBWTEFOIG91dHB1dCB0 YWJsZSBpbnRvIEVuY2FwVGFibGUuCgp0aGUgdGFibGUgZW50cnkgbG9va3MgbGlrZToKCiAgICAg ICA8ZGF0YVR5cGVEZWY+CiAgICAgICAgICA8bmFtZT5FbmNhcFRhYmxlVHlwZTwvbmFtZT4KICAg ICAgICAgIDxzeW5vcHNpcz5FdGhlcm5ldCBFbmNhcHN1bGF0aW9uIHRhYmxlIGVudHJ5IHR5cGUu PC9zeW5vcHNpcz4KICAgICAgICAgIDxzdHJ1Y3Q+CiAgICAgICAgICAgICA8Y29tcG9uZW50IGNv bXBvbmVudElEPSIxIj4KICAgICAgICAgICAgICAgIDxuYW1lPkRzdE1hYzwvbmFtZT4KICAgICAg ICAgICAgICAgIDxzeW5vcHNpcz5FdGhlcm5ldCBNYWMgb2YgdGhlIE5laWdoYm9yPC9zeW5vcHNp cz4KICAgICAgICAgICAgICAgIDx0eXBlUmVmPklFRUVNQUM8L3R5cGVSZWY+CiAgICAgICAgICAg ICA8L2NvbXBvbmVudD4KICAgICAgICAgICAgIDxjb21wb25lbnQgY29tcG9uZW50SUQ9IjIiPgog ICAgICAgICAgICAgICAgPG5hbWU+U3JjTWFjPC9uYW1lPgogICAgICAgICAgICAgICAgPHN5bm9w c2lzPlNvdXJjZSBNQUMgdXNlZCBpbiBlbmNhcHN1bGF0aW9uPC9zeW5vcHNpcz4KICAgICAgICAg ICAgICAgIDx0eXBlUmVmPklFRUVNQUM8L3R5cGVSZWY+CiAgICAgICAgICAgICA8L2NvbXBvbmVu dD4KICAgICAgICAgICAgIDxjb21wb25lbnQgY29tcG9uZW50SUQ9IjMiPgogICAgICAgICAgICAg ICAgPG5hbWU+VmxhbklEPC9uYW1lPgogICAgICAgICAgICAgICAgPHN5bm9wc2lzPlZMQU4gSUQu PC9zeW5vcHNpcz4KICAgICAgICAgICAgICAgIDx0eXBlUmVmPnVpbnQzMjwvdHlwZVJlZj4KICAg ICAgICAgICAgIDwvY29tcG9uZW50PgogICAgICAgICAgICAgPGNvbXBvbmVudCBjb21wb25lbnRJ RD0iNCI+CiAgICAgICAgICAgICAgICA8bmFtZT5PdXRwdXRMb2dpY2FsUG9ydElEPC9uYW1lPgog ICAgICAgICAgICAgICAgPHN5bm9wc2lzPk91dHB1dCBsb2dpY2FsIHBvcnQgSUQuPC9zeW5vcHNp cz4KICAgICAgICAgICAgICAgIDx0eXBlUmVmPnVpbnQzMjwvdHlwZVJlZj4KICAgICAgICAgICAg IDwvY29tcG9uZW50PgogICAgICAgICAgPC9zdHJ1Y3Q+CiAgICAgICA8L2RhdGFUeXBlRGVmPgoK ClhYWDogVGhlIFZsYW5JRCB0eXBlIGxvb2tzIHdyb25nLiBCdXQgSSBqdXN0IGNvcGllZCB0aGlz IGZyb20gdGhlIGN1cnJlbnQKdGV4dApYWFg6IFdlIGFyZSBtZXJnaW5nIHRoZSBzb3VyY2UgYW5k IGRlc3RpbmF0aW9uIGluZm9ybWF0aW9uIG9uIHRoZQpzYW1lIHRhYmxlIChzb21lIGltcGxlbWVu dGF0aW9ucyBtYXkgaGF2ZSB0aGVtIGluIHNlcGFyYXRlIHRhYmxlcykuCldlIGFyZSBhc3N1bWlu ZyB0aGUgbWVyZ2VkIHZlcnNpb24gcHJvdmlkZXMgYSBnZW5lcmFsIHZpZXcuLi4KCgpEYXRhIEhh bmRsaW5nCi0tLS0tLS0tLS0tLS0KUGFja2V0cyBhbG9uZ3NpZGUgbWV0YWRhdGEgYXJlIHJlY2Vp dmVkIG9uIHRoaXMgTEZCIHZpYSB0aGUKIkVuY2FwSW4iIGlucHV0IExGQi4gVGhlIHVwc3RyZWFt IExGQiBjbGFzc2VzIG1heWJlIHRoZSBkaWZmZXJlbnQgCk5leHRIb3AgTEZCcyBzdWNoIGFzIElQ djROZXh0SG9wIGFuZCBJUHY2TmV4dEhvcCBvciBtYXliZSAKQmFzaWNNZXRhZGF0YURpc3BhdGNo IG9yIGV2ZW4gTDIgYnJpZGdpbmcgKHdoaWNoIGlzIG91dCBvZiBzY29wZSBpbiAKdGhpcyBkb2N1 bWVudCkuCkluIHRoZSBjYXNlIG9mIGlucHV0IGJlaW5nIGZyb20gYW55IG9mIHRoZSBOZXh0SG9w IExGQiBjbGFzc2VzLAp0aGUgTmV4dGhvcElQdjRBZGRyIG9yIE5leHRob3BJUHY2QWRkciBpcyBw YXNzZWQgaW4gYXMgbWV0YWRhdGEKdG8gdGhpcyBMRkIuIApYWFg6IElmIEwyIGJyaWRpbmcgaXMg aW5wdXR0aW5nIHBhY2tldHMgLSB3aGVyZSBkb2VzIHRoZSBJUCBhZGRyZXNzCmNvbWUgZnJvbT8K QWRkaXRpb25hbGx5LCBPdXRwdXRMb2dpY2FsUG9ydEluZGV4IGlzIGFsc28gcGFzc2VkIGJ5IHVw c3RyZWFtCkxGQiBpbnN0YW5jZXMuCgpUaGUgbWV0YWRhdGEgT3V0cHV0TG9naWNhbFBvcnRJbmRl eCBpcyB1c2VkIGFzIGFuIGluZGV4IHRvIGxvb2t1cCAKdGhlIEVuY2FwIFRhYmxlLgpVcG9uIGEg c3VjY2Vzc2Z1bCB0YWJsZSBsb29rdXAsIHRoZSBkZXN0aW5hdGlvbiBhbmQgc291cmNlIE1BQyBh ZGRyZXNzZXMsCmFuZCB0aGUgbG9naWNhbCBtZWRpYSBwb3J0IChPdXRwdXRMb2dpY2FsUG9ydElE KSBhcmUgZm91bmQgaW4gdGhlIG1hdGNoaW5nCnRhYmxlIGVudHJ5LiBUaGUgQ0UgbWF5IHNldCB0 aGUgVmxhbklkIGluIGNhc2UgVkxBTnMgYXJlIHVzZWQuCkJ5IGRlZmF1bHQgdGhlIHRhYmxlIGVu dHJ5IGZvciBWTEFOSUQgb2YgMCBpcyB1c2VkIGFzIHBlciBJRUVFIHJ1bGVzLgpYWFg6IEhvdyBp cyBMRkJPdXRwdXRTZWxlY3RJbmRleCB1c2VkIGluIHRoaXMgY2FzZT8KClhYWDogRGF0YSBwcm9j ZXNzaW5nIGludm9sdmVzIHJlcGxhY2luZyBvciBhdHRhY2hpbmcgdGhlIGFwcHJvcHJpYXRlCkV0 aGVybmV0IGhlYWRlcnMgdG8gdGhlIHBhY2tldC4KQWZ0ZXIgZGF0YSBwcm9jZXNzaW5nIGlzIGNv bXBsZXRlLCB0aGUgcGFja2V0IGlzIHBhc3NlZCBvdXQgb24gCnRoZSAiU3VjY2Vzc091dCIgTEZC IHBvcnQgdG8gYSBkb3duc3RyZWFtIExGQiBpbnN0YW5jZSBhbG9uZ3NpZGUgd2l0aCAKdGhlIE91 dHB1dExvZ2ljYWxQb3J0SUQuClhYWDogaXMgT3V0cHV0TG9naWNhbFBvcnRJbmRleCAoZnJvbSBO SCkgY29uc3VtZWQgaGVyZSBvciBzaG91bGQgd2UgCmJlIHVzaW5nIHRoZSB0ZXJtIE91dHB1dExv Z2ljYWxQb3J0SUQgZm9yIGJvdGg/CgpJdCBpcyBwb3NzaWJsZSBmb3IgdGhlIEVuY2FwVGFibGUg bG9va3VwIHRvIGZhaWwuIFRoZSBOSCBMRkIgbWF5IApiZSBwcm9ncmFtbWVkIGJ5IHRoZSBDRSB0 byBwYXNzIGFsb25nIGFuIE91dHB1dExvZ2ljYWxQb3J0SW5kZXgKdGhhdCBkb2VzbnQgZXhpc3Qg aW4gdGhlIEVuY2FwVGFibGUuIFRoZSByZWFzb24gZm9yIHRoaXMgaXMgdG8gYWxsb3cKZm9yIHJl c29sdXRpb24gb2YgdGhlIEwyIGhlYWRlcnMgdG8gYmUgbWFkZSBhdCB0aGUgTDIgZW5jYXBzdWxh dGlvbiBsZXZlbAppbiB0aGlzIGNhc2UoZXRoZXJuZXQpIHZpYSBBUlAsIG9yIE5EIChvciBvdGhl ciBtZXRob2RzIGRlcGVuZGluZyBvbiB0aGUgbGluayAKbGF5ZXIgdGVjaG5vbG9neSkgd2hlbiBh IHRhYmxlIG1pc3Mgb2NjdXJzLgpJZiB0YWJsZSBsb29rdXAgZmFpbHMsIHRoZSBwYWNrZXQgaXMg c2VudCBvdXQgb24gdGhlICJleGNlcHRpb24iIApvdXRwdXQgYWxvbmcgd2l0aCBhbiBhZGRpdGlv bmFsIGV4Y2VwdGlvbklEIG1ldGFkYXRhLgoKRm9yIG5laWdoYm9yIEwyIGhlYWRlciByZXNvbHV0 aW9uKHRhYmxlIG1pc3MgZXhjZXB0aW9uKSwgdGhlIHByb2Nlc3NpbmcgCkxGQiBtYXkgcGFzcyB0 aGlzIHBhY2tldCB0byB0aGUgQ0UgdmlhIHRoZSByZWRpcmVjdCBMRkIgb3IgRkUgc29mdHdhcmUg Cm9yIGFub3RoZXIgTEZCIGluc3RhbmNlIGZvciBmdXJ0aGVyIHJlc29sdXRpb24uIEluIHN1Y2gg YSBjYXNlIHRoZSBtZXRhZGF0YSAKbmV4dCBob3AgaXAgKHY0IG9yIHY2KSBpcyBhbHNvIHBhc3Nl ZCB0byB0aGUgZXhjZXB0aW9uIGhhbmRsaW5nLiBTdWNoIGFuIApJUCBhZGRyZXNzIGNvdWxkIGJl IHVzZWQgdG8gZG8gYWN0aXZpdGllcyBzdWNoIGFzIEFSUCBvciBORCBieSB0aGUgaGFuZGxlciAK aXQgaXMgcGFzc2VkIHRvLgpUaGUgcmVzdWx0IG9mIHRoZSBMMiByZXNvbHV0aW9uIGlzIHRvIHVw ZGF0ZSB0aGUgRW5jYXBUYWJsZSBhcyB3ZWxsCmFzIHRoZSBOSCBMRkIgc28gc3Vic2VxdWVudCBw YWNrZXRzIGRvbnQgZmFpbCBFbmNhcCB0YWJsZSBsb29rdXAuIApUaGUgRXRoZXJFbmNhcCBMRkIg ZG9lcyBub3QgbWFrZSBhbnkgYXNzdW1wdGlvbnMgb2YgaG93IHRoZSBFbmNhcFRhYmxlCmlzIHVw ZGF0ZWQgYnkgdGhlIENFIChvciB3aGV0aGVyIEFSUC9ORCBpcyB1c2VkIGR5bmFtaWNhbGx5IG9y CnN0YXRpYyBtYXBzIGV4aXN0KS4KCkRvd25zdHJlYW0gbmVpZ2hib3JpbmcgTEZCIGluc3RhbmNl cyBjb3VsZCBiZSBlaXRoZXIgYW4gRXRoZXJNQUNPdXQgCnR5cGUoc2hvd24gaW4gZmlndXJlIHh4 eCkgb3IgYSBCYXNpY01ldGFkYXRhRGlzcGF0Y2ggdHlwZSAoc2hvd24gCmluIEZpZ3VyZSAxKS4K Ckp1c3RpZmljYXRpb24gZm9yIGNob2ljZSBvZiBkb3duc3RyZWFtIExGQiBpbnN0YW5jZQo9PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KCkluIHNjZW5h cmlvcyB3aGVyZSB0aGUgZmluYWwgcGFja2V0IEwyIHByb2Nlc3NpbmcgaXMgcG9zc2libGUgdG8g CmJlIG9uIHBlci1tZWRpYS1wb3J0IGJhc2lzIG9yIHJlc2lkZXMgb24gYSBkaWZmZXJlbnQgRkUg b3IgaW4gY2FzZXMgd2hlcmUKTDIgaGVhZGVyIHJlc29sdXRpb24gaXMgbmVlZGVkLCB0aGVuIHRo ZSBtb2RlbCBtYWtlcyBzZW5zZSB0byB1c2UgYSAKQmFzaWNNZXRhZGF0YURpc3BhdGNoIExGQiB0 byBmYW5vdXQgdG8gZGlmZmVyZW50IExGQiBpbnN0YW5jZXMuCihyZWZlciB0byBmaWd1cmUgMSB3 aGljaCBzaG93cyBob3cgdGhpcyB3b3VsZCB3b3JrKS4KSW4gc2NlbmFyaW9zIHdoZXJlIHRoZXJl IGlzIGEgZGlyZWN0IGVncmVzcyBwb3J0IHBvaW50LCB0aGVuIHRoZSBtb2RlbCAKbWFrZXMgc2Vu c2UgdG8gaGF2ZSBhIGRvd25zdHJlYW0gTEZCIGluc3RhbmNlIGJlIGFuIEV0aGVyTUFDT3V0IChh cyAKZGVtb25zdHJhdGVkIGluIEZpZ3VyZSB4eHgpLgoKWFhYOiB0ZXh0IGhlcmUgdG8gZGVzY3Jp YmUgdGhlIGRpZmZlcmVudCBleGNlcHRpb25zIHRoYXQgY291bGQK --90e6ba53a91242cecb04a171b4d8-- From jmh@joelhalpern.com Thu Apr 21 11:22:19 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B42B3E07C7 for ; Thu, 21 Apr 2011 11:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.502 X-Spam-Level: X-Spam-Status: No, score=-102.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qkXmQ0-2R+EZ for ; Thu, 21 Apr 2011 11:22:19 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes.out.tigertech.net [74.114.88.72]) by ietfc.amsl.com (Postfix) with ESMTP id 37484E0717 for ; Thu, 21 Apr 2011 11:22:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 0025F4300FA; Thu, 21 Apr 2011 11:22:17 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-50-206.clppva.btas.verizon.net [71.161.50.206]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id D4EB34300E1; Thu, 21 Apr 2011 11:22:16 -0700 (PDT) Message-ID: <4DB075D7.8040606@joelhalpern.com> Date: Thu, 21 Apr 2011 14:22:15 -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: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: forces , Chuanhuang Li , wmwang@zjgsu.edu.cn Subject: Re: [forces] EtherEncap review WAS(Re: BasicMetadataDispatch WAS(Re: LFB LPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 18:22:19 -0000 One quick comment: Can we call the input metadata table index something other than a port ID. it has nothing to do with ports. SelectedMediaIndex maybe? Yours, Joel On 4/21/2011 2:13 PM, Jamal Hadi Salim wrote: > EtherEncap summary attached. > > cheers, > jamal > > On Thu, Apr 21, 2011 at 8:08 AM, Jamal Hadi Salim wrote: > >> I was hoping to do both NH and EtherEncap but instead of waiting for >> completion of both, here's a write up of NH suggestions. >> When i get time next I will do Etherencap. From hadi@mojatatu.com Thu Apr 21 11:41:14 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2F3E2E0837 for ; Thu, 21 Apr 2011 11:41:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.865 X-Spam-Level: X-Spam-Status: No, score=-101.865 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 75mBily51XZl for ; Thu, 21 Apr 2011 11:41:13 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfc.amsl.com (Postfix) with ESMTP id BC6B8E0831 for ; Thu, 21 Apr 2011 11:41:13 -0700 (PDT) Received: by vxg33 with SMTP id 33so10467vxg.31 for ; Thu, 21 Apr 2011 11:41:13 -0700 (PDT) Received: by 10.220.128.17 with SMTP id i17mr73841vcs.182.1303411273109; Thu, 21 Apr 2011 11:41:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.185.193 with HTTP; Thu, 21 Apr 2011 11:40:53 -0700 (PDT) In-Reply-To: <4DB075D7.8040606@joelhalpern.com> References: <4DB075D7.8040606@joelhalpern.com> From: Jamal Hadi Salim Date: Thu, 21 Apr 2011 14:40:53 -0400 Message-ID: To: "Joel M. Halpern" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: forces , Chuanhuang Li , wmwang@zjgsu.edu.cn Subject: Re: [forces] EtherEncap review WAS(Re: BasicMetadataDispatch WAS(Re: LFB LPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 18:41:14 -0000 I can make that change (i think you meant change OutputLogicalPortIndex to SelectedMediaIndex). Will wait to hear from the other folks. cheers, jamal On Thu, Apr 21, 2011 at 2:22 PM, Joel M. Halpern wrot= e: > One quick comment: > Can we call the input metadata table index something other than a port ID= . > =A0it has nothing to do with ports. =A0SelectedMediaIndex maybe? > > Yours, > Joel > > On 4/21/2011 2:13 PM, Jamal Hadi Salim wrote: >> >> EtherEncap summary attached. >> >> cheers, >> jamal >> >> On Thu, Apr 21, 2011 at 8:08 AM, Jamal Hadi Salim >> =A0wrote: >> >>> I was hoping to do both NH and EtherEncap but instead of waiting for >>> completion of both, here's a write up of NH suggestions. >>> When i get time next I will do Etherencap. > From chuanhuang_li@mail.zjgsu.edu.cn Thu Apr 21 21:55:14 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B242CE06D7 for ; Thu, 21 Apr 2011 21:55:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.892 X-Spam-Level: X-Spam-Status: No, score=-0.892 tagged_above=-999 required=5 tests=[AWL=1.707, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rkAh-X6vflp2 for ; Thu, 21 Apr 2011 21:55:13 -0700 (PDT) Received: from mail.zjgsu.edu.cn (ucmail.zjgsu.edu.cn [124.160.64.1]) by ietfc.amsl.com (Postfix) with SMTP id 3DD29E0792 for ; Thu, 21 Apr 2011 21:55:09 -0700 (PDT) Received: from RobinLee (unknown [10.20.0.167]) by mailportal (Coremail) with SMTP id rBCI85D7BDfTB7FNgIQeAA--.15881S2; Fri, 22 Apr 2011 12:45:07 +0800 (CST) Date: Fri, 22 Apr 2011 12:55:22 +0800 From: "Chuanhuang Li" To: "Jamal Hadi Salim" , "Wang,Weiming" Message-ID: <201104221255218779523@mail.zjgsu.edu.cn> Organization: Zhejiang Gongshang Univercity X-mailer: Foxmail 6, 15, 201, 23 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-CM-TRANSID: rBCI85D7BDfTB7FNgIQeAA--.15881S2 X-Coremail-Antispam: 1Uf129KBjDUn29KB7ZKAUJUUUUUYxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJ3UbIYCTnIWIevJa73UjIFyTuYvj4RJUUUUUUUU X-CM-SenderInfo: pfkxt0xkxd0wxbolqzhdloh6pmjv3hxhgxhubq/ Cc: "Joel M. Halpern" , wmwang , forces Subject: Re: [forces] NH review WAS(Re: BasicMetadataDispatch WAS(Re: LFB LPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 04:55:14 -0000 Hi, Jamal, Thanks! I have some comments. > 1)I dont think NexthopID (componentID="1") should be part of the table. > The passed NexthopID is an _index_ into the NextHopTable and does not > need to be part of the table. Chuanhuang: whether need we differentiate between the truly table index and the "index" which reflect the pointing relationship between two table? This maybe a common question. The so-called "truly table index" is just the internal order for building the table in an LFB. For example, there are two implementing methods for NH table in two different FE, they can place the same entry in different place(different truly table index), but the NexthopID is the same. This kind of definition can reduce some "hard" coordination between LFBs. > 2)Renaming OutputLogicalPortID to OutputLogicalPortIndex for readability. Chuanhuang: From previous discussion, the "OutputLogicalPortID" is exactly an L3 port ID, It isn't an index. It have physic meaning. This should be continue to have in the NH table. Maybe, do you want to add an element named "NHEncapInfoIndex" to the definition of NH table? > 3)Renaming EncapOutputIndex to LFBOutputSelectIndex to indicate > which LFB port we are selecting to go to the downstream LFB instance. Chuanhuang: I agree. > > LFBOutputSelectIndex > LFB Group output port index to select > downstream LFB port. Some possibilities > of downstream LFB instances are: > a) EtherEncapsulator > b) A metadata Dispatcher > Typically, there will be only one LFB port > > uint32 > Chuanhuang: There are not only two cases you have showed. The downstream LFB instance also can be redirectOut or other media encapsulator. > a)MaxOutputPorts - what is the semantics of that given that we > only have one "SuccessOut" LFB port? Chuanhuang: Capability "MaxOutputPorts" has been removed, please see the email: subject: port group time: 2010-12-22 Yours, Chuanhuang From jmh@joelhalpern.com Thu Apr 21 22:03:59 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 05D39E06C5 for ; Thu, 21 Apr 2011 22:03:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.507 X-Spam-Level: X-Spam-Status: No, score=-102.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NX59KoFYJa8O for ; Thu, 21 Apr 2011 22:03:58 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes.out.tigertech.net [74.114.88.72]) by ietfc.amsl.com (Postfix) with ESMTP id 3A845E064E for ; Thu, 21 Apr 2011 22:03:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 4BC564300E5; Thu, 21 Apr 2011 22:03:57 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-218.clppva.btas.verizon.net [71.161.51.218]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id 80F984300D5; Thu, 21 Apr 2011 22:03:55 -0700 (PDT) Message-ID: <4DB10C39.6030801@joelhalpern.com> Date: Fri, 22 Apr 2011 01:03:53 -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: Chuanhuang Li References: <201104221255218779523@mail.zjgsu.edu.cn> In-Reply-To: <201104221255218779523@mail.zjgsu.edu.cn> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: forces , wmwang Subject: Re: [forces] NH review WAS(Re: BasicMetadataDispatch WAS(Re: LFB LPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 05:03:59 -0000 Whether the FE gets to pi9ck the entry index for entries in a table depends upon how the CE creates the entries, and whether there is provision for the FE to autonomously create entries. For most tables, there is no autonomous creation, and the CE will select the index to use. Using the explicit index, rather than using a content value as a content-index, will generally be significantly more efficient. The tables we are discussing are ones where the CE will be creating entries. Also, note, these indices are used between LFBs in the same FE. We are not passing metadata between the FEs. (although it would still work then.) Yes, we need the L3 Logical Port ID metadata, and we need the mediaencaptable index. these are separate pieces of metadata. Yours, Joel On 4/22/2011 12:55 AM, Chuanhuang Li wrote: > Hi, Jamal, > Thanks! I have some comments. >> 1)I dont think NexthopID (componentID="1") should be part of the table. >> The passed NexthopID is an _index_ into the NextHopTable and does not >> need to be part of the table. > Chuanhuang: whether need we differentiate between the truly table index and > the "index" which reflect the pointing relationship between two table? This maybe > a common question. The so-called "truly table index" is just the internal order > for building the table in an LFB. For example, there are two implementing methods for > NH table in two different FE, they can place the same entry in different place(different > truly table index), but the NexthopID is the same. This kind of definition can reduce some > "hard" coordination between LFBs. > >> 2)Renaming OutputLogicalPortID to OutputLogicalPortIndex for readability. > Chuanhuang: From previous discussion, the "OutputLogicalPortID" is exactly an L3 port ID, > It isn't an index. It have physic meaning. This should be continue to have in the NH table. > Maybe, do you want to add an element named "NHEncapInfoIndex" to the definition of NH table? > >> 3)Renaming EncapOutputIndex to LFBOutputSelectIndex to indicate >> which LFB port we are selecting to go to the downstream LFB instance. > Chuanhuang: I agree. > >> >> LFBOutputSelectIndex >> LFB Group output port index to select >> downstream LFB port. Some possibilities >> of downstream LFB instances are: >> a) EtherEncapsulator >> b) A metadata Dispatcher >> Typically, there will be only one LFB port >> >> uint32 >> > Chuanhuang: There are not only two cases you have showed. The downstream > LFB instance also can be redirectOut or other media encapsulator. > >> a)MaxOutputPorts - what is the semantics of that given that we >> only have one "SuccessOut" LFB port? > Chuanhuang: Capability "MaxOutputPorts" has been removed, please see the email: > subject: port group > time: 2010-12-22 > > > Yours, > Chuanhuang > > > From chuanhuang_li@mail.zjgsu.edu.cn Thu Apr 21 23:38:28 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 367DDE0743 for ; Thu, 21 Apr 2011 23:38:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.136 X-Spam-Level: X-Spam-Status: No, score=-1.136 tagged_above=-999 required=5 tests=[AWL=1.463, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DxrXTszVGR-x for ; Thu, 21 Apr 2011 23:38:27 -0700 (PDT) Received: from mail.zjgsu.edu.cn (ucmail.zjgsu.edu.cn [124.160.64.1]) by ietfc.amsl.com (Postfix) with SMTP id E17C3E0693 for ; Thu, 21 Apr 2011 23:38:23 -0700 (PDT) Received: from RobinLee (unknown [10.20.0.167]) by mailportal (Coremail) with SMTP id rBCI85D7cTsDILFNgIQeAA--.16055S2; Fri, 22 Apr 2011 14:28:20 +0800 (CST) Date: Fri, 22 Apr 2011 14:38:35 +0800 From: "Chuanhuang Li" To: "Joel M. Halpern" References: <201104221255218779523@mail.zjgsu.edu.cn> Message-ID: <201104221438353777658@mail.zjgsu.edu.cn> Organization: Zhejiang Gongshang Univercity X-mailer: Foxmail 6, 15, 201, 23 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-CM-TRANSID: rBCI85D7cTsDILFNgIQeAA--.16055S2 X-Coremail-Antispam: 1Uf129KBjDUn29KB7ZKAUJUUUUUYxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJ3UbIYCTnIWIevJa73UjIFyTuYvj4RJUUUUUUUU X-CM-SenderInfo: pfkxt0xkxd0wxbolqzhdloh6pmjv3hxhgxhubq/ Cc: forces , wmwang Subject: Re: [forces] NH review WAS(Re: BasicMetadataDispatch WAS(Re: LFBLPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 06:38:28 -0000 Hi,Joel Yes, it will be more efficient if using the explicit index between LFBs in the same FE. But, CE need manage the unified routing tables for all FEs. If CE create an entry, all FEs with differnet implementing ways need to create the same table index. This hard coupling may constrain user's implementation. From CE point, loose coupling between LFBs may be helpful to his manager. From FE point, FE can implement the table more flexible. >Whether the FE gets to pi9ck the entry index for entries in a table >depends upon how the CE creates the entries, and whether there is >provision for the FE to autonomously create entries. >For most tables, there is no autonomous creation, and the CE will select >the index to use. Using the explicit index, rather than using a content >value as a content-index, will generally be significantly more efficient. >The tables we are discussing are ones where the CE will be creating entries. > >Also, note, these indices are used between LFBs in the same FE. We are >not passing metadata between the FEs. (although it would still work then.) >Yes, we need the L3 Logical Port ID metadata, and we need the >mediaencaptable index. these are separate pieces of metadata. > >Yours, >Joel > > >On 4/22/2011 12:55 AM, Chuanhuang Li wrote: >> Hi, Jamal, >> Thanks! I have some comments. >>> 1)I dont think NexthopID (componentID="1") should be part of the table. >>> The passed NexthopID is an _index_ into the NextHopTable and does not >>> need to be part of the table. >> Chuanhuang: whether need we differentiate between the truly table index and >> the "index" which reflect the pointing relationship between two table? This maybe >> a common question. The so-called "truly table index" is just the internal order >> for building the table in an LFB. For example, there are two implementing methods for >> NH table in two different FE, they can place the same entry in different place(different >> truly table index), but the NexthopID is the same. This kind of definition can reduce some >> "hard" coordination between LFBs. >> >>> 2)Renaming OutputLogicalPortID to OutputLogicalPortIndex for readability. >> Chuanhuang: From previous discussion, the "OutputLogicalPortID" is exactly an L3 port ID, >> It isn't an index. It have physic meaning. This should be continue to have in the NH table. >> Maybe, do you want to add an element named "NHEncapInfoIndex" to the definition of NH table? >> >>> 3)Renaming EncapOutputIndex to LFBOutputSelectIndex to indicate >>> which LFB port we are selecting to go to the downstream LFB instance. >> Chuanhuang: I agree. >> >>> >>> LFBOutputSelectIndex >>> LFB Group output port index to select >>> downstream LFB port. Some possibilities >>> of downstream LFB instances are: >>> a) EtherEncapsulator >>> b) A metadata Dispatcher >>> Typically, there will be only one LFB port >>> >>> uint32 >>> >> Chuanhuang: There are not only two cases you have showed. The downstream >> LFB instance also can be redirectOut or other media encapsulator. >> >>> a)MaxOutputPorts - what is the semantics of that given that we >>> only have one "SuccessOut" LFB port? >> Chuanhuang: Capability "MaxOutputPorts" has been removed, please see the email: >> subject: port group >> time: 2010-12-22 >> >> >> Yours, >> Chuanhuang >> >> >> From chuanhuang_li@mail.zjgsu.edu.cn Thu Apr 21 23:43:43 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4907AE07F5 for ; Thu, 21 Apr 2011 23:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.319 X-Spam-Level: X-Spam-Status: No, score=-1.319 tagged_above=-999 required=5 tests=[AWL=1.280, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oT2d5b06Ig1m for ; Thu, 21 Apr 2011 23:43:42 -0700 (PDT) Received: from mail.zjgsu.edu.cn (ucmail.zjgsu.edu.cn [124.160.64.1]) by ietfc.amsl.com (Postfix) with SMTP id EB327E07E9 for ; Thu, 21 Apr 2011 23:43:41 -0700 (PDT) Received: from RobinLee (unknown [10.20.0.167]) by mailportal (Coremail) with SMTP id rBCI85D7cjtDIbFNgIQeAA--.16064S2; Fri, 22 Apr 2011 14:33:39 +0800 (CST) Date: Fri, 22 Apr 2011 14:43:54 +0800 From: "Chuanhuang Li" To: "Jamal Hadi Salim" , "Wang,Weiming" Message-ID: <201104221443545647087@mail.zjgsu.edu.cn> Organization: Zhejiang Gongshang Univercity X-mailer: Foxmail 6, 15, 201, 23 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-CM-TRANSID: rBCI85D7cjtDIbFNgIQeAA--.16064S2 X-Coremail-Antispam: 1Uf129KBjDUn29KB7ZKAUJUUUUUYxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJ3UbIYCTnIWIevJa73UjIFyTuYvj4RJUUUUUUUU X-CM-SenderInfo: pfkxt0xkxd0wxbolqzhdloh6pmjv3hxhgxhubq/ Cc: "Joel M. Halpern" , wmwang , forces Subject: Re: [forces] EtherEncap review WAS(Re: BasicMetadataDispatch WAS(Re: LFB LPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 06:43:43 -0000 Hi, Jamal About the EtherEncap, please see the following comments. > 0) Note disappearance of ARP/ND from this draft. Also > note this LFB is agnostic of IPV4 or IPv6. > 1) Fix to look for OutputLogicalPortIndex > (as passed from NH) instead of LogicalPortID and note that > it is not optional. Chuanhuang: As said in previous email, do you mean "NHEncapInfoIndex"? L3 port ID "OutputLogicalPortID" may also be needed. > 2) We have an alternative table known as EncapTable which is very close to > ArpTable/NbrTable. We only need one table for both IPV4 and IPV6. > So assume as a starting point one of these. Chuanhuang: Sorry. I have to recover the discussion about how to process the packets needed to be forwarded to the directly connected subnet hosts. If we don't define ArpTable/NbrTable, each directly connected subnet host need one routing entry in Prefix and NH table. From implementation experience, the general processing way is define an indication in NH table to indicate this routing entry is for some directly connected subnet host. In this way we need define the ArpTable/NbrTable in EtherEncap. > i ) I dont think LogicalPortID (componentID="1") should be part of the > table. > The passed OutputLogicalPortIndex is an _index_ into the EncapTable > and therefore does not need to be part of the table. Chuanhuang: Please see the same considerations in NH table in previous email . > ii ) DstIPvxAddress is never used in this LFB. > iii) We merge the VLAN output table into EncapTable. Chuanhuang: VLAN output table is defined to get VLAN ID and the L2 output port before. > the table entry looks like: Chuanhuang: "FillFlag" definition need to be added to this table according the previous discussion. > > EncapTableType > Ethernet Encapsulation table entry type. > > > DstMac > Ethernet Mac of the Neighbor > IEEEMAC > > > SrcMac > Source MAC used in encapsulation > IEEEMAC > > > VlanID > VLAN ID. > uint32 > > > OutputLogicalPortID > Output logical port ID. > uint32 > > > Yours, Chuanhuang From jmh@joelhalpern.com Fri Apr 22 08:01:13 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C8942E06F7 for ; Fri, 22 Apr 2011 08:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.21 X-Spam-Level: X-Spam-Status: No, score=-102.21 tagged_above=-999 required=5 tests=[AWL=-0.211, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cj87qsQ5jWiV for ; Fri, 22 Apr 2011 08:01:13 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes.out.tigertech.net [74.114.88.72]) by ietfc.amsl.com (Postfix) with ESMTP id DADC4E05F5 for ; Fri, 22 Apr 2011 08:01:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 0000D4300F5; Fri, 22 Apr 2011 08:01:11 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-218.clppva.btas.verizon.net [71.161.51.218]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id A10354300F7; Fri, 22 Apr 2011 08:01:10 -0700 (PDT) Message-ID: <4DB19835.1000001@joelhalpern.com> Date: Fri, 22 Apr 2011 11:01:09 -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: Chuanhuang Li References: <201104221255218779523@mail.zjgsu.edu.cn> <201104221438353777658@mail.zjgsu.edu.cn> In-Reply-To: <201104221438353777658@mail.zjgsu.edu.cn> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: forces , wmwang Subject: Re: [forces] NH review WAS(Re: BasicMetadataDispatch WAS(Re: LFBLPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 15:01:13 -0000 I do not see any need for all the FEs in the NE to use the same index. The index is stored in one LFB of an FE, and used in another LFB of that same FE. Since the view of things and the capabilities from each FE is different, an implementation of a CE which attempted to use the same data representation to represent all the FEs is simply not going to work. The CE needs to keep a per-FE representation. No, this is not specified by the protocol. It is not a protocol issue. However, it does follow from looking at what the CE needs to do. The simplest example is that given multiple FEs, for any given prefix some FEs will need to have next-hops pointing to other FEs, while some FEs will have external next-hops for that prefix. Even the prefix granularity may be different on different FEs. Yours, Joel On 4/22/2011 2:38 AM, Chuanhuang Li wrote: > Hi,Joel > > Yes, it will be more efficient if using the explicit index between LFBs in the same > FE. But, CE need manage the unified routing tables for all FEs. If CE create an entry, > all FEs with differnet implementing ways need to create the same table index. This > hard coupling may constrain user's implementation. From CE point, loose coupling > between LFBs may be helpful to his manager. From FE point, FE can implement the > table more flexible. > >> Whether the FE gets to pi9ck the entry index for entries in a table >> depends upon how the CE creates the entries, and whether there is >> provision for the FE to autonomously create entries. >> For most tables, there is no autonomous creation, and the CE will select >> the index to use. Using the explicit index, rather than using a content >> value as a content-index, will generally be significantly more efficient. >> The tables we are discussing are ones where the CE will be creating entries. >> >> Also, note, these indices are used between LFBs in the same FE. We are >> not passing metadata between the FEs. (although it would still work then.) > >> Yes, we need the L3 Logical Port ID metadata, and we need the >> mediaencaptable index. these are separate pieces of metadata. >> >> Yours, >> Joel >> >> >> On 4/22/2011 12:55 AM, Chuanhuang Li wrote: >>> Hi, Jamal, >>> Thanks! I have some comments. >>>> 1)I dont think NexthopID (componentID="1") should be part of the table. >>>> The passed NexthopID is an _index_ into the NextHopTable and does not >>>> need to be part of the table. >>> Chuanhuang: whether need we differentiate between the truly table index and >>> the "index" which reflect the pointing relationship between two table? This maybe >>> a common question. The so-called "truly table index" is just the internal order >>> for building the table in an LFB. For example, there are two implementing methods for >>> NH table in two different FE, they can place the same entry in different place(different >>> truly table index), but the NexthopID is the same. This kind of definition can reduce some >>> "hard" coordination between LFBs. >>> >>>> 2)Renaming OutputLogicalPortID to OutputLogicalPortIndex for readability. >>> Chuanhuang: From previous discussion, the "OutputLogicalPortID" is exactly an L3 port ID, >>> It isn't an index. It have physic meaning. This should be continue to have in the NH table. >>> Maybe, do you want to add an element named "NHEncapInfoIndex" to the definition of NH table? >>> >>>> 3)Renaming EncapOutputIndex to LFBOutputSelectIndex to indicate >>>> which LFB port we are selecting to go to the downstream LFB instance. >>> Chuanhuang: I agree. >>> >>>> >>>> LFBOutputSelectIndex >>>> LFB Group output port index to select >>>> downstream LFB port. Some possibilities >>>> of downstream LFB instances are: >>>> a) EtherEncapsulator >>>> b) A metadata Dispatcher >>>> Typically, there will be only one LFB port >>>> >>>> uint32 >>>> >>> Chuanhuang: There are not only two cases you have showed. The downstream >>> LFB instance also can be redirectOut or other media encapsulator. >>> >>>> a)MaxOutputPorts - what is the semantics of that given that we >>>> only have one "SuccessOut" LFB port? >>> Chuanhuang: Capability "MaxOutputPorts" has been removed, please see the email: >>> subject: port group >>> time: 2010-12-22 >>> >>> >>> Yours, >>> Chuanhuang >>> >>> >>> > > > From hadi@mojatatu.com Sat Apr 23 08:46:22 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9FAC5E068A for ; Sat, 23 Apr 2011 08:46:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.068 X-Spam-Level: X-Spam-Status: No, score=-102.068 tagged_above=-999 required=5 tests=[AWL=0.309, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wc1nufpDcmlk for ; Sat, 23 Apr 2011 08:46:22 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfc.amsl.com (Postfix) with ESMTP id DA2DFE0674 for ; Sat, 23 Apr 2011 08:46:21 -0700 (PDT) Received: by fxm15 with SMTP id 15so876781fxm.31 for ; Sat, 23 Apr 2011 08:46:21 -0700 (PDT) Received: by 10.223.58.80 with SMTP id f16mr2381648fah.148.1303573581133; Sat, 23 Apr 2011 08:46:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.21.16 with HTTP; Sat, 23 Apr 2011 08:46:01 -0700 (PDT) In-Reply-To: <201104221255218779523@mail.zjgsu.edu.cn> References: <201104221255218779523@mail.zjgsu.edu.cn> From: Jamal Hadi Salim Date: Sat, 23 Apr 2011 11:46:01 -0400 Message-ID: To: Chuanhuang Li Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Joel M. Halpern" , wmwang , forces Subject: Re: [forces] NH review WAS(Re: BasicMetadataDispatch WAS(Re: LFB LPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2011 15:46:22 -0000 Chuanhuang, On Fri, Apr 22, 2011 at 12:55 AM, Chuanhuang Li wrote: [..] > Chuanhuang: whether need we differentiate between the truly table index a= nd > the "index" which reflect the pointing relationship between two table? Th= is maybe > a common question. The so-called "truly table index" is just the internal= order > for building the table in an LFB. =A0For example, there are two implement= ing methods for > NH table in two different FE, they can place the same entry in different = place(different > truly table index), but the NexthopID is the same. =A0This kind of defini= tion can reduce some > "hard" coordination between LFBs. As Joel has argued - there is only one index, so i dont see any change need= ed from what i said. Having said that since the issue of "NextHop FE" or "NextHop Module ID" has come up many times before. I have been guilty of bringing up that discussion many times (I dont do it intentionaly, it just shows up in my br= ain cells given my past experience). People implement with NH tables pointing to either other chips or linecards in addition to the NH ID. My opinion is we need to have a discussion in the draft somewhere about it. The model should be able to handle it without assuming inter-FE LFBs. Joel, what do you think? >> 2)Renaming OutputLogicalPortID to OutputLogicalPortIndex for readability= . > Chuanhuang: From previous discussion, the "OutputLogicalPortID" is exactl= y an L3 port ID, > It isn't an index. It have physic meaning. This should be continue to hav= e in the NH table. > Maybe, do you want to add an element named "NHEncapInfoIndex" to the defi= nition of > NH table? > Ok. When i update, I will have both MediaIndex or EncapIndex (please pick o= ne name) as well as L3PortID. >> 3)Renaming EncapOutputIndex to LFBOutputSelectIndex to indicate >> which LFB port we are selecting to go to the downstream LFB instance. > Chuanhuang: I agree. > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 LFBOutputSelectIndex >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 LFB Group output port index to= select >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 downstream LFB port.= Some possibilities >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 of downstream LFB in= stances are: >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 a) EtherEncapsulator >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 b) A metadata Dispatcher >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Typically, there will be= only one LFB port >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 uint32 >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 > Chuanhuang: =A0There are not only two cases you have showed. The downstre= am > LFB instance also can be redirectOut or other media encapsulator. > I will add those two as well as "etc" to mean there could be others. >> =A0a)MaxOutputPorts - what is the semantics of that given that we >> =A0only have one "SuccessOut" LFB port? > Chuanhuang: Capability "MaxOutputPorts" has been removed, please see the = email: > =A0 =A0 =A0 =A0 =A0 =A0subject: port group > =A0 =A0 =A0 =A0 =A0 =A0time: 2010-12-22 > I am still confused because my question is still not answered: We only have "successout" or "exception". What is the point of LFBOutputSelectIndex then? The CE knows what is to be sent on "successout". There is no need to set it anywhere. Who decides what the values of LFBOutputSelectIndex? Are we going to standardize? cheers, jamal From hadi@mojatatu.com Sat Apr 23 08:59:18 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 831FEE068A for ; Sat, 23 Apr 2011 08:59:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.075 X-Spam-Level: X-Spam-Status: No, score=-102.075 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w7CwlxekKRB4 for ; Sat, 23 Apr 2011 08:59:18 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfc.amsl.com (Postfix) with ESMTP id C0979E05F5 for ; Sat, 23 Apr 2011 08:59:17 -0700 (PDT) Received: by fxm15 with SMTP id 15so880627fxm.31 for ; Sat, 23 Apr 2011 08:59:17 -0700 (PDT) Received: by 10.223.58.80 with SMTP id f16mr2391109fah.148.1303574357103; Sat, 23 Apr 2011 08:59:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.21.16 with HTTP; Sat, 23 Apr 2011 08:58:57 -0700 (PDT) In-Reply-To: <201104221443545647087@mail.zjgsu.edu.cn> References: <201104221443545647087@mail.zjgsu.edu.cn> From: Jamal Hadi Salim Date: Sat, 23 Apr 2011 11:58:57 -0400 Message-ID: To: Chuanhuang Li Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Joel M. Halpern" , wmwang , forces Subject: Re: [forces] EtherEncap review WAS(Re: BasicMetadataDispatch WAS(Re: LFB LPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2011 15:59:18 -0000 Chuanhuang, On Fri, Apr 22, 2011 at 2:43 AM, Chuanhuang Li wrote: > Chuanhuang: As said in previous email, do you mean "NHEncapInfoIndex"? > L3 port ID "OutputLogicalPortID" may also be needed. > Refer to my other email: I have added L3portID and suggested a name for the Encap/MediaIndex (I asked for name suggestion of one or other). >> 2) We have an alternative table known as EncapTable which is very close = to >> ArpTable/NbrTable. We only need one table for both IPV4 and IPV6. >> So assume as a starting point one of these. > Chuanhuang: Sorry. I have to recover the discussion about how to process = the > packets needed to be forwarded to the directly connected subnet hosts. > If we don't define ArpTable/NbrTable, each directly connected subnet host= need > one routing entry in Prefix and NH table. From implementation experience,= the > general processing way is define an indication in NH table to indicate th= is routing > entry is for some directly connected subnet host. In this way we need def= ine the > ArpTable/NbrTable in EtherEncap. I still think this is an optimization. I also dont think that ARP is the right spot to make L3 decisions. Let me set that up as a separate discussion. I will c= hange the subject and send out new email to discuss this topic so it is not lost. >> i =A0) I dont think LogicalPortID (componentID=3D"1") should be part of = the >> table. >> The passed OutputLogicalPortIndex is an _index_ into the EncapTable >> and therefore does not need to be part of the table. > Chuanhuang: Please see the same considerations in NH table in previous em= ail . > Indeed - once we agree on the name it will apply here. >> ii ) DstIPvxAddress is never used in this LFB. > >> iii) We merge the VLAN output table into EncapTable. > Chuanhuang: VLAN output table is defined to get VLAN ID and the L2 output= port before. Can you explain some more? Are you saying we first take the media index and lookup the vlan table first and therefore it needs to be a separate tab= le? If that is the case then this vlan table will need to output a new media index as well to be used to lookup encap table, no? >> the table entry looks like: > Chuanhuang: "FillFlag" definition need to be added to this table accordin= g the previous >discussion. > Please refer again to my NH text. I made a slightly different suggestion which has the advantage of not requiring "FillFlag" entry or metadata . To quote (modified with "MediaIndex"): ---- CE sets MediaIndex port in NH to a value that is not allocated in EtherEncap EncapTable. EtherEncap lookup using passed MediaIndex will fail to find it. The failure serves as indication some other way to resolve it may be needed= . (Could be ARP etc). --- cheers, jamal From jmh@joelhalpern.com Sat Apr 23 09:02:10 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9BC15E06FA for ; Sat, 23 Apr 2011 09:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.745 X-Spam-Level: X-Spam-Status: No, score=-101.745 tagged_above=-999 required=5 tests=[AWL=-0.681, BAYES_00=-2.599, FRT_STRONG2=1.535, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YjUkeJXpXjaZ for ; Sat, 23 Apr 2011 09:02:10 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes.out.tigertech.net [74.114.88.72]) by ietfc.amsl.com (Postfix) with ESMTP id 0E6CFE06AB for ; Sat, 23 Apr 2011 09:02:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id B23FE4300BE; Sat, 23 Apr 2011 09:02:08 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-218.clppva.btas.verizon.net [71.161.51.218]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id 7CF7E4300AC; Sat, 23 Apr 2011 09:02:07 -0700 (PDT) Message-ID: <4DB2F7FE.5080400@joelhalpern.com> Date: Sat, 23 Apr 2011 12:02:06 -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: <201104221255218779523@mail.zjgsu.edu.cn> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: forces , Chuanhuang Li , wmwang Subject: Re: [forces] NH review WAS(Re: BasicMetadataDispatch WAS(Re: LFB LPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2011 16:02:10 -0000 Sorry, I am missing something. Is the question the existence of intermediate LFBs between the NH LFB and the media encapsulator? The metadata carries the information across that. Is the concern that there may be other, next-hop-specific, LFBs that need to know which next-hop is intended? It seems to me, since the CE creates all the entries, that the CE can, in hte normal case, just create entries at the correct index. If necessary, an LFB could have an auxiliary table, indexed by the logical output port and the next hop encapsulation index, which provides the local processing index. Or the unusual LFB could use the next hop encapsulation index as a content index, stroing the value in the base table. Lots of ways for it tow work, depending upon what problem the LFB is dealing with. I do not see why any change from what was suggested at the meeting is needed: Next Hop LFB produces an output logical port ID and a next hop ecnapsulation index. It also produces, where known, the next hop IP address, in case someone needs that. Yours, Joel On 4/23/2011 11:46 AM, Jamal Hadi Salim wrote: > Chuanhuang, > > On Fri, Apr 22, 2011 at 12:55 AM, Chuanhuang Li > wrote: > [..] >> Chuanhuang: whether need we differentiate between the truly table index and >> the "index" which reflect the pointing relationship between two table? This maybe >> a common question. The so-called "truly table index" is just the internal order >> for building the table in an LFB. For example, there are two implementing methods for >> NH table in two different FE, they can place the same entry in different place(different >> truly table index), but the NexthopID is the same. This kind of definition can reduce some >> "hard" coordination between LFBs. > > As Joel has argued - there is only one index, so i dont see any change needed > from what i said. > > Having said that since the issue of "NextHop FE" or "NextHop Module ID" > has come up many times before. I have been guilty of bringing up that > discussion many times (I dont do it intentionaly, it just shows up in my brain > cells given my past experience). > People implement with NH tables pointing to either other chips or linecards > in addition to the NH ID. My opinion is we need to have a discussion in the > draft somewhere about it. The model should be able to handle > it without assuming inter-FE LFBs. > Joel, what do you think? > From hadi@mojatatu.com Sat Apr 23 09:22:19 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 86174E06CD for ; Sat, 23 Apr 2011 09:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.382 X-Spam-Level: X-Spam-Status: No, score=-102.382 tagged_above=-999 required=5 tests=[AWL=0.595, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IgdzSjfv0Rz5 for ; Sat, 23 Apr 2011 09:22:18 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfc.amsl.com (Postfix) with ESMTP id B7010E06C8 for ; Sat, 23 Apr 2011 09:22:18 -0700 (PDT) Received: by fxm15 with SMTP id 15so887614fxm.31 for ; Sat, 23 Apr 2011 09:22:18 -0700 (PDT) Received: by 10.223.1.201 with SMTP id 9mr2466686fag.91.1303575738060; Sat, 23 Apr 2011 09:22:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.21.16 with HTTP; Sat, 23 Apr 2011 09:21:58 -0700 (PDT) From: Jamal Hadi Salim Date: Sat, 23 Apr 2011 12:21:58 -0400 Message-ID: To: Chuanhuang Li Content-Type: text/plain; charset=ISO-8859-1 Cc: "Joel M. Halpern" , wmwang , forces Subject: [forces] Directly Connected Routes WAS(Re: EtherEncap review WAS(Re: BasicMetadataDispatch WAS(Re: LFB LPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2011 16:22:19 -0000 On Sat, Apr 23, 2011 at 11:58 AM, Jamal Hadi Salim wrote: > I still think this is an optimization. I also dont think that ARP is > the right spot > to make L3 decisions. Let me set that up as a separate discussion. I will change > the subject and send out new email to discuss this topic so it is not lost. I will provide some context so other people can follow - so this is going to a long email. Authors please correct me if i misunderstood. There is a current optimization for directly connected routes as defined by draft-03 achieved by the presence of ARP in the EtherEncapsulator LFB. The ARP table, looked using NextHopIP address metadat, on success will match directly connected routes and allows us to send out to the on link host with the correct dstmac and media port without requiring us to store this routing entry in the LPM. The optimization in this case is that i) we dont have many entries in the LPM table and ii) it separates the directly connected routes from non-direct ones. While i agree that the optimization may be of value to say an edge router (which has presence of many direct hosts), I have counter-arguements. I would argue (using IPV4 as an example): - from a model abstraction view, LPM (not ARP) is the proper abstraction for "L3 Lookups". - the optimization is of no value to a core router with very few hosts connected. - the number of table entries are no different if you put these table entries in the ARP or LPM tables. i.e if you have 10 directly connected hosts, you will either have 10 ARP entries or 10 LPM entries. - the approach described in -03 is implementation specific. I have seen implementations which address this issue via two levels of lookups. First you lookup an LPM for directly connected hosts (Longest prefix) using one algorith which is efficient for /32 then you lookup the next LPM for prefixes other than /32. In such an implementation we dont need to have ARP and assuming a mandatory presence of ARP just complicates things. So my suggestion is this should stay out of the model. The model would still support the described text by assuming that etherencap can be connected via an LFB-port to ARP for exception handling. And that the ARP table can have these details as described in L3 and forward on the packet to the host. Having said that: We should have text discussing this issue so we dont have to go scan emails later to figure how we reached the decision. cheers, jamal From hadi@mojatatu.com Sat Apr 23 09:37:41 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A8469E06CD for ; Sat, 23 Apr 2011 09:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.629 X-Spam-Level: X-Spam-Status: No, score=-101.629 tagged_above=-999 required=5 tests=[AWL=-0.187, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_STRONG2=1.535, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id px4JmgCTjUZm for ; Sat, 23 Apr 2011 09:37:41 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfc.amsl.com (Postfix) with ESMTP id 06C71E06C8 for ; Sat, 23 Apr 2011 09:37:40 -0700 (PDT) Received: by fxm15 with SMTP id 15so891844fxm.31 for ; Sat, 23 Apr 2011 09:37:40 -0700 (PDT) Received: by 10.223.91.79 with SMTP id l15mr1906983fam.53.1303576660200; Sat, 23 Apr 2011 09:37:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.21.16 with HTTP; Sat, 23 Apr 2011 09:37:20 -0700 (PDT) In-Reply-To: <4DB2F7FE.5080400@joelhalpern.com> References: <201104221255218779523@mail.zjgsu.edu.cn> <4DB2F7FE.5080400@joelhalpern.com> From: Jamal Hadi Salim Date: Sat, 23 Apr 2011 12:37:20 -0400 Message-ID: To: "Joel M. Halpern" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: forces , Chuanhuang Li , wmwang Subject: Re: [forces] NH review WAS(Re: BasicMetadataDispatch WAS(Re: LFB LPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2011 16:37:41 -0000 Joel, My main concern is that this discussion will come up again (100.5%). Or the= re may be confusion from someone implementing as to the semantics. It is useful for the reader and pragmatic for the authors to provide clarit= y. For example, we have clearly stated that the burden is on the FE to do handle the massaging that maps its LPM/NH tables (given some implementations have the LPM encapsulating the NH info vs others with separate NH LFB/table). As far as the CE is concerned, they are separate. My thinking is that the idea of a NH implementation with a reference to a moduleID applies similarly. i.e we may need to pick a side, but we need to state and reason it clearly. cheers, jamal On Sat, Apr 23, 2011 at 12:02 PM, Joel M. Halpern wro= te: > Sorry, I am missing something. > > Is the question the existence of intermediate LFBs between the NH LFB and > the media encapsulator? =A0The metadata carries the information across th= at. > > Is the concern that there may be other, next-hop-specific, LFBs that need= to > know which next-hop is intended? =A0It seems to me, since the CE creates = all > the entries, that the CE can, in hte normal case, just create entries at = the > correct index. > If necessary, an LFB could have an auxiliary table, indexed by the logica= l > output port and the next hop encapsulation index, which provides the loca= l > processing index. =A0Or the unusual LFB could use the next hop encapsulat= ion > index as a content index, stroing the value in the base table. =A0Lots of= ways > for it tow work, depending upon what problem the LFB is dealing with. > > I do not see why any change from what was suggested at the meeting is > needed: =A0Next Hop LFB produces an output logical port ID and a next hop > ecnapsulation index. =A0It also produces, where known, the next hop IP > address, in case someone needs that. > > Yours, > Joel From jmh@joelhalpern.com Sat Apr 23 10:32:20 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id AE554E071B for ; Sat, 23 Apr 2011 10:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.489 X-Spam-Level: X-Spam-Status: No, score=-102.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t6WR5F691+QR for ; Sat, 23 Apr 2011 10:32:20 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes.out.tigertech.net [74.114.88.72]) by ietfc.amsl.com (Postfix) with ESMTP id E0000E06C8 for ; Sat, 23 Apr 2011 10:32:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 7AF7B4300EC; Sat, 23 Apr 2011 10:32:19 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-218.clppva.btas.verizon.net [71.161.51.218]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id 66C634300BE; Sat, 23 Apr 2011 10:32:18 -0700 (PDT) Message-ID: <4DB30D21.2000903@joelhalpern.com> Date: Sat, 23 Apr 2011 13:32:17 -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: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: forces , Chuanhuang Li , wmwang Subject: Re: [forces] Directly Connected Routes WAS(Re: EtherEncap review WAS(Re: BasicMetadataDispatch WAS(Re: LFB LPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2011 17:32:20 -0000 I could live with this. I think we do end up with more entries this way in edge routers. But your argument about generality is sufficient for me. Yours, Joel On 4/23/2011 12:21 PM, Jamal Hadi Salim wrote: > On Sat, Apr 23, 2011 at 11:58 AM, Jamal Hadi Salim wrote: > >> I still think this is an optimization. I also dont think that ARP is >> the right spot >> to make L3 decisions. Let me set that up as a separate discussion. I will change >> the subject and send out new email to discuss this topic so it is not lost. > > I will provide some context so other people can follow - so this is going to > a long email. Authors please correct me if i misunderstood. > There is a current optimization for directly connected routes as defined by > draft-03 achieved by the presence of ARP in the EtherEncapsulator LFB. > > The ARP table, looked using NextHopIP address metadat, on success will match > directly connected routes and allows us to send out to the on link host with > the correct dstmac and media port without requiring us to store this routing > entry in the LPM. > The optimization in this case is that i) we dont have many entries in the LPM > table and ii) it separates the directly connected routes from non-direct ones. > > While i agree that the optimization may be of value to say an edge router > (which has presence of many direct hosts), I have counter-arguements. > I would argue (using IPV4 as an example): > > - from a model abstraction view, LPM (not ARP) is the proper abstraction > for "L3 Lookups". > - the optimization is of no value to a core router with very few hosts > connected. > - the number of table entries are no different if you put these table entries > in the ARP or LPM tables. i.e if you have 10 directly connected hosts, you > will either have 10 ARP entries or 10 LPM entries. > - the approach described in -03 is implementation specific. I have seen > implementations which address this issue via two levels of lookups. > First you lookup an LPM for directly connected hosts (Longest prefix) > using one algorith which is efficient for /32 then you lookup the next > LPM for prefixes other than /32. In such an implementation we dont need > to have ARP and assuming a mandatory presence of ARP just complicates > things. > > So my suggestion is this should stay out of the model. The model would > still support the described text by assuming that etherencap can be connected > via an LFB-port to ARP for exception handling. And that the ARP table can > have these details as described in L3 and forward on the packet to the host. > > Having said that: > We should have text discussing this issue so we dont have to go scan emails > later to figure how we reached the decision. > > cheers, > jamal > From jmh@joelhalpern.com Sat Apr 23 10:33:58 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id BC990E071B for ; Sat, 23 Apr 2011 10:33:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.725 X-Spam-Level: X-Spam-Status: No, score=-101.725 tagged_above=-999 required=5 tests=[AWL=-0.661, BAYES_00=-2.599, FRT_STRONG2=1.535, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DeM2fdekxL1d for ; Sat, 23 Apr 2011 10:33:58 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes.out.tigertech.net [74.114.88.72]) by ietfc.amsl.com (Postfix) with ESMTP id 30A8DE06C8 for ; Sat, 23 Apr 2011 10:33:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id D628F4300E1; Sat, 23 Apr 2011 10:33:57 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-218.clppva.btas.verizon.net [71.161.51.218]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id AABCE4300BD; Sat, 23 Apr 2011 10:33:56 -0700 (PDT) Message-ID: <4DB30D84.8050508@joelhalpern.com> Date: Sat, 23 Apr 2011 13:33:56 -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: <201104221255218779523@mail.zjgsu.edu.cn> <4DB2F7FE.5080400@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: forces , Chuanhuang Li , wmwang Subject: Re: [forces] NH review WAS(Re: BasicMetadataDispatch WAS(Re: LFB LPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2011 17:33:58 -0000 If what you are asking for is better explanation, I would agree with that. The amount of discussion we have needed makes it clear we need good explanatory text. Otherwise, not only will the discussion come up again, but folks will misunderstand what we have put together. I thought you were asking for a different structuring of the LFBs, tables, and metadata. Yours, Joel On 4/23/2011 12:37 PM, Jamal Hadi Salim wrote: > Joel, > > My main concern is that this discussion will come up again (100.5%). Or there > may be confusion from someone implementing as to the semantics. > It is useful for the reader and pragmatic for the authors to provide clarity. > > For example, we have clearly stated that the burden is on the FE to do > handle the massaging that maps its LPM/NH tables > (given some implementations have the LPM encapsulating the NH info vs > others with separate NH LFB/table). As far as the CE is concerned, they are > separate. > My thinking is that the idea of a NH implementation with a reference to a > moduleID applies similarly. i.e we may need to pick a side, but we need > to state and reason it clearly. > > cheers, > jamal > > On Sat, Apr 23, 2011 at 12:02 PM, Joel M. Halpern wrote: >> Sorry, I am missing something. >> >> Is the question the existence of intermediate LFBs between the NH LFB and >> the media encapsulator? The metadata carries the information across that. >> >> Is the concern that there may be other, next-hop-specific, LFBs that need to >> know which next-hop is intended? It seems to me, since the CE creates all >> the entries, that the CE can, in hte normal case, just create entries at the >> correct index. >> If necessary, an LFB could have an auxiliary table, indexed by the logical >> output port and the next hop encapsulation index, which provides the local >> processing index. Or the unusual LFB could use the next hop encapsulation >> index as a content index, stroing the value in the base table. Lots of ways >> for it tow work, depending upon what problem the LFB is dealing with. >> >> I do not see why any change from what was suggested at the meeting is >> needed: Next Hop LFB produces an output logical port ID and a next hop >> ecnapsulation index. It also produces, where known, the next hop IP >> address, in case someone needs that. >> >> Yours, >> Joel > From hadi@mojatatu.com Sat Apr 23 11:22:28 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 06714E067C for ; Sat, 23 Apr 2011 11:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.624 X-Spam-Level: X-Spam-Status: No, score=-101.624 tagged_above=-999 required=5 tests=[AWL=-0.182, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_STRONG2=1.535, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z4EvjzADfTeU for ; Sat, 23 Apr 2011 11:22:27 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfc.amsl.com (Postfix) with ESMTP id 411D4E0668 for ; Sat, 23 Apr 2011 11:22:27 -0700 (PDT) Received: by fxm15 with SMTP id 15so919019fxm.31 for ; Sat, 23 Apr 2011 11:22:26 -0700 (PDT) Received: by 10.223.27.14 with SMTP id g14mr2524392fac.129.1303582946085; Sat, 23 Apr 2011 11:22:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.21.16 with HTTP; Sat, 23 Apr 2011 11:22:06 -0700 (PDT) In-Reply-To: <4DB30D84.8050508@joelhalpern.com> References: <201104221255218779523@mail.zjgsu.edu.cn> <4DB2F7FE.5080400@joelhalpern.com> <4DB30D84.8050508@joelhalpern.com> From: Jamal Hadi Salim Date: Sat, 23 Apr 2011 14:22:06 -0400 Message-ID: To: "Joel M. Halpern" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: forces , Chuanhuang Li , wmwang Subject: Re: [forces] NH review WAS(Re: BasicMetadataDispatch WAS(Re: LFB LPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2011 18:22:28 -0000 Indeed I am asking for better explanation - and maybe even an example i.e I am happy for it not to be part of the model. cheers, jamal On Sat, Apr 23, 2011 at 1:33 PM, Joel M. Halpern wrot= e: > If what you are asking for is better explanation, I would agree with that= . > =A0The amount of discussion we have needed makes it clear we need good > explanatory text. =A0Otherwise, not only will the discussion come up agai= n, > but folks will misunderstand what we have put together. > > I thought you were asking for a different structuring of the LFBs, tables= , > and metadata. > > Yours, > Joel > > On 4/23/2011 12:37 PM, Jamal Hadi Salim wrote: >> >> Joel, >> >> My main concern is that this discussion will come up again (100.5%). Or >> there >> may be confusion from someone implementing as to the semantics. >> It is useful for the reader and pragmatic for the authors to provide >> clarity. >> >> For example, we have clearly stated that the burden is on the FE to do >> handle the massaging that maps its LPM/NH tables >> (given some implementations have the LPM encapsulating the NH info vs >> others with separate NH LFB/table). As far as the CE is concerned, they >> are >> separate. >> My thinking is that the idea of a NH implementation with a reference to = a >> moduleID applies =A0similarly. i.e we may need to pick a side, but we ne= ed >> to state and reason it clearly. >> >> cheers, >> jamal >> >> On Sat, Apr 23, 2011 at 12:02 PM, Joel M. Halpern >> =A0wrote: >>> >>> Sorry, I am missing something. >>> >>> Is the question the existence of intermediate LFBs between the NH LFB a= nd >>> the media encapsulator? =A0The metadata carries the information across >>> that. >>> >>> Is the concern that there may be other, next-hop-specific, LFBs that ne= ed >>> to >>> know which next-hop is intended? =A0It seems to me, since the CE create= s >>> all >>> the entries, that the CE can, in hte normal case, just create entries a= t >>> the >>> correct index. >>> If necessary, an LFB could have an auxiliary table, indexed by the >>> logical >>> output port and the next hop encapsulation index, which provides the >>> local >>> processing index. =A0Or the unusual LFB could use the next hop >>> encapsulation >>> index as a content index, stroing the value in the base table. =A0Lots = of >>> ways >>> for it tow work, depending upon what problem the LFB is dealing with. >>> >>> I do not see why any change from what was suggested at the meeting is >>> needed: =A0Next Hop LFB produces an output logical port ID and a next h= op >>> ecnapsulation index. =A0It also produces, where known, the next hop IP >>> address, in case someone needs that. >>> >>> Yours, >>> Joel >> > From chuanhuang_li@mail.zjgsu.edu.cn Sun Apr 24 18:22:31 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7FD40E0669 for ; Sun, 24 Apr 2011 18:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.161 X-Spam-Level: X-Spam-Status: No, score=-0.161 tagged_above=-999 required=5 tests=[AWL=-0.162, BAYES_50=0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MB26NIbh5JgA for ; Sun, 24 Apr 2011 18:22:31 -0700 (PDT) Received: from mail.zjgsu.edu.cn (ucmail.zjgsu.edu.cn [124.160.64.1]) by ietfc.amsl.com (Postfix) with SMTP id 30DC6E062B for ; Sun, 24 Apr 2011 18:22:28 -0700 (PDT) Received: from RobinLee (unknown [10.20.0.167]) by mailportal (Coremail) with SMTP id rBCI85DrUTxoyrRNgIQeAA--.22925S2; Mon, 25 Apr 2011 09:12:09 +0800 (CST) Date: Mon, 25 Apr 2011 09:20:27 +0800 From: "Chuanhuang Li" To: "Joel M. Halpern" References: <201104221255218779523@mail.zjgsu.edu.cn>, <201104221438353777658@mail.zjgsu.edu.cn> Message-ID: <201104250920271076777@mail.zjgsu.edu.cn> Organization: Zhejiang Gongshang Univercity X-mailer: Foxmail 6, 15, 201, 23 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-CM-TRANSID: rBCI85DrUTxoyrRNgIQeAA--.22925S2 X-Coremail-Antispam: 1Uf129KBjDUn29KB7ZKAUJUUUUUYxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJ3UbIYCTnIWIevJa73UjIFyTuYvj4RJUUUUUUUU X-CM-SenderInfo: pfkxt0xkxd0wxbolqzhdloh6pmjv3hxhgxhubq/ Cc: forces , wmwang Subject: Re: [forces] NH review WAS(Re: BasicMetadataDispatch WAS(Re: LFBLPMissue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 01:22:31 -0000 >I do not see any need for all the FEs in the NE to use the same index. >The index is stored in one LFB of an FE, and used in another LFB of that >same FE. >Since the view of things and the capabilities from each FE is different, >an implementation of a CE which attempted to use the same data >representation to represent all the FEs is simply not going to work. >The CE needs to keep a per-FE representation. No, this is not specified >by the protocol. It is not a protocol issue. However, it does follow >from looking at what the CE needs to do. >The simplest example is that given multiple FEs, for any given prefix >some FEs will need to have next-hops pointing to other FEs, while some >FEs will have external next-hops for that prefix. >Even the prefix granularity may be different on different FEs. OK, I accept this point. I have no problem about this. Yours, Chuanhuang From chuanhuang_li@mail.zjgsu.edu.cn Sun Apr 24 18:24:02 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 70CFEE0669 for ; Sun, 24 Apr 2011 18:24:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.548 X-Spam-Level: X-Spam-Status: No, score=-0.548 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fMaH3eCm7LD5 for ; Sun, 24 Apr 2011 18:24:01 -0700 (PDT) Received: from mail.zjgsu.edu.cn (ucmail.zjgsu.edu.cn [124.160.64.1]) by ietfc.amsl.com (Postfix) with SMTP id 1ACBFE062B for ; Sun, 24 Apr 2011 18:24:00 -0700 (PDT) Received: from RobinLee (unknown [10.20.0.167]) by mailportal (Coremail) with SMTP id rBCI85D7QDnEyrRNgIQeAA--.22931S2; Mon, 25 Apr 2011 09:13:40 +0800 (CST) Date: Mon, 25 Apr 2011 09:21:59 +0800 From: "Chuanhuang Li" To: "Jamal Hadi Salim" References: <201104221255218779523@mail.zjgsu.edu.cn> Message-ID: <201104250921589037174@mail.zjgsu.edu.cn> Organization: Zhejiang Gongshang Univercity X-mailer: Foxmail 6, 15, 201, 23 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-CM-TRANSID: rBCI85D7QDnEyrRNgIQeAA--.22931S2 X-Coremail-Antispam: 1Uf129KBjDUn29KB7ZKAUJUUUUUYxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJ3UbIYCTnIWIevJa73UjIFyTuYvj4RJUUUUUUUU X-CM-SenderInfo: pfkxt0xkxd0wxbolqzhdloh6pmjv3hxhgxhubq/ Cc: "Joel M. Halpern" , wmwang , forces Subject: Re: [forces] NH review WAS(Re: BasicMetadataDispatch WAS(Re: LFB LPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 01:24:02 -0000 SGksSmFtYWwgDQo+Pj4goGEpTWF4T3V0cHV0UG9ydHMgLSB3aGF0IGlzIHRoZSBzZW1hbnRpY3Mg b2YgdGhhdCBnaXZlbiB0aGF0IHdlDQo+Pj4goG9ubHkgaGF2ZSBvbmUgIlN1Y2Nlc3NPdXQiIExG QiBwb3J0Pw0KPj4gQ2h1YW5odWFuZzogQ2FwYWJpbGl0eSAiTWF4T3V0cHV0UG9ydHMiIGhhcyBi ZWVuIHJlbW92ZWQsIHBsZWFzZSBzZWUgdGhlIGVtYWlsOg0KPj4goCCgIKAgoCCgIKBzdWJqZWN0 OiBwb3J0IGdyb3VwDQo+PiCgIKAgoCCgIKAgoHRpbWU6IDIwMTAtMTItMjINCg0KPkkgYW0gc3Rp bGwgY29uZnVzZWQgYmVjYXVzZSBteSBxdWVzdGlvbiBpcyBzdGlsbCBub3QgYW5zd2VyZWQ6DQo+ V2Ugb25seSBoYXZlICJzdWNjZXNzb3V0IiBvciAiZXhjZXB0aW9uIi4gV2hhdCBpcyB0aGUgcG9p bnQgb2YNCj5MRkJPdXRwdXRTZWxlY3RJbmRleCB0aGVuPyBUaGUgQ0Uga25vd3Mgd2hhdCBpcyB0 byBiZSBzZW50IG9uICJzdWNjZXNzb3V0Ii4NCj5UaGVyZSBpcyBubyBuZWVkIHRvIHNldCBpdCBh bnl3aGVyZS4NCj5XaG8gZGVjaWRlcyB3aGF0IHRoZSB2YWx1ZXMgb2YgTEZCT3V0cHV0U2VsZWN0 SW5kZXg/IEFyZSB3ZSBnb2luZyB0bw0KPnN0YW5kYXJkaXplPw0KDQoic3VjY2Vzc291dCIgaXMg YW4gb3V0cHV0IHBvcnQgZ3JvdXAuICJMRkJPdXRwdXRTZWxlY3RJbmRleCIgaXMgdXNlZCB0byBz ZWxlY3QgYW4gb3V0cHV0IA0KZnJvbSB0aGlzIGdyb3VwLg0KDQpZb3VycywNCkNodWFuaHVhbmcN Cg0K From chuanhuang_li@mail.zjgsu.edu.cn Sun Apr 24 19:20:37 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9116BE0611 for ; Sun, 24 Apr 2011 19:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.168 X-Spam-Level: X-Spam-Status: No, score=-1.168 tagged_above=-999 required=5 tests=[AWL=0.831, BAYES_00=-2.599, J_CHICKENPOX_16=0.6] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AoneQp6xqe9z for ; Sun, 24 Apr 2011 19:20:37 -0700 (PDT) Received: from mail.zjgsu.edu.cn (ucmail.zjgsu.edu.cn [124.160.64.1]) by ietfc.amsl.com (Postfix) with SMTP id 3BE65E00BE for ; Sun, 24 Apr 2011 19:20:35 -0700 (PDT) Received: from RobinLee (unknown [10.20.0.167]) by mailportal (Coremail) with SMTP id rBCI85Dr3zoI2LRNgIQeAA--.23043S2; Mon, 25 Apr 2011 10:10:16 +0800 (CST) Date: Mon, 25 Apr 2011 10:18:35 +0800 From: "Chuanhuang Li" To: "Jamal Hadi Salim" References: <201104221443545647087@mail.zjgsu.edu.cn> Message-ID: <201104251018350282351@mail.zjgsu.edu.cn> Organization: Zhejiang Gongshang Univercity X-mailer: Foxmail 6, 15, 201, 23 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-CM-TRANSID: rBCI85Dr3zoI2LRNgIQeAA--.23043S2 X-Coremail-Antispam: 1Uf129KBjDUn29KB7ZKAUJUUUUUYxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJ3UbIYCTnIWIevJa73UjIFyTuYvj4RJUUUUUUUU X-CM-SenderInfo: pfkxt0xkxd0wxbolqzhdloh6pmjv3hxhgxhubq/ Cc: "Joel M. Halpern" , wmwang , forces Subject: Re: [forces] EtherEncap review WAS(Re: BasicMetadataDispatch WAS(Re: LFB LPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 02:20:37 -0000 Hi,Jamal >Refer to my other email: >I have added L3portID and suggested a name for the Encap/MediaIndex (I >asked for name suggestion of one or other). I prefer to the combined name: MediaEncapInfoIndex. "MediaIndex" seems to only indicate selecting a special/different media to encapsulate. >>> iii) We merge the VLAN output table into EncapTable. >> Chuanhuang: VLAN output table is defined to get VLAN ID and the L2 output port before. > >Can you explain some more? Are you saying we first take the media index >and lookup the vlan table first and therefore it needs to be a separate table? >If that is the case then this vlan table will need to output a new >media index as >well to be used to lookup encap table, no? These are our consideration before, and had been discussed with Joel: (Precondition: not using the "MediaEncapInfoIndex".) NH LFB will generate new metadatas: OutputLogicalPortID, NexthopIPv4Addr. In the entry which have been found, if "NexthopOption" is indicated that this packet need to be forwarded to local dirrectly connected subnet host, metadata NexthopIPv4Addr will be filled with the destination IP address of the packet. For normal forwarding, next, the packet will be sent to EtherEncapsulator LFB. EtherEncapsulator will use OutputLogicalPortID metadata as the key of LogicalPortID element to lookup VlanOutputTable to get VlanID and the new OutputLogicalPortID. Then it will use this new OutputLogicalPortID and NexthopIPv4Addr metadata to lookup ArpTable to get the output Ethernet L2 information. After processed in this LFB, metadata OutputLogicalPortID will be updated. In this simple case, EtherEncapsulator will deliver packets to the correct physical port directly. And the OutputLogicalPortID is exactly the PHYPortID information. However, if the device is doing bridging as well as routing (or bridging plus host applications like management or console services), then after the encapsulation, all that EtherEncapsulator knows is what logical port the packet is to be sent on. The packet must be handed to the bridging logic, which will use the logical output port and the destination MAC address to decide what physical port to send the frame on, including the possibility that it may need to flood the packet out several physical ports, or add additional bridging encapsulations. I think, If we use "MediaEncapInfoIndex" and merge VLAN output table into media enap table, an element, such as named "L2PortID", need to be added into the encap table. Yours, Chuanhuang From chuanhuang_li@mail.zjgsu.edu.cn Sun Apr 24 19:28:38 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8EB8DE0669 for ; Sun, 24 Apr 2011 19:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.537 X-Spam-Level: X-Spam-Status: No, score=-1.537 tagged_above=-999 required=5 tests=[AWL=1.062, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eed3+Lg2Ttjf for ; Sun, 24 Apr 2011 19:28:38 -0700 (PDT) Received: from mail.zjgsu.edu.cn (ucmail.zjgsu.edu.cn [124.160.64.1]) by ietfc.amsl.com (Postfix) with SMTP id 3D66AE0611 for ; Sun, 24 Apr 2011 19:28:36 -0700 (PDT) Received: from RobinLee (unknown [10.20.0.167]) by mailportal (Coremail) with SMTP id rBCI85D7Vznp2bRNgIQeAA--.23059S2; Mon, 25 Apr 2011 10:18:17 +0800 (CST) Date: Mon, 25 Apr 2011 10:26:36 +0800 From: "Chuanhuang Li" To: "Jamal Hadi Salim" References: <201104221443545647087@mail.zjgsu.edu.cn> Message-ID: <201104251026359503667@mail.zjgsu.edu.cn> Organization: Zhejiang Gongshang Univercity X-mailer: Foxmail 6, 15, 201, 23 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-CM-TRANSID: rBCI85D7Vznp2bRNgIQeAA--.23059S2 X-Coremail-Antispam: 1Uf129KBjDUn29KB7ZKAUJUUUUUYxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJ3UbIYCTnIWIevJa73UjIFyTuYvj4RJUUUUUUUU X-CM-SenderInfo: pfkxt0xkxd0wxbolqzhdloh6pmjv3hxhgxhubq/ Cc: "Joel M. Halpern" , wmwang , forces Subject: Re: [forces] EtherEncap review WAS(Re: BasicMetadataDispatch WAS(Re: LFB LPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 02:28:38 -0000 Hi,Jamal > >>> the table entry looks like: >> Chuanhuang: "FillFlag" definition need to be added to this table according the previous >discussion. >Please refer again to my NH text. I made a slightly different suggestion >which has the advantage of not requiring "FillFlag" entry or metadata . To >quote (modified with "MediaIndex"): > >---- >CE sets MediaIndex port in NH to a value that is not allocated >in EtherEncap EncapTable. EtherEncap lookup using passed MediaIndex >will fail to find it. >The failure serves as indication some other way to resolve it may be needed. >(Could be ARP etc). >--- OK, this can solve the problem. We also had used this way to indicate the ARP table having not been flushed. Yours, Chuanhuang From hadi@mojatatu.com Mon Apr 25 05:17:48 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 22AD2E0722 for ; Mon, 25 Apr 2011 05:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.388 X-Spam-Level: X-Spam-Status: No, score=-102.388 tagged_above=-999 required=5 tests=[AWL=0.589, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M6K2m4OWHY1h for ; Mon, 25 Apr 2011 05:17:47 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfc.amsl.com (Postfix) with ESMTP id 0D46CE064E for ; Mon, 25 Apr 2011 05:17:46 -0700 (PDT) Received: by fxm15 with SMTP id 15so1561702fxm.31 for ; Mon, 25 Apr 2011 05:17:46 -0700 (PDT) Received: by 10.223.58.80 with SMTP id f16mr4252499fah.148.1303733866052; Mon, 25 Apr 2011 05:17:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.21.16 with HTTP; Mon, 25 Apr 2011 05:17:26 -0700 (PDT) In-Reply-To: <201104250921589037174@mail.zjgsu.edu.cn> References: <201104221255218779523@mail.zjgsu.edu.cn> <201104250921589037174@mail.zjgsu.edu.cn> From: Jamal Hadi Salim Date: Mon, 25 Apr 2011 08:17:26 -0400 Message-ID: To: Chuanhuang Li Content-Type: text/plain; charset=ISO-8859-1 Cc: "Joel M. Halpern" , wmwang , forces Subject: Re: [forces] NH review WAS(Re: BasicMetadataDispatch WAS(Re: LFB LPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 12:17:48 -0000 Chuanhuang, On Sun, Apr 24, 2011 at 9:21 PM, Chuanhuang Li wrote: > "successout" is an output port group. "LFBOutputSelectIndex" is used to select an output > from this group. Sorry I missed it - it was right there in the text ;-> I will fix the text and re-post again. my brain is slow: how does the CE knows what LFBOutputSelectIndex 32 bit value is? I know that the LFB Topology will eventually have an LFB selector indication for the port - but how do we go there to the value in LFBOutputSelectIndex of this table? cheers, jamal From hadi@mojatatu.com Mon Apr 25 05:19:51 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7A8D2E0725 for ; Mon, 25 Apr 2011 05:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.401 X-Spam-Level: X-Spam-Status: No, score=-102.401 tagged_above=-999 required=5 tests=[AWL=0.576, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mtNCYwV54nol for ; Mon, 25 Apr 2011 05:19:50 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfc.amsl.com (Postfix) with ESMTP id B2067E0722 for ; Mon, 25 Apr 2011 05:19:50 -0700 (PDT) Received: by fxm15 with SMTP id 15so1562824fxm.31 for ; Mon, 25 Apr 2011 05:19:50 -0700 (PDT) Received: by 10.223.91.79 with SMTP id l15mr3766512fam.53.1303733990085; Mon, 25 Apr 2011 05:19:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.21.16 with HTTP; Mon, 25 Apr 2011 05:19:30 -0700 (PDT) In-Reply-To: <201104251018350282351@mail.zjgsu.edu.cn> References: <201104221443545647087@mail.zjgsu.edu.cn> <201104251018350282351@mail.zjgsu.edu.cn> From: Jamal Hadi Salim Date: Mon, 25 Apr 2011 08:19:30 -0400 Message-ID: To: Chuanhuang Li Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Joel M. Halpern" , wmwang , forces Subject: Re: [forces] EtherEncap review WAS(Re: BasicMetadataDispatch WAS(Re: LFB LPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 12:19:51 -0000 Hi Chuanhuang, On Sun, Apr 24, 2011 at 10:18 PM, Chuanhuang Li wrote: > I prefer to =A0the combined name: MediaEncapInfoIndex. > "MediaIndex" seems to only indicate selecting a special/different media t= o > encapsulate. Ok, changed in my text. > These are our consideration before, and had been discussed with Joel: > (Precondition: not using the "MediaEncapInfoIndex".) > NH LFB will generate new metadatas: OutputLogicalPortID, NexthopIPv4Addr. > In the entry which have been found, if "NexthopOption" is indicated that = this > packet need to be forwarded to local dirrectly connected subnet host, met= adata > NexthopIPv4Addr will be filled with the destination IP address of the pac= ket. > For normal forwarding, next, the packet will be sent to EtherEncapsulator= LFB. > EtherEncapsulator will use OutputLogicalPortID metadata as the key of Log= icalPortID > element to lookup VlanOutputTable to get VlanID and the new OutputLogical= PortID. > Then it will use this new OutputLogicalPortID and NexthopIPv4Addr metadat= a to lookup > ArpTable to get the output Ethernet L2 information. After processed in th= is LFB, > metadata OutputLogicalPortID will be updated. > In this simple case, EtherEncapsulator will deliver packets to the correc= t physical port > directly. =A0And the OutputLogicalPortID is exactly the PHYPortID informa= tion. > However, if the device is doing bridging as well as routing (or bridging = plus > host applications > like management or console services), then after the encapsulation, all t= hat > EtherEncapsulator > knows is what logical port the packet is to be sent on. =A0The packet mus= t be handed to > the bridging logic, which will use the logical output port and the destin= ation MAC address > to decide what physical port to send the frame on, including the possibil= ity that it may need > to flood the packet out several physical ports, or add additional bridgin= g encapsulations. > > I think, If we use "MediaEncapInfoIndex" and merge VLAN output table into= media enap table, > an element, such as named "L2PortID", need to be added into the encap tab= le. > We already have OutputLogicalPortID - do you mean we need to change the name to L2PortID? cheers, jamal From hadi@mojatatu.com Mon Apr 25 05:20:28 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C42CEE073A for ; Mon, 25 Apr 2011 05:20:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.413 X-Spam-Level: X-Spam-Status: No, score=-102.413 tagged_above=-999 required=5 tests=[AWL=0.564, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cm4uQ9yVbEoD for ; Mon, 25 Apr 2011 05:20:28 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfc.amsl.com (Postfix) with ESMTP id 34FFEE0722 for ; Mon, 25 Apr 2011 05:20:28 -0700 (PDT) Received: by fxm15 with SMTP id 15so1563164fxm.31 for ; Mon, 25 Apr 2011 05:20:27 -0700 (PDT) Received: by 10.223.27.14 with SMTP id g14mr509963fac.129.1303734027554; Mon, 25 Apr 2011 05:20:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.21.16 with HTTP; Mon, 25 Apr 2011 05:20:07 -0700 (PDT) In-Reply-To: <201104251026359503667@mail.zjgsu.edu.cn> References: <201104221443545647087@mail.zjgsu.edu.cn> <201104251026359503667@mail.zjgsu.edu.cn> From: Jamal Hadi Salim Date: Mon, 25 Apr 2011 08:20:07 -0400 Message-ID: To: Chuanhuang Li Content-Type: text/plain; charset=ISO-8859-1 Cc: "Joel M. Halpern" , wmwang , forces Subject: Re: [forces] EtherEncap review WAS(Re: BasicMetadataDispatch WAS(Re: LFB LPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 12:20:28 -0000 On Sun, Apr 24, 2011 at 10:26 PM, Chuanhuang Li wrote: > OK, this can solve the problem. We also had used this way to indicate the ARP table having not been flushed. I will update the text before posting. cheers, jamal From jmh@joelhalpern.com Mon Apr 25 07:29:21 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 74010E0751 for ; Mon, 25 Apr 2011 07:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.399 X-Spam-Level: X-Spam-Status: No, score=-102.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5p5IIJZt0oLx for ; Mon, 25 Apr 2011 07:29:21 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes.out.tigertech.net [74.114.88.72]) by ietfc.amsl.com (Postfix) with ESMTP id DDE4BE06B8 for ; Mon, 25 Apr 2011 07:29:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 8C44A4300AE; Mon, 25 Apr 2011 07:29:20 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [192.168.1.14] (pool-96-245-82-167.phlapa.fios.verizon.net [96.245.82.167]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id C2647430035; Mon, 25 Apr 2011 07:29:19 -0700 (PDT) Message-ID: <4DB5853F.4000004@joelhalpern.com> Date: Mon, 25 Apr 2011 10:29:19 -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: <201104221255218779523@mail.zjgsu.edu.cn> <201104250921589037174@mail.zjgsu.edu.cn> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: forces , Chuanhuang Li , wmwang Subject: Re: [forces] NH review WAS(Re: BasicMetadataDispatch WAS(Re: LFB LPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 14:29:21 -0000 The CE normally connected the various elements of the group output port to the successor LFBs. Therefore it know what it connected at which index. In unusual cases, those connections are fixed, or established by an earlier CE. In that case, the CE reads the same structure it would write to set them up, and learns what the connections are. Yours, Joel On 4/25/2011 8:17 AM, Jamal Hadi Salim wrote: > Chuanhuang, > > On Sun, Apr 24, 2011 at 9:21 PM, Chuanhuang Li > wrote: > >> "successout" is an output port group. "LFBOutputSelectIndex" is used to select an output >> from this group. > > Sorry I missed it - it was right there in the text ;-> > I will fix the text and re-post again. > > my brain is slow: how does the CE knows what LFBOutputSelectIndex 32 > bit value is? > I know that the LFB Topology will eventually have an LFB selector > indication for the > port - but how do we go there to the value in LFBOutputSelectIndex of > this table? > > cheers, > jamal > From hadi@mojatatu.com Mon Apr 25 07:36:12 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7CC2CE073F for ; Mon, 25 Apr 2011 07:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.425 X-Spam-Level: X-Spam-Status: No, score=-102.425 tagged_above=-999 required=5 tests=[AWL=0.552, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Ge8nSJCVXWx for ; Mon, 25 Apr 2011 07:36:11 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfc.amsl.com (Postfix) with ESMTP id 44820E06F5 for ; Mon, 25 Apr 2011 07:36:11 -0700 (PDT) Received: by fxm15 with SMTP id 15so1646015fxm.31 for ; Mon, 25 Apr 2011 07:36:10 -0700 (PDT) Received: by 10.223.1.201 with SMTP id 9mr4472916fag.91.1303742170092; Mon, 25 Apr 2011 07:36:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.21.16 with HTTP; Mon, 25 Apr 2011 07:35:50 -0700 (PDT) In-Reply-To: <4DB5853F.4000004@joelhalpern.com> References: <201104221255218779523@mail.zjgsu.edu.cn> <201104250921589037174@mail.zjgsu.edu.cn> <4DB5853F.4000004@joelhalpern.com> From: Jamal Hadi Salim Date: Mon, 25 Apr 2011 10:35:50 -0400 Message-ID: To: "Joel M. Halpern" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: forces , Chuanhuang Li , wmwang Subject: Re: [forces] NH review WAS(Re: BasicMetadataDispatch WAS(Re: LFB LPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 14:36:12 -0000 So the LFBOutputSelectIndex is the table index for table as defined in: FEObject/LFBTopology ? It may need some mention in the text or xml synopsis. cheers, jamal On Mon, Apr 25, 2011 at 10:29 AM, Joel M. Halpern wro= te: > The CE normally connected the various elements of the group output port t= o > the successor LFBs. =A0Therefore it know what it connected at which index= . > In unusual cases, those connections are fixed, or established by an earli= er > CE. =A0In that case, the CE reads the same structure it would write to se= t > them up, and learns what the connections are. > > Yours, > Joel > > On 4/25/2011 8:17 AM, Jamal Hadi Salim wrote: >> >> Chuanhuang, >> >> On Sun, Apr 24, 2011 at 9:21 PM, Chuanhuang Li >> =A0wrote: >> >>> "successout" is an output port group. "LFBOutputSelectIndex" is used to >>> select an output >>> from this group. >> >> Sorry I missed it - it was right there in the text ;-> >> I will fix the text and re-post again. >> >> my brain is slow: =A0how does the CE knows what LFBOutputSelectIndex 32 >> bit value is? >> I know that the LFB Topology will eventually have an LFB selector >> indication for the >> port - but how do we go there to the value in LFBOutputSelectIndex of >> this table? >> >> cheers, >> jamal >> > From joel@stevecrocker.com Mon Apr 25 07:47:13 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 335F8E074C for ; Mon, 25 Apr 2011 07:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.47 X-Spam-Level: X-Spam-Status: No, score=-1.47 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DSL=1.129] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJiHzZQs8t-P for ; Mon, 25 Apr 2011 07:47:12 -0700 (PDT) Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by ietfc.amsl.com (Postfix) with ESMTP id C2585E0682 for ; Mon, 25 Apr 2011 07:47:12 -0700 (PDT) Received: from [96.245.82.167] (HELO [192.168.1.14]) by execdsl.com (CommuniGate Pro SMTP 5.1.16) with ESMTPS id 19577091; Mon, 25 Apr 2011 14:47:47 +0000 Message-ID: <4DB58970.3060401@stevecrocker.com> Date: Mon, 25 Apr 2011 10:47:12 -0400 From: Joel 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: <201104221255218779523@mail.zjgsu.edu.cn> <201104250921589037174@mail.zjgsu.edu.cn> <4DB5853F.4000004@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Joel M. Halpern" , Chuanhuang Li , wmwang , forces Subject: Re: [forces] NH review WAS(Re: BasicMetadataDispatch WAS(Re: LFB LPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 14:47:13 -0000 Yes. And this is the way we work with all output groups. So it seems strange to make a big point of saying so in this document. Yours, Joel On 4/25/2011 10:35 AM, Jamal Hadi Salim wrote: > So the LFBOutputSelectIndex is the table index for table as defined in: > FEObject/LFBTopology ? > It may need some mention in the text or xml synopsis. > > cheers, > jamal > From hadi@mojatatu.com Mon Apr 25 07:56:14 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 75426E0696 for ; Mon, 25 Apr 2011 07:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.436 X-Spam-Level: X-Spam-Status: No, score=-102.436 tagged_above=-999 required=5 tests=[AWL=0.541, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9uscA9rnQxi6 for ; Mon, 25 Apr 2011 07:56:14 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfc.amsl.com (Postfix) with ESMTP id BF8CCE0682 for ; Mon, 25 Apr 2011 07:56:13 -0700 (PDT) Received: by fxm15 with SMTP id 15so1660649fxm.31 for ; Mon, 25 Apr 2011 07:56:13 -0700 (PDT) Received: by 10.223.27.14 with SMTP id g14mr665096fac.129.1303743373096; Mon, 25 Apr 2011 07:56:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.21.16 with HTTP; Mon, 25 Apr 2011 07:55:53 -0700 (PDT) In-Reply-To: <4DB58970.3060401@stevecrocker.com> References: <201104221255218779523@mail.zjgsu.edu.cn> <201104250921589037174@mail.zjgsu.edu.cn> <4DB5853F.4000004@joelhalpern.com> <4DB58970.3060401@stevecrocker.com> From: Jamal Hadi Salim Date: Mon, 25 Apr 2011 10:55:53 -0400 Message-ID: To: Joel Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Joel M. Halpern" , Chuanhuang Li , wmwang , forces Subject: Re: [forces] NH review WAS(Re: BasicMetadataDispatch WAS(Re: LFB LPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 14:56:14 -0000 On Mon, Apr 25, 2011 at 10:47 AM, Joel wrote: > Yes. =A0And this is the way we work with all output groups. =A0 So it see= ms > strange to make a big point of saying so in this document. Well, I couldnt remember - thats why ;-> The only additional text i added was the "Note" at the end of the synopsis: =3D=3D=3D LFBOutputSelectIndex LFB Group output port index to select downstream LFB port. Some possibilities of downstream LFB instances are: a) EtherEncapsulator b) Other type of media LFB c) A metadata Dispatcher d) A redirect LFB e) etc Typically, there will be only one LFB port where one of the above is connected Note: LFBOutputSelectIndex is the table index for table FEObject/LFBTopology for this port uint32 =3D=3D=3D=3D cheers, jamal From chuanhuang_li@mail.zjgsu.edu.cn Mon Apr 25 08:42:27 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id BE905E06E8 for ; Mon, 25 Apr 2011 08:42:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.422 X-Spam-Level: X-Spam-Status: No, score=-0.422 tagged_above=-999 required=5 tests=[AWL=-0.217, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a+YEB+nqZxUH for ; Mon, 25 Apr 2011 08:42:27 -0700 (PDT) Received: from mail.zjgsu.edu.cn (ucmail.zjgsu.edu.cn [124.160.64.1]) by ietfc.amsl.com (Postfix) with SMTP id 32385E06A7 for ; Mon, 25 Apr 2011 08:42:24 -0700 (PDT) Received: from RobinLee (unknown [10.20.0.167]) by mailportal (Coremail) with SMTP id rBCI85DLiTLwk7VNgIQeAA--.24946S2; Mon, 25 Apr 2011 23:32:00 +0800 (CST) Date: Mon, 25 Apr 2011 23:40:23 +0800 From: "Chuanhuang Li" To: "Jamal Hadi Salim" References: <201104221443545647087@mail.zjgsu.edu.cn>, <201104251018350282351@mail.zjgsu.edu.cn> Message-ID: <201104252340233725747@mail.zjgsu.edu.cn> Organization: Zhejiang Gongshang Univercity X-mailer: Foxmail 6, 15, 201, 23 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-CM-TRANSID: rBCI85DLiTLwk7VNgIQeAA--.24946S2 X-Coremail-Antispam: 1Uf129KBjDUn29KB7ZKAUJUUUUUYxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJ3UbIYCTnIWIevJa73UjIFyTuYvj4RJUUUUUUUU X-CM-SenderInfo: pfkxt0xkxd0wxbolqzhdloh6pmjv3hxhgxhubq/ Cc: "Joel M. Halpern" , wmwang , forces Subject: Re: [forces] EtherEncap review WAS(Re: BasicMetadataDispatch WAS(Re: LFB LPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 15:42:27 -0000 SGksSmFtYWwNCj4+IFRoZXNlIGFyZSBvdXIgY29uc2lkZXJhdGlvbiBiZWZvcmUsIGFuZCBoYWQg YmVlbiBkaXNjdXNzZWQgd2l0aCBKb2VsOg0KPj4gKFByZWNvbmRpdGlvbjogbm90IHVzaW5nIHRo ZSAiTWVkaWFFbmNhcEluZm9JbmRleCIuKQ0KPj4gTkggTEZCIHdpbGwgZ2VuZXJhdGUgbmV3IG1l dGFkYXRhczogT3V0cHV0TG9naWNhbFBvcnRJRCwgTmV4dGhvcElQdjRBZGRyLg0KPj4gSW4gdGhl IGVudHJ5IHdoaWNoIGhhdmUgYmVlbiBmb3VuZCwgaWYgIk5leHRob3BPcHRpb24iIGlzIGluZGlj YXRlZCB0aGF0IHRoaXMNCj4+IHBhY2tldCBuZWVkIHRvIGJlIGZvcndhcmRlZCB0byBsb2NhbCBk aXJyZWN0bHkgY29ubmVjdGVkIHN1Ym5ldCBob3N0LCBtZXRhZGF0YQ0KPj4gTmV4dGhvcElQdjRB ZGRyIHdpbGwgYmUgZmlsbGVkIHdpdGggdGhlIGRlc3RpbmF0aW9uIElQIGFkZHJlc3Mgb2YgdGhl IHBhY2tldC4NCj4+IEZvciBub3JtYWwgZm9yd2FyZGluZywgbmV4dCwgdGhlIHBhY2tldCB3aWxs IGJlIHNlbnQgdG8gRXRoZXJFbmNhcHN1bGF0b3IgTEZCLg0KPj4gRXRoZXJFbmNhcHN1bGF0b3Ig d2lsbCB1c2UgT3V0cHV0TG9naWNhbFBvcnRJRCBtZXRhZGF0YSBhcyB0aGUga2V5IG9mIExvZ2lj YWxQb3J0SUQNCj4+IGVsZW1lbnQgdG8gbG9va3VwIFZsYW5PdXRwdXRUYWJsZSB0byBnZXQgVmxh bklEIGFuZCB0aGUgbmV3IE91dHB1dExvZ2ljYWxQb3J0SUQuDQo+PiBUaGVuIGl0IHdpbGwgdXNl IHRoaXMgbmV3IE91dHB1dExvZ2ljYWxQb3J0SUQgYW5kIE5leHRob3BJUHY0QWRkciBtZXRhZGF0 YSB0byBsb29rdXANCj4+IEFycFRhYmxlIHRvIGdldCB0aGUgb3V0cHV0IEV0aGVybmV0IEwyIGlu Zm9ybWF0aW9uLiBBZnRlciBwcm9jZXNzZWQgaW4gdGhpcyBMRkIsDQo+PiBtZXRhZGF0YSBPdXRw dXRMb2dpY2FsUG9ydElEIHdpbGwgYmUgdXBkYXRlZC4NCj4+IEluIHRoaXMgc2ltcGxlIGNhc2Us IEV0aGVyRW5jYXBzdWxhdG9yIHdpbGwgZGVsaXZlciBwYWNrZXRzIHRvIHRoZSBjb3JyZWN0IHBo eXNpY2FsIHBvcnQNCj4+IGRpcmVjdGx5LiCgQW5kIHRoZSBPdXRwdXRMb2dpY2FsUG9ydElEIGlz IGV4YWN0bHkgdGhlIFBIWVBvcnRJRCBpbmZvcm1hdGlvbi4NCj4+IEhvd2V2ZXIsIGlmIHRoZSBk ZXZpY2UgaXMgZG9pbmcgYnJpZGdpbmcgYXMgd2VsbCBhcyByb3V0aW5nIChvciBicmlkZ2luZyBw bHVzDQo+PiBob3N0IGFwcGxpY2F0aW9ucw0KPj4gbGlrZSBtYW5hZ2VtZW50IG9yIGNvbnNvbGUg c2VydmljZXMpLCB0aGVuIGFmdGVyIHRoZSBlbmNhcHN1bGF0aW9uLCBhbGwgdGhhdA0KPj4gRXRo ZXJFbmNhcHN1bGF0b3INCj4+IGtub3dzIGlzIHdoYXQgbG9naWNhbCBwb3J0IHRoZSBwYWNrZXQg aXMgdG8gYmUgc2VudCBvbi4goFRoZSBwYWNrZXQgbXVzdCBiZSBoYW5kZWQgdG8NCj4+IHRoZSBi cmlkZ2luZyBsb2dpYywgd2hpY2ggd2lsbCB1c2UgdGhlIGxvZ2ljYWwgb3V0cHV0IHBvcnQgYW5k IHRoZSBkZXN0aW5hdGlvbiBNQUMgYWRkcmVzcw0KPj4gdG8gZGVjaWRlIHdoYXQgcGh5c2ljYWwg cG9ydCB0byBzZW5kIHRoZSBmcmFtZSBvbiwgaW5jbHVkaW5nIHRoZSBwb3NzaWJpbGl0eSB0aGF0 IGl0IG1heSBuZWVkDQo+PiB0byBmbG9vZCB0aGUgcGFja2V0IG91dCBzZXZlcmFsIHBoeXNpY2Fs IHBvcnRzLCBvciBhZGQgYWRkaXRpb25hbCBicmlkZ2luZyBlbmNhcHN1bGF0aW9ucy4NCj4+DQo+ PiBJIHRoaW5rLCBJZiB3ZSB1c2UgIk1lZGlhRW5jYXBJbmZvSW5kZXgiIGFuZCBtZXJnZSBWTEFO IG91dHB1dCB0YWJsZSBpbnRvIG1lZGlhIGVuYXAgdGFibGUsDQo+PiBhbiBlbGVtZW50LCBzdWNo IGFzIG5hbWVkICJMMlBvcnRJRCIsIG5lZWQgdG8gYmUgYWRkZWQgaW50byB0aGUgZW5jYXAgdGFi bGUuDQo+Pg0KPg0KPldlIGFscmVhZHkgaGF2ZSBPdXRwdXRMb2dpY2FsUG9ydElEIC0gZG8geW91 IG1lYW4gd2UgbmVlZCB0byBjaGFuZ2UgdGhlDQo+bmFtZSB0byBMMlBvcnRJRD8NCj4NCkV4YWN0 bHksIEknbSB0aGlua2luZyBob3cgdG8ga25vdyB0aGUgTDJQb3J0SUQob3IgUEhZUG9ydElEKSAs IElmIHRoZSB0d28gdGFibGVzIHdlcmUgDQptZXJnZWQgYW5kIHRoZSBtZXJnZWQgdGFibGUgd2Fz IHNlYXJjaGVkIGJ5ICJNZWRpYUVuY2FwSW5mb0luZGV4IiBrZXkuIFdoZXJlIHdpbGwgdGhlIEwz UG9ydElEIA0KbWV0YWRhdGEgYmUgY29uc3VtZWQgaW4gdGhlIHNpbXBsZSByb3V0aW5nIGNhc2Ug Pw0KDQpZb3VycywNCkNodWFuaHVhbmcNCg== From joel@stevecrocker.com Mon Apr 25 08:45:23 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 43B24E06A9 for ; Mon, 25 Apr 2011 08:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.87 X-Spam-Level: X-Spam-Status: No, score=-0.87 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HELO_EQ_DSL=1.129, J_CHICKENPOX_16=0.6, J_CHICKENPOX_25=0.6] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qO2dFvnSmmMU for ; Mon, 25 Apr 2011 08:45:21 -0700 (PDT) Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by ietfc.amsl.com (Postfix) with ESMTP id DD554E06A7 for ; Mon, 25 Apr 2011 08:45:21 -0700 (PDT) Received: from [96.245.82.167] (HELO [192.168.1.14]) by execdsl.com (CommuniGate Pro SMTP 5.1.16) with ESMTPS id 19577218; Mon, 25 Apr 2011 15:45:56 +0000 Message-ID: <4DB59711.7050306@stevecrocker.com> Date: Mon, 25 Apr 2011 11:45:21 -0400 From: Joel 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: Chuanhuang Li References: <201104221443545647087@mail.zjgsu.edu.cn>, <201104251018350282351@mail.zjgsu.edu.cn> <201104252340233725747@mail.zjgsu.edu.cn> In-Reply-To: <201104252340233725747@mail.zjgsu.edu.cn> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: forces , "Joel M. Halpern" , wmwang Subject: Re: [forces] EtherEncap review WAS(Re: BasicMetadataDispatch WAS(Re: LFB LPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 15:45:23 -0000 Remember that if there are LFBs between the NH lFB and the mediaencap LFB we will need to know which L3 port processing media encap LFB we need to hand the packet to. As such, we need the L3 port ID as a metadatum passed through the system. Yours, Joel On 4/25/2011 11:40 AM, Chuanhuang Li wrote: > Hi,Jamal >>> These are our consideration before, and had been discussed with Joel: >>> (Precondition: not using the "MediaEncapInfoIndex".) >>> NH LFB will generate new metadatas: OutputLogicalPortID, NexthopIPv4Addr. >>> In the entry which have been found, if "NexthopOption" is indicated that this >>> packet need to be forwarded to local dirrectly connected subnet host, metadata >>> NexthopIPv4Addr will be filled with the destination IP address of the packet. >>> For normal forwarding, next, the packet will be sent to EtherEncapsulator LFB. >>> EtherEncapsulator will use OutputLogicalPortID metadata as the key of LogicalPortID >>> element to lookup VlanOutputTable to get VlanID and the new OutputLogicalPortID. >>> Then it will use this new OutputLogicalPortID and NexthopIPv4Addr metadata to lookup >>> ArpTable to get the output Ethernet L2 information. After processed in this LFB, >>> metadata OutputLogicalPortID will be updated. >>> In this simple case, EtherEncapsulator will deliver packets to the correct physical port >>> directly. And the OutputLogicalPortID is exactly the PHYPortID information. >>> However, if the device is doing bridging as well as routing (or bridging plus >>> host applications >>> like management or console services), then after the encapsulation, all that >>> EtherEncapsulator >>> knows is what logical port the packet is to be sent on. The packet must be handed to >>> the bridging logic, which will use the logical output port and the destination MAC address >>> to decide what physical port to send the frame on, including the possibility that it may need >>> to flood the packet out several physical ports, or add additional bridging encapsulations. >>> >>> I think, If we use "MediaEncapInfoIndex" and merge VLAN output table into media enap table, >>> an element, such as named "L2PortID", need to be added into the encap table. >>> >> We already have OutputLogicalPortID - do you mean we need to change the >> name to L2PortID? >> > Exactly, I'm thinking how to know the L2PortID(or PHYPortID) , If the two tables were > merged and the merged table was searched by "MediaEncapInfoIndex" key. Where will the L3PortID > metadata be consumed in the simple routing case ? > > Yours, > Chuanhuang > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces From chuanhuang_li@mail.zjgsu.edu.cn Mon Apr 25 08:49:45 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 26414E06BE for ; Mon, 25 Apr 2011 08:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.604 X-Spam-Level: X-Spam-Status: No, score=-1.604 tagged_above=-999 required=5 tests=[AWL=0.996, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fT2oXO-oW8SI for ; Mon, 25 Apr 2011 08:49:44 -0700 (PDT) Received: from mail.zjgsu.edu.cn (ucmail.zjgsu.edu.cn [124.160.64.1]) by ietfc.amsl.com (Postfix) with SMTP id C8836E0664 for ; Mon, 25 Apr 2011 08:49:43 -0700 (PDT) Received: from RobinLee (unknown [10.20.0.167]) by mailportal (Coremail) with SMTP id rBCI85DrjDuolbVNgIQeAA--.24961S2; Mon, 25 Apr 2011 23:39:20 +0800 (CST) Date: Mon, 25 Apr 2011 23:47:44 +0800 From: "Chuanhuang Li" To: "Jamal Hadi Salim" , "Joel" References: <201104221255218779523@mail.zjgsu.edu.cn>, <201104250921589037174@mail.zjgsu.edu.cn>, , <4DB5853F.4000004@joelhalpern.com>, , <4DB58970.3060401@stevecrocker.com> Message-ID: <201104252347439979478@mail.zjgsu.edu.cn> Organization: Zhejiang Gongshang Univercity X-mailer: Foxmail 6, 15, 201, 23 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-CM-TRANSID: rBCI85DrjDuolbVNgIQeAA--.24961S2 X-Coremail-Antispam: 1Uf129KBjDUn29KB7ZKAUJUUUUUYxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJ3UbIYCTnIWIevJa73UjIFyTuYvj4RJUUUUUUUU X-CM-SenderInfo: pfkxt0xkxd0wxbolqzhdloh6pmjv3hxhgxhubq/ Cc: "Joel M. Halpern" , wmwang , forces Subject: Re: [forces] NH review WAS(Re: BasicMetadataDispatch WAS(Re: LFB LPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 15:49:45 -0000 Hi, Jamal >=== > > LFBOutputSelectIndex > LFB Group output port index to select > downstream LFB port. Some possibilities > of downstream LFB instances are: > a) EtherEncapsulator > b) Other type of media LFB > c) A metadata Dispatcher > d) A redirect LFB > e) etc > Typically, there will be only one LFB port where > one of the above is connected > Note: LFBOutputSelectIndex is the table index > for table FEObject/LFBTopology for this port > > uint32 > 1)Typically, there may be more LFBs connected to the group output ports at the same time. For example, RedirectOut LFB and EtherEncapsulator(or metadata Dispatcher) will connect after NH, if the media is Ethernet. 2) I don't think "LFBOutputSelectIndex" is the table index for LFBTopology table. LFBOutputSelectIndex is just the NH group output index. For the static LFB topology, as Joel said, CE can knows what indexes NH are using to connect with some LFBs. Please see the LFBLinkType definition in FEObject LFB: LFBLinkType Link between two LFB instances of topology FromLFBID LFB src LFBSelectorType FromPortGroup src port group string FromPortIndex src port index uint32 ........... If FE supports dynamic topology, CE will reconfig the link relationship by itself. That is, what index will be set is charged by CE . (CE knows all the possible indexes which was limited in the "SupportedLFBs" capability in FEObject LFB.) Yours, Chuanhuang From hadi@mojatatu.com Mon Apr 25 09:13:59 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 92112E06C7 for ; Mon, 25 Apr 2011 09:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.447 X-Spam-Level: X-Spam-Status: No, score=-102.447 tagged_above=-999 required=5 tests=[AWL=0.530, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jmftiQpevYAa for ; Mon, 25 Apr 2011 09:13:59 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfc.amsl.com (Postfix) with ESMTP id E3B2CE0664 for ; Mon, 25 Apr 2011 09:13:58 -0700 (PDT) Received: by fxm15 with SMTP id 15so1712104fxm.31 for ; Mon, 25 Apr 2011 09:13:58 -0700 (PDT) Received: by 10.223.35.8 with SMTP id n8mr1152919fad.72.1303748038100; Mon, 25 Apr 2011 09:13:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.21.16 with HTTP; Mon, 25 Apr 2011 09:13:38 -0700 (PDT) In-Reply-To: <201104252347439979478@mail.zjgsu.edu.cn> References: <201104221255218779523@mail.zjgsu.edu.cn> <201104250921589037174@mail.zjgsu.edu.cn> <4DB5853F.4000004@joelhalpern.com> <4DB58970.3060401@stevecrocker.com> <201104252347439979478@mail.zjgsu.edu.cn> From: Jamal Hadi Salim Date: Mon, 25 Apr 2011 12:13:38 -0400 Message-ID: To: Chuanhuang Li Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Joel M. Halpern" , wmwang , forces Subject: Re: [forces] NH review WAS(Re: BasicMetadataDispatch WAS(Re: LFB LPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 16:13:59 -0000 Hi Chuanhuang, On Mon, Apr 25, 2011 at 11:47 AM, Chuanhuang Li wrote: > Hi, Jamal > > 1)Typically, there may be more LFBs connected to the group output ports a= t the same time. For > example, RedirectOut LFB and EtherEncapsulator(or metadata Dispatcher) wi= ll connect after NH, > if the media is Ethernet. > I can remove the sentence that starts with "Typically..." > 2) I don't think "LFBOutputSelectIndex" =A0is the table index for LFBTopo= logy table. > LFBOutputSelectIndex is just the NH group output index. > =A0For the static LFB topology, as Joel said, CE can knows what indexes N= H are > using to connect with some LFBs. Please see the LFBLinkType definition in > FEObject LFB: I think you are right - still we need to make that clear. So i am assuming this is the FromPortIndex 32-bit value that is of interest here. cheers, jamal From hadi@mojatatu.com Mon Apr 25 09:19:32 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D1F6EE075C for ; Mon, 25 Apr 2011 09:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.157 X-Spam-Level: X-Spam-Status: No, score=-102.157 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6khLfwIM8tEf for ; Mon, 25 Apr 2011 09:19:32 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfc.amsl.com (Postfix) with ESMTP id C13D2E0750 for ; Mon, 25 Apr 2011 09:19:31 -0700 (PDT) Received: by fxm15 with SMTP id 15so1715562fxm.31 for ; Mon, 25 Apr 2011 09:19:31 -0700 (PDT) Received: by 10.223.35.8 with SMTP id n8mr1159547fad.72.1303748371092; Mon, 25 Apr 2011 09:19:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.21.16 with HTTP; Mon, 25 Apr 2011 09:19:11 -0700 (PDT) In-Reply-To: References: <201104221255218779523@mail.zjgsu.edu.cn> <201104250921589037174@mail.zjgsu.edu.cn> <4DB5853F.4000004@joelhalpern.com> <4DB58970.3060401@stevecrocker.com> <201104252347439979478@mail.zjgsu.edu.cn> From: Jamal Hadi Salim Date: Mon, 25 Apr 2011 12:19:11 -0400 Message-ID: To: Chuanhuang Li Content-Type: multipart/mixed; boundary=00151747578489171404a1c09236 Cc: "Joel M. Halpern" , wmwang , forces Subject: Re: [forces] NH review WAS(Re: BasicMetadataDispatch WAS(Re: LFB LPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 16:19:33 -0000 --00151747578489171404a1c09236 Content-Type: text/plain; charset=ISO-8859-1 And here are my notes so far for NH. Please take a look at the XXX parts as well as the other parts carefully. [I have a few other things i would like to move on once i can hand this and the Etherencap over to you.] cheers, jamal --00151747578489171404a1c09236 Content-Type: text/plain; charset=US-ASCII; name="NH-suggested.txt" Content-Disposition: attachment; filename="NH-suggested.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gmxm2z5w0 CkdlbmVyYWwKPT09PT09PQoxKSBXZSBuZWVkIHRvIGJlIGNvbnNpc3RlbnQgYW5kIGFjdHVhbGx5 IGRlZmluZSByaWdodCBhdCB0aGUgCmJlZ2luaW5nIHdoYXQgInVwc3RyZWFtIiBhbmQgImRvd25z dHJlYW0iIExGQiBtZWFucy4KSW4gbXkgdmlldyBiZWxvdywgYnkgZG93bnN0cmVhbSBJIG1lYW4g d2hlcmUgdGhlIHBhY2tldCBmbG93IGlzCmdvaW5nLiBQbGVhc2UgZG91YmxlIGNoZWNrIGFsbCB0 aGUgdGV4dCBpbiB0aGUgZHJhZnQgZm9yIHRoaXMKY29uc2lzdGVuY3kuLgoKMikgR2VuZXJhbCBx dWVzdGlvbjoKPG91dHB1dFBvcnQgZ3JvdXA9InRydWUiPiBhcyBpbmRpY2F0ZWQgaW4gdGhlIE5I IExGQjoKd2hlbiBpbiBnZW5lcmFsIGRvZXMgaXQgbWFrZSBzZW5zZSB0byBoYXZlIGl0IGFzICJ0 cnVlIiB2cyAiZmFsc2UiCmFuZCB3aGVyZSBpcyB0aGlzIGRlc2NyaWJlZD8KCjMpWFhYOiBXZSBu ZWVkIHRvIGNvbWUgdXAgd2l0aCB0ZXh0IHRoYXQgbWVudGlvbnMgTkhNb2RJRC9OSEZFSUQgCndo aWNoIHdoaWxlIG91dCBvZiBzY29wZSBpbiB0aGlzIGRvY3VtZW50IGhhcyBjb21lIHVwIGluIG1h bnkKZGlzY3Vzc2lvbnMuIFdlIGp1c3QgbmVlZCB0byBwcm92aWRlIHNvbWUgZXhhbXBsZXMgb24g aG93IGl0IGNhbiBiZSAKYWNoaWV2ZWQuCgpMRkI6IElQdlhOZXh0SG9wCj09PT09PT09PT09PT09 PT0KCjEpSSBkb250IHRoaW5rIE5leHRob3BJRCAoY29tcG9uZW50SUQ9IjEiKSBzaG91bGQgYmUg cGFydCBvZiB0aGUgdGFibGUuClRoZSBwYXNzZWQgTmV4dGhvcElEIGlzIGFuIF9pbmRleF8gaW50 byB0aGUgTmV4dEhvcFRhYmxlIGFuZCBkb2VzIG5vdApuZWVkIHRvIGJlIHBhcnQgb2YgdGhlIHRh YmxlLgoKMilSZW5hbWluZyBPdXRwdXRMb2dpY2FsUG9ydElEIHRvIEwzUG9ydElEIGZvciByZWFk YWJpbGl0eS4KCgkgICAgPGNvbXBvbmVudCBjb21wb25lbnRJRD0iPz8iPgogICAgICAgICAgICAg ICAgPG5hbWU+TDNQb3J0SUQ8L25hbWU+CiAgICAgICAgICAgICAgICA8c3lub3BzaXM+VGhlIElE IG9mIHRoZSBMb2dpY2FsL3BoeXNpY2FsIE91dHB1dCBQb3J0CiAgICAgICAgICAgICAgICAgICAg ICAgICAgdGhhdCB3ZSBwYXNzIG9udG8gdGhlIG5laWdoYm9yaW5nIExGQiBpbnN0YW5jZS4KICAg ICAgICAgICAgICAgICAgICAgICAgICBUaGlzIElEIGluZGljYXRlcyB3aGF0IHBvcnQgdG8gdGhl IG5laWdoYm9yIGlzCgkJCSAgYXMgZGVmaW5lZCBieSBMMy4KICAgICAgICAgICAgICAgIDwvc3lu b3BzaXM+CiAgICAgICAgICAgICAgICA8dHlwZVJlZj51aW50MzI8L3R5cGVSZWY+CiAgICAgICAg ICAgICA8L2NvbXBvbmVudD4KCjMpIEFkZCBhIG5ldyBlbnRyeSwgTWVkaWFFbmNhcEluZm9JbmRl eCB0byBiZSB1c2VkIGJ5IG5leHQgTEZCIGZvciBsb29rdXAuCgogICAgICAgICAgICA8Y29tcG9u ZW50IGNvbXBvbmVudElEPSI/PyI+CiAgICAgICAgICAgICAgICA8bmFtZT5NZWRpYUVuY2FwSW5m b0luZGV4PC9uYW1lPgogICAgICAgICAgICAgICAgPHN5bm9wc2lzPlRoZSBpbmRleCB3ZSBwYXNz IG9udG8gdGhlIG5laWdoYm9yaW5nIExGQiBpbnN0YW5jZS4KICAgICAgICAgICAgICAgICAgICAg ICAgICBUaGlzIGluZGV4IGlzIHVzZWQgdG8gbG9va3VwIGEgdGFibGUgKHR5cGljYWxseSAKCQkJ ICBtZWRpYSBlbmNhcHN1bGF0YXRpb24gcmVsYXRlZCkgZnVydGhlciBkb3duc3RyZWFtLgogICAg ICAgICAgICAgICAgPC9zeW5vcHNpcz4KICAgICAgICAgICAgICAgIDx0eXBlUmVmPnVpbnQzMjwv dHlwZVJlZj4KICAgICAgICAgICAgIDwvY29tcG9uZW50PgoKCjQpUmVuYW1pbmcgRW5jYXBPdXRw dXRJbmRleCB0byBMRkJPdXRwdXRTZWxlY3RJbmRleCB0byBpbmRpY2F0ZQp3aGljaCBMRkIgcG9y dCB3ZSBhcmUgc2VsZWN0aW5nIHRvIGdvIHRvIHRoZSBkb3duc3RyZWFtIExGQiBpbnN0YW5jZS4K CiAgICAgICAgICAgICA8Y29tcG9uZW50IGNvbXBvbmVudElEPSI/Ij4KICAgICAgICAgICAgICAg IDxuYW1lPkxGQk91dHB1dFNlbGVjdEluZGV4PC9uYW1lPgogICAgICAgICAgICAgICAgPHN5bm9w c2lzPkxGQiBHcm91cCBvdXRwdXQgcG9ydCBpbmRleCB0byBzZWxlY3QKICAgICAgICAgICAgICAg ICAgICAgICAgICBkb3duc3RyZWFtIExGQiBwb3J0LiBTb21lIHBvc3NpYmlsaXRpZXMKICAgICAg ICAgICAgICAgICAgICAgICAgICBvZiBkb3duc3RyZWFtIExGQiBpbnN0YW5jZXMgYXJlOgoJCQkg ICAgYSkgRXRoZXJFbmNhcHN1bGF0b3IKCQkJICAgIGIpIE90aGVyIHR5cGUgb2YgbWVkaWEgTEZC CgkJCSAgICBjKSBBIG1ldGFkYXRhIERpc3BhdGNoZXIKCQkJICAgIGQpIEEgcmVkaXJlY3QgTEZC CgkJCSAgICBlKSBldGMgCgkJCSBOb3RlOiBMRkJPdXRwdXRTZWxlY3RJbmRleCBpcyB0aGUgRnJv bVBvcnRJbmRleAoJCQkgZm9yIHRoZSBwb3J0IGdyb3VwICJzdWNjZXNzb3V0IiBpbiB0aGUgdGFi bGUgCiAgICAgICAgICAgICAgICAgICAgICAgICBMRkJUb3BvbG9neSAob2YgRkVPYmplY3QgTEZC KSBhcyBkZWZpbmVkIGZvciAKCQkJIHRoZSBOSCBMRkIuCiAgICAgICAgICAgICAgICA8L3N5bm9w c2lzPgogICAgICAgICAgICAgICAgPHR5cGVSZWY+dWludDMyPC90eXBlUmVmPgogICAgICAgICAg ICAgPC9jb21wb25lbnQ+Cgo0KURlZmluZSBhIHNjaGVtZSB0byBpbmRpY2F0ZSB0aGF0IEV0aGVy RW5jYXAgZGV0YWlscyBhcmUgdW5yZXNvbHZlZCAKYXQgdGhpcyBwb2ludC4gTWV0aG9kcyB0aGF0 IGhhdmUgYmVlbiBkaXNjdXNzZWQgc28gZmFyOgoKYSlDRSBzZXRzIE1lZGlhRW5jYXBJbmZvSW5k ZXggcG9ydCB0byBhIHZhbHVlIHRoYXQgaXMgbm90IGFsbG9jYXRlZAppbiBFdGhlckVuY2FwIEVu Y2FwVGFibGUuIEV0aGVyRW5jYXAgbG9va3VwIHdpbGwgZmFpbCB0byBmaW5kIGl0LgpXaGljaCBp cyBpbmRpY2F0aW9uIHNvbWUgb3RoZXIgd2F5IHRvIHJlc29sdmUgaXQgbWF5IGJlIG5lZWRlZC4K CmIpIGVsZW1lbnQgbmFtZWQgc3VjaCBhcyAiRmlsbEZsYWciIHRvIGluZGljYXRlIHdoZXRoZXIg dGhlIHRhYmxlIAplbnRyeSBoYWQgYmVlbiBmaWxsZWQuIEJ1dCB0aGVuIHdlIG5lZWQgdG8gcGFz cyB0aGlzIGluZm8gYXMgbWV0YWRhdGEuCgojYSBpcyBhc3N1bW5lZCBwZXItZGlzY3Vzc2lvbiB3 aXRoIENodWFuaHVhbmcuCgo1KSBPdGhlciBjb21tZW50cyBhYm91dCBJUHZ4TmV4dEhvcDoKCmEp IGNhbiB3ZSBjaGFuZ2UgbGFuZ3VhZ2UgbGlrZSAiZm9yIGFwcGxpY2F0aW5nIG5leHQgaG9wIGFj dGlvbiIgCnRvIHNvbWV0aGluZyBsaWtlICJmb3Igc2VsZWN0aW5nIG5leHQgaG9wIGFjdGlvbiIK CkRhdGEgSGFuZGxpbmcKLS0tLS0tLS0tLS0tLQoKSW5jb21pbmcgTmV4dGhvcGlkIG1ldGFkYXRh IGlzIHVzZWQgYXMgYW4gaW5kZXggdG8gbG9va3VwIHRoZSB0YWJsZS4KRGF0YSBwcm9jZXNzaW5n IGludm9sdmVzIHRoZSBmb3J3YXJkaW5nIFRUTCBkZWNyZW1lbnQgYW5kIGNoZWNrc3VtIApyZWNh bGN1bGF0aW9uLiBPbiBzdWNjZXNzZnVsIGRhdGEgcHJvY2Vzc2luZyB0aGUgcGFja2V0IGlzIHNl bnQgb3V0CmFuIExGQi1wb3J0IGZyb20gd2l0aGluIHRoZSBMRkIgcG9ydCBncm91cCAiU3VjY2Vz c091dCIgYXMgc2VsZWN0ZWQgYnkKTEZCT3V0cHV0U2VsZWN0SW5kZXggdmFsdWUgb2YgdGhlIG1h dGNoZWQgdGFibGUgZW50cnkuIApUaGUgcGFja2V0IGlzIHNlbnQgdG8gYSBkb3duc3RyZWFtIExG QiBpbnN0YW5jZSBhbG9uZ3NpZGUgCndpdGggbmV3IG1ldGFkYXRhOiBUaGUgTDNQb3J0SUQgYW5k IE1lZGlhRW5jYXBJbmZvSW5kZXguClhYWDogRG8gd2UgbmVlZCB0byBzYXkgd2hlcmUgdGhlc2Ug bWV0YWRhdGEgYXJlIGNvbnN1bWVkPwoKSWYgZGF0YSBwcm9jZXNzaW5nIGZhaWxzLCB0aGUgcGFj a2V0IGlzIHNlbnQgb3V0IG9uIHRoZSAiZXhjZXB0aW9uIiAKb3V0cHV0IGFsb25nIHdpdGggYW4g YWRkaXRpb25hbCBleGNlcHRpb25JRCBtZXRhZGF0YS4KClhYWDogQWN0dWFsbHkgdGhpcyBhcHBs aWVzIHRvIHRoZSBkcmFmdCBpbiBnZW5lcmFsOgpEbyB3ZSBuZWVkIElBTkEgaWRzIGZvciB0aGUg cG9ydHMgaW4gIExGQiBwb3J0IGdyb3VwPwpXaGF0IGFib3V0IGV4Y2VwdGlvbiBJRHM/CgpEb3du c3RyZWFtIG5laWdoYm9yaW5nIExGQiBpbnN0YW5jZXMgY291bGQgYmUgZWl0aGVyIGFuIEV0aGVy RW5jYXAgCnR5cGUgb3IgYSBCYXNpY01ldGFkYXRhRGlzcGF0Y2ggdHlwZS4KCkp1c3RpZmljYXRp b24gZm9yIGNob2ljZSBvZiBkb3duc3RyZWFtIExGQiBpbnN0YW5jZQo9PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KCkluIHNjZW5hcmlvcyB3aGVyZSB0 aGUgZmluYWwgcGFja2V0IEwyIHByb2Nlc3NpbmcgaXMgcG9zc2libGUgdG8gCmJlIG9uIHBlci1t ZWRpYS1wb3J0IGJhc2lzIG9yIG9uIGEgZGlmZmVyZW50IEZFIHRoZSBtb2RlbCBtYWtlcyBzZW5z ZQp0byB1c2UgYSBCYXNpY01ldGFkYXRhRGlzcGF0Y2ggTEZCIHRvIGZhbm91dCB0byBkaWZmZXJl bnQgTEZCIGluc3RhbmNlcy4KKHJlZmVyIHRvIGZpZ3VyZSBYWFggd2hpY2ggc2hvd3MgaG93IHRo aXMgd291bGQgd29yaykuCkluIHNjZW5hcmlvcyB3aGVyZSB0aGVyZSBpcyBhIGNlbnRyYWxpemVk IEwyIGhlYWRlciBlbmNhcHN1bGF0aW9uCnBvaW50LCB0aGVuIHRoZSBtb2RlbCBtYWtlcyBzZW5z ZSB0byBoYXZlIGEgZG93bnN0cmVhbSBMRkIgaW5zdGFuY2UKYmUgYW4gRXRoZXJFbmNhcCAoYXMg ZGVtb25zdHJhdGVkIGluIEZpZ3VyZSAxKS4KWFhYOiBFeHBsYWluIGluIHN1bW1hcnkgaG93IHRo ZSBMRkJPdXRwdXRTZWxlY3RJbmRleCBhbmQgCkwzUG9ydElEIGFyZSB1c2VkIGluIGJvdGggTEZC cy4KWFhYOiB0ZXh0IGhlcmUgdG8gZGVzY3JpYmUgdGhlIGRpZmZlcmVudCBleGNlcHRpb25zIHRo YXQgY291bGQKCg== --00151747578489171404a1c09236-- From hadi@mojatatu.com Mon Apr 25 09:25:28 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 35DB3E075C for ; Mon, 25 Apr 2011 09:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.261 X-Spam-Level: X-Spam-Status: No, score=-101.261 tagged_above=-999 required=5 tests=[AWL=-0.684, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_16=0.6, J_CHICKENPOX_25=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id om6hrJ05fwoB for ; Mon, 25 Apr 2011 09:25:27 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfc.amsl.com (Postfix) with ESMTP id AC8BAE0758 for ; Mon, 25 Apr 2011 09:25:26 -0700 (PDT) Received: by fxm15 with SMTP id 15so1719333fxm.31 for ; Mon, 25 Apr 2011 09:25:26 -0700 (PDT) Received: by 10.223.1.201 with SMTP id 9mr4591058fag.91.1303748726081; Mon, 25 Apr 2011 09:25:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.21.16 with HTTP; Mon, 25 Apr 2011 09:25:06 -0700 (PDT) In-Reply-To: <4DB59711.7050306@stevecrocker.com> References: <201104221443545647087@mail.zjgsu.edu.cn> <201104251018350282351@mail.zjgsu.edu.cn> <201104252340233725747@mail.zjgsu.edu.cn> <4DB59711.7050306@stevecrocker.com> From: Jamal Hadi Salim Date: Mon, 25 Apr 2011 12:25:06 -0400 Message-ID: To: Joel Content-Type: multipart/mixed; boundary=20cf3054a461b1c81804a1c0a751 Cc: "Joel M. Halpern" , Chuanhuang Li , wmwang , forces Subject: Re: [forces] EtherEncap review WAS(Re: BasicMetadataDispatch WAS(Re: LFB LPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 16:25:28 -0000 --20cf3054a461b1c81804a1c0a751 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ok, here's my handover text to Chuanhuang so i can move over to the next issues i have. There are a few XXX in there to point to uncertainties. cheers, jamal On Mon, Apr 25, 2011 at 11:45 AM, Joel wrote: > Remember that if there are LFBs between the NH lFB and the mediaencap LFB= we > will need to know which L3 port processing media encap LFB we need to han= d > the packet to. =A0As such, we need the L3 port ID as a metadatum passed > through the system. > > Yours, > Joel > > On 4/25/2011 11:40 AM, Chuanhuang Li wrote: >> >> Hi,Jamal >>>> >>>> These are our consideration before, and had been discussed with Joel: >>>> (Precondition: not using the "MediaEncapInfoIndex".) >>>> NH LFB will generate new metadatas: OutputLogicalPortID, >>>> NexthopIPv4Addr. >>>> In the entry which have been found, if "NexthopOption" is indicated th= at >>>> this >>>> packet need to be forwarded to local dirrectly connected subnet host, >>>> metadata >>>> NexthopIPv4Addr will be filled with the destination IP address of the >>>> packet. >>>> For normal forwarding, next, the packet will be sent to >>>> EtherEncapsulator LFB. >>>> EtherEncapsulator will use OutputLogicalPortID metadata as the key of >>>> LogicalPortID >>>> element to lookup VlanOutputTable to get VlanID and the new >>>> OutputLogicalPortID. >>>> Then it will use this new OutputLogicalPortID and NexthopIPv4Addr >>>> metadata to lookup >>>> ArpTable to get the output Ethernet L2 information. After processed in >>>> this LFB, >>>> metadata OutputLogicalPortID will be updated. >>>> In this simple case, EtherEncapsulator will deliver packets to the >>>> correct physical port >>>> directly. =A0And the OutputLogicalPortID is exactly the PHYPortID >>>> information. >>>> However, if the device is doing bridging as well as routing (or bridgi= ng >>>> plus >>>> host applications >>>> like management or console services), then after the encapsulation, al= l >>>> that >>>> EtherEncapsulator >>>> knows is what logical port the packet is to be sent on. =A0The packet = must >>>> be handed to >>>> the bridging logic, which will use the logical output port and the >>>> destination MAC address >>>> to decide what physical port to send the frame on, including the >>>> possibility that it may need >>>> to flood the packet out several physical ports, or add additional >>>> bridging encapsulations. >>>> >>>> I think, If we use "MediaEncapInfoIndex" and merge VLAN output table >>>> into media enap table, >>>> an element, such as named "L2PortID", need to be added into the encap >>>> table. >>>> >>> We already have OutputLogicalPortID - do you mean we need to change the >>> name to L2PortID? >>> >> Exactly, I'm thinking how to know the L2PortID(or PHYPortID) , If the tw= o >> tables were >> merged and the merged table was searched by "MediaEncapInfoIndex" key. >> Where will the L3PortID >> metadata be consumed in the simple routing case ? >> >> Yours, >> Chuanhuang >> _______________________________________________ >> forces mailing list >> forces@ietf.org >> https://www.ietf.org/mailman/listinfo/forces > > --20cf3054a461b1c81804a1c0a751 Content-Type: text/plain; charset=US-ASCII; name="ee-suggested.txt" Content-Disposition: attachment; filename="ee-suggested.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gmxmavv60 CkxGQjogRXRoZXJFbmNhcAo9PT09PT09PT09PT09PT0KCjApIE5vdGUgZGlzYXBwZWFyYW5jZSBv ZiBBUlAvTkQgZnJvbSB0aGlzIGRyYWZ0LiBBbHNvCm5vdGUgdGhpcyBMRkIgaXMgYWdub3N0aWMg b2YgSVBWNCBvciBJUHY2LgoKMSkgRml4IDxtZXRhZGF0YUV4cGVjdGVkPiB0byBoYXZlIEwzUG9y dElEIChhcyBwYXNzZWQgZnJvbSBOSCkgaW5zdGVhZCAKb2YgTG9naWNhbFBvcnRJRCBhbmQgbm90 ZSB0aGF0IGl0IGlzIG9wdGlvbmFsIChhcyBjdXJyZW50bHkgZGVzY3JpYmVkKS4KWFhYOiBOb3Rl IHRoYXQgdGhpcyBtZXRhZGF0YSBtYXRjaGVzIEwyUG9ydElEIGluIHRoZSB0YWJsZT8/CgoyKSBB ZGQgdG8gPG1ldGFkYXRhRXhwZWN0ZWQ+IHRvIGluY2x1ZGUgTWVkaWFFbmNhcEluZm9JbmRleC4K VGhpcyBpcyBhIG5vbi1vcHRpb25hbCBtZXRhZGF0YSBhbmQgaXMgdXNlZCB0byBsb29rdXAgRW5j YXBUYWJsZS4KCjMpIFdlIGhhdmUgYW4gYWx0ZXJuYXRpdmUgdGFibGUga25vd24gYXMgRW5jYXBU YWJsZSB3aGljaCBpcyB2ZXJ5IGNsb3NlIHRvCkFycFRhYmxlL05iclRhYmxlLiBXZSBvbmx5IG5l ZWQgb25lIHRhYmxlIGZvciBib3RoIElQVjQgYW5kIElQVjYuClNvIGFzc3VtZSBhcyBhIHN0YXJ0 aW5nIHBvaW50IG9uZSBvZiB0aGVzZS4KCmkgICkgVGhlIHBhc3NlZCBNZWRpYUVuY2FwSW5mb0lu ZGV4IGlzIGFuIF9pbmRleF8gaW50byB0aGUgRW5jYXBUYWJsZSAKYW5kIHRoZXJlZm9yZSBkb2Vz IG5vdCBuZWVkIHRvIGJlIHBhcnQgb2YgdGhlIHRhYmxlLgoKaWkgKSBEc3RJUHZ4QWRkcmVzcyBp cyBuZXZlciB1c2VkIGluIHRoaXMgTEZCLgoKaWlpKSBXZSBtZXJnZSB0aGUgVkxBTiBvdXRwdXQg dGFibGUgaW50byBFbmNhcFRhYmxlLgoKdGhlIHRhYmxlIGVudHJ5IGxvb2tzIGxpa2U6CgogICAg ICAgPGRhdGFUeXBlRGVmPgogICAgICAgICAgPG5hbWU+RW5jYXBUYWJsZVR5cGU8L25hbWU+CiAg ICAgICAgICA8c3lub3BzaXM+RXRoZXJuZXQgRW5jYXBzdWxhdGlvbiB0YWJsZSBlbnRyeSB0eXBl Ljwvc3lub3BzaXM+CiAgICAgICAgICA8c3RydWN0PgogICAgICAgICAgICAgPGNvbXBvbmVudCBj b21wb25lbnRJRD0iMSI+CiAgICAgICAgICAgICAgICA8bmFtZT5Ec3RNYWM8L25hbWU+CiAgICAg ICAgICAgICAgICA8c3lub3BzaXM+RXRoZXJuZXQgTWFjIG9mIHRoZSBOZWlnaGJvcjwvc3lub3Bz aXM+CiAgICAgICAgICAgICAgICA8dHlwZVJlZj5JRUVFTUFDPC90eXBlUmVmPgogICAgICAgICAg ICAgPC9jb21wb25lbnQ+CiAgICAgICAgICAgICA8Y29tcG9uZW50IGNvbXBvbmVudElEPSIyIj4K ICAgICAgICAgICAgICAgIDxuYW1lPlNyY01hYzwvbmFtZT4KICAgICAgICAgICAgICAgIDxzeW5v cHNpcz5Tb3VyY2UgTUFDIHVzZWQgaW4gZW5jYXBzdWxhdGlvbjwvc3lub3BzaXM+CiAgICAgICAg ICAgICAgICA8dHlwZVJlZj5JRUVFTUFDPC90eXBlUmVmPgogICAgICAgICAgICAgPC9jb21wb25l bnQ+CiAgICAgICAgICAgICA8Y29tcG9uZW50IGNvbXBvbmVudElEPSIzIj4KICAgICAgICAgICAg ICAgIDxuYW1lPlZsYW5JRDwvbmFtZT4KICAgICAgICAgICAgICAgIDxzeW5vcHNpcz5WTEFOIElE Ljwvc3lub3BzaXM+CiAgICAgICAgICAgICAgICA8dHlwZVJlZj51aW50MzI8L3R5cGVSZWY+CiAg ICAgICAgICAgICA8L2NvbXBvbmVudD4KICAgICAgICAgICAgIDxjb21wb25lbnQgY29tcG9uZW50 SUQ9IjQiPgogICAgICAgICAgICAgICAgPG5hbWU+TDJQb3J0SUQ8L25hbWU+CiAgICAgICAgICAg ICAgICA8c3lub3BzaXM+T3V0cHV0IGxvZ2ljYWwgTDIgcG9ydCBJRC48L3N5bm9wc2lzPgogICAg ICAgICAgICAgICAgPHR5cGVSZWY+dWludDMyPC90eXBlUmVmPgogICAgICAgICAgICAgPC9jb21w b25lbnQ+CiAgICAgICAgICA8L3N0cnVjdD4KICAgICAgIDwvZGF0YVR5cGVEZWY+CgoKWFhYOiBU aGUgVmxhbklEIHR5cGUgbG9va3Mgd3JvbmcuIEJ1dCBJIGp1c3QgY29waWVkIHRoaXMgZnJvbSB0 aGUgY3VycmVudAp0ZXh0ClhYWDogV2UgYXJlIG1lcmdpbmcgdGhlIHNvdXJjZSBhbmQgZGVzdGlu YXRpb24gaW5mb3JtYXRpb24gb24gdGhlCnNhbWUgdGFibGUgKHNvbWUgaW1wbGVtZW50YXRpb25z IG1heSBoYXZlIHRoZW0gaW4gc2VwYXJhdGUgdGFibGVzKS4KV2UgYXJlIGFzc3VtaW5nIHRoZSBt ZXJnZWQgdmVyc2lvbiBwcm92aWRlcyBhIGdlbmVyYWwgdmlldy4uLgpXZSBuZWVkIHRvIHNheSB0 aGlzIGluIHRoZSB0ZXh0IHRvIGF2b2lkIGltcGxlbWVudGF0aW9uIGRldGFpbGVkIHF1ZXN0aW9u cy4KCgpEYXRhIEhhbmRsaW5nCi0tLS0tLS0tLS0tLS0KUGFja2V0cyBhbG9uZ3NpZGUgbWV0YWRh dGEgYXJlIHJlY2VpdmVkIG9uIHRoaXMgTEZCIHZpYSB0aGUKIkVuY2FwSW4iIGlucHV0IExGQi4g VGhlIHVwc3RyZWFtIExGQiBjbGFzc2VzIG1heWJlIHRoZSBkaWZmZXJlbnQgCk5leHRIb3AgTEZC cyBzdWNoIGFzIElQdjROZXh0SG9wIGFuZCBJUHY2TmV4dEhvcCBvciBtYXliZSAKQmFzaWNNZXRh ZGF0YURpc3BhdGNoIG9yIGV2ZW4gTDIgYnJpZGdpbmcgKHdoaWNoIGlzIG91dCBvZiBzY29wZSBp biAKdGhpcyBkb2N1bWVudCkuCkluIHRoZSBjYXNlIG9mIGlucHV0IGNvbWluZyBmcm9tIGFueSBv ZiB0aGUgSVAgTmV4dEhvcCBMRkIgY2xhc3NlcywKdGhlIE5leHRob3BJUHY0QWRkciBvciBOZXh0 aG9wSVB2NkFkZHIgaXMgcGFzc2VkIGluIGFzIG1ldGFkYXRhCnRvIHRoaXMgTEZCLiAKVGhlIE5l eHRob3BJUHY0QWRkciBvciBOZXh0aG9wSVB2NkFkZHIgaXMgb3B0aW9uYWwuCkFub3RoZXIgb3B0 aW9uYWwgbWV0YWRhdGEgcGFzc2VkIGJ5IHVwc3RyZWFtIExGQnMgaXMgdGhlIEwzUG9ydElELgpU aGUgdXBzdHJlYW0gTEZCIE1VU1QgcGFzcyB0aGUgTWVkaWFFbmNhcEluZm9JbmRleC4KClRoZSBt ZXRhZGF0YSBNZWRpYUVuY2FwSW5mb0luZGV4IGlzIHVzZWQgYXMgYW4gaW5kZXggdG8gbG9va3Vw IHRoZSAKRW5jYXAgVGFibGUuClVwb24gYSBzdWNjZXNzZnVsIHRhYmxlIGxvb2t1cCwgdGhlIGRl c3RpbmF0aW9uIGFuZCBzb3VyY2UgTUFDIGFkZHJlc3NlcywKYW5kIHRoZSBsb2dpY2FsIG1lZGlh IHBvcnQgKEwyUG9ydElEKSBhcmUgZm91bmQgaW4gdGhlIG1hdGNoaW5nCnRhYmxlIGVudHJ5LiBU aGUgQ0UgbWF5IHNldCB0aGUgVmxhbklkIGluIGNhc2UgVkxBTnMgYXJlIHVzZWQuCkJ5IGRlZmF1 bHQgdGhlIHRhYmxlIGVudHJ5IGZvciBWTEFOSUQgb2YgMCBpcyB1c2VkIGFzIHBlciBJRUVFIHJ1 bGVzLgoKWFhYOiBEYXRhIHByb2Nlc3NpbmcgaW52b2x2ZXMgcmVwbGFjaW5nIG9yIGF0dGFjaGlu ZyB0aGUgYXBwcm9wcmlhdGUKRXRoZXJuZXQgaGVhZGVycyB0byB0aGUgcGFja2V0LgpBZnRlciBk YXRhIHByb2Nlc3NpbmcgaXMgY29tcGxldGUsIHRoZSBwYWNrZXQgaXMgcGFzc2VkIG91dCBvbiAK dGhlICJTdWNjZXNzT3V0IiBMRkIgcG9ydCB0byBhIGRvd25zdHJlYW0gTEZCIGluc3RhbmNlIGFs b25nc2lkZSB3aXRoIAp0aGUgTDJQb3J0SUQuClhYWDogaXMgTDNQb3J0SUQgKGZyb20gTkgpIGNv bnN1bWVkIGhlcmUgb3Igc2hvdWxkIHdlIApiZSB1c2luZyB0aGUgdGVybSBMMlBvcnRJRCBmb3Ig Ym90aD8KCkl0IGlzIHBvc3NpYmxlIGZvciB0aGUgRW5jYXBUYWJsZSBsb29rdXAgdG8gZmFpbC4g VGhlIE5IIExGQiBtYXkgCmJlIHByb2dyYW1tZWQgYnkgdGhlIENFIHRvIHBhc3MgYWxvbmcgYSBN ZWRpYUVuY2FwSW5mb0luZGV4IHRoYXQgZG9lc250IGV4aXN0IAppbiB0aGUgRW5jYXBUYWJsZS4g VGhlIHJlYXNvbiBmb3IgdGhpcyBpcyB0byBhbGxvdyBmb3IgcmVzb2x1dGlvbiBvZiB0aGUgCkwy IGhlYWRlcnMsIGlmIG5lZWRlZCwgdG8gYmUgbWFkZSBhdCB0aGUgTDIgZW5jYXBzdWxhdGlvbiBs ZXZlbAppbiB0aGlzIGNhc2UoZXRoZXJuZXQpIHZpYSBBUlAsIG9yIE5EIChvciBvdGhlciBtZXRo b2RzIGRlcGVuZGluZyBvbiB0aGUgCmxpbmsgbGF5ZXIgdGVjaG5vbG9neSkgd2hlbiBhIHRhYmxl IG1pc3Mgb2NjdXJzLgpJZiB0YWJsZSBsb29rdXAgZmFpbHMsIHRoZSBwYWNrZXQgaXMgc2VudCBv dXQgb24gdGhlICJleGNlcHRpb24iIApvdXRwdXQgYWxvbmcgd2l0aCBhbiBhZGRpdGlvbmFsIGV4 Y2VwdGlvbklEIG1ldGFkYXRhLgoKRm9yIG5laWdoYm9yIEwyIGhlYWRlciByZXNvbHV0aW9uKHRh YmxlIG1pc3MgZXhjZXB0aW9uKSwgdGhlIHByb2Nlc3NpbmcgCkxGQiBtYXkgcGFzcyB0aGlzIHBh Y2tldCB0byB0aGUgQ0UgdmlhIHRoZSByZWRpcmVjdCBMRkIgb3IgRkUgc29mdHdhcmUgCm9yIGFu b3RoZXIgTEZCIGluc3RhbmNlIGZvciBmdXJ0aGVyIHJlc29sdXRpb24uIEluIHN1Y2ggYSBjYXNl IHRoZSBtZXRhZGF0YSAKbmV4dCBob3AgaXAgKHY0IG9yIHY2KSBpcyBhbHNvIHBhc3NlZCB0byB0 aGUgZXhjZXB0aW9uIGhhbmRsaW5nLiBTdWNoIGFuIApJUCBhZGRyZXNzIGNvdWxkIGJlIHVzZWQg dG8gZG8gYWN0aXZpdGllcyBzdWNoIGFzIEFSUCBvciBORCBieSB0aGUgaGFuZGxlciAKaXQgaXMg cGFzc2VkIHRvLgpUaGUgcmVzdWx0IG9mIHRoZSBMMiByZXNvbHV0aW9uIGlzIHRvIHVwZGF0ZSB0 aGUgRW5jYXBUYWJsZSBhcyB3ZWxsCmFzIHRoZSBOSCBMRkIgc28gc3Vic2VxdWVudCBwYWNrZXRz IGRvbnQgZmFpbCBFbmNhcCB0YWJsZSBsb29rdXAuIApUaGUgRXRoZXJFbmNhcCBMRkIgZG9lcyBu b3QgbWFrZSBhbnkgYXNzdW1wdGlvbnMgb2YgaG93IHRoZSBFbmNhcFRhYmxlCmlzIHVwZGF0ZWQg YnkgdGhlIENFIChvciB3aGV0aGVyIEFSUC9ORCBpcyB1c2VkIGR5bmFtaWNhbGx5IG9yCnN0YXRp YyBtYXBzIGV4aXN0KS4KCkRvd25zdHJlYW0gbmVpZ2hib3JpbmcgTEZCIGluc3RhbmNlcyBjb3Vs ZCBiZSBlaXRoZXIgYW4gRXRoZXJNQUNPdXQgCnR5cGUoc2hvd24gaW4gZmlndXJlIHh4eCkgb3Ig YSBCYXNpY01ldGFkYXRhRGlzcGF0Y2ggdHlwZSAoc2hvd24gCmluIEZpZ3VyZSAxKS4KCkp1c3Rp ZmljYXRpb24gZm9yIGNob2ljZSBvZiBkb3duc3RyZWFtIExGQiBpbnN0YW5jZQo9PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KCkluIHNjZW5hcmlvcyB3 aGVyZSB0aGUgZmluYWwgcGFja2V0IEwyIHByb2Nlc3NpbmcgaXMgcG9zc2libGUgdG8gCmJlIG9u IHBlci1tZWRpYS1wb3J0IGJhc2lzIG9yIHJlc2lkZXMgb24gYSBkaWZmZXJlbnQgRkUgb3IgaW4g Y2FzZXMgd2hlcmUKTDIgaGVhZGVyIHJlc29sdXRpb24gaXMgbmVlZGVkLCB0aGVuIHRoZSBtb2Rl bCBtYWtlcyBzZW5zZSB0byB1c2UgYSAKQmFzaWNNZXRhZGF0YURpc3BhdGNoIExGQiB0byBmYW5v dXQgdG8gZGlmZmVyZW50IExGQiBpbnN0YW5jZXMuCihyZWZlciB0byBmaWd1cmUgMSB3aGljaCBz aG93cyBob3cgdGhpcyB3b3VsZCB3b3JrKS4KSW4gc2NlbmFyaW9zIHdoZXJlIHRoZXJlIGlzIGEg ZGlyZWN0IGVncmVzcyBwb3J0IHBvaW50LCB0aGVuIHRoZSBtb2RlbCAKbWFrZXMgc2Vuc2UgdG8g aGF2ZSBhIGRvd25zdHJlYW0gTEZCIGluc3RhbmNlIGJlIGFuIEV0aGVyTUFDT3V0IChhcyAKZGVt b25zdHJhdGVkIGluIEZpZ3VyZSB4eHgpLgoKWFhYOiB0ZXh0IGhlcmUgdG8gZGVzY3JpYmUgdGhl IGRpZmZlcmVudCBleGNlcHRpb25zIHRoYXQgY291bGQKCkFQUEVORElYCj09PT09PT09CgpYWFg6 IEZpbmQgc29tZXdoZXJlIHRvIHB1dCB0aGlzIHRleHQgc28gd2UgYXZvaWQgcXVlc3Rpb25zIGlu IHRoZQpmdXR1cmUuIEl0IGlzIGNvcGllZCBmcm9tIGVtYWlsIGkgc2VudCBlYXJsaWVyLgoKSSB3 aWxsIHByb3ZpZGUgc29tZSBjb250ZXh0IHNvIG90aGVyIHBlb3BsZSBjYW4gZm9sbG93IC0gc28g dGhpcyBpcyBnb2luZyB0bwphIGxvbmcgZW1haWwuIEF1dGhvcnMgcGxlYXNlIGNvcnJlY3QgbWUg aWYgaSBtaXN1bmRlcnN0b29kLgpUaGVyZSBpcyBhIGN1cnJlbnQgb3B0aW1pemF0aW9uIGZvciBk aXJlY3RseSBjb25uZWN0ZWQgcm91dGVzIGFzIGRlZmluZWQgYnkKZHJhZnQtMDMgYWNoaWV2ZWQg YnkgdGhlIHByZXNlbmNlIG9mIEFSUCBpbiB0aGUgRXRoZXJFbmNhcHN1bGF0b3IgTEZCLgoKVGhl IEFSUCB0YWJsZSwgbG9va2VkIHVzaW5nICBOZXh0SG9wSVAgYWRkcmVzcyBtZXRhZGF0LCBvbiBz dWNjZXNzIHdpbGwgbWF0Y2gKZGlyZWN0bHkgY29ubmVjdGVkIHJvdXRlcyBhbmQgYWxsb3dzIHVz IHRvIHNlbmQgb3V0IHRvIHRoZSBvbiBsaW5rIGhvc3Qgd2l0aAp0aGUgY29ycmVjdCBkc3RtYWMg YW5kIG1lZGlhIHBvcnQgd2l0aG91dCByZXF1aXJpbmcgdXMgdG8gc3RvcmUgdGhpcyByb3V0aW5n CmVudHJ5IGluIHRoZSBMUE0uClRoZSBvcHRpbWl6YXRpb24gaW4gdGhpcyBjYXNlIGlzIHRoYXQg aSkgd2UgZG9udCBoYXZlIG1hbnkgZW50cmllcyBpbiB0aGUgTFBNCnRhYmxlIGFuZCBpaSkgaXQg c2VwYXJhdGVzIHRoZSBkaXJlY3RseSBjb25uZWN0ZWQgcm91dGVzIGZyb20gbm9uLWRpcmVjdCBv bmVzLgoKV2hpbGUgaSBhZ3JlZSB0aGF0IHRoZSBvcHRpbWl6YXRpb24gbWF5IGJlIG9mIHZhbHVl IHRvIHNheSBhbiBlZGdlIHJvdXRlcgood2hpY2ggaGFzIHByZXNlbmNlIG9mIG1hbnkgZGlyZWN0 IGhvc3RzKSwgSSBoYXZlIGNvdW50ZXItYXJndWVtZW50cy4KSSB3b3VsZCBhcmd1ZSAodXNpbmcg SVBWNCBhcyBhbiBleGFtcGxlKToKCi0gZnJvbSBhIG1vZGVsIGFic3RyYWN0aW9uIHZpZXcsIExQ TSAobm90IEFSUCkgaXMgdGhlIHByb3BlciBhYnN0cmFjdGlvbgpmb3IgIkwzIExvb2t1cHMiLgot IHRoZSBvcHRpbWl6YXRpb24gaXMgb2Ygbm8gdmFsdWUgdG8gYSBjb3JlIHJvdXRlciB3aXRoIHZl cnkgZmV3IGhvc3RzCmNvbm5lY3RlZC4KLSB0aGUgbnVtYmVyIG9mIHRhYmxlIGVudHJpZXMgYXJl IG5vIGRpZmZlcmVudCBpZiB5b3UgcHV0IHRoZXNlIHRhYmxlIGVudHJpZXMKaW4gdGhlIEFSUCBv ciBMUE0gdGFibGVzLiBpLmUgaWYgeW91IGhhdmUgMTAgZGlyZWN0bHkgY29ubmVjdGVkIGhvc3Rz LCB5b3UKd2lsbCBlaXRoZXIgaGF2ZSAxMCBBUlAgZW50cmllcyBvciAxMCBMUE0gZW50cmllcy4K LSB0aGUgYXBwcm9hY2ggZGVzY3JpYmVkIGluIC0wMyBpcyBpbXBsZW1lbnRhdGlvbiBzcGVjaWZp Yy4gSSBoYXZlIHNlZW4KaW1wbGVtZW50YXRpb25zIHdoaWNoIGFkZHJlc3MgdGhpcyBpc3N1ZSB2 aWEgdHdvIGxldmVscyBvZiBsb29rdXBzLgpGaXJzdCB5b3UgbG9va3VwIGFuIExQTSBmb3IgZGly ZWN0bHkgY29ubmVjdGVkIGhvc3RzIChMb25nZXN0IHByZWZpeCkKdXNpbmcgb25lIGFsZ29yaXRo IHdoaWNoIGlzIGVmZmljaWVudCBmb3IgLzMyIHRoZW4gIHlvdSBsb29rdXAgdGhlIG5leHQKTFBN IGZvciBwcmVmaXhlcyBvdGhlciB0aGFuIC8zMi4gSW4gc3VjaCBhbiBpbXBsZW1lbnRhdGlvbiB3 ZSBkb250IG5lZWQKdG8gaGF2ZSBBUlAgYW5kIGFzc3VtaW5nIGEgbWFuZGF0b3J5IHByZXNlbmNl IG9mIEFSUCBqdXN0IGNvbXBsaWNhdGVzCnRoaW5ncy4KClNvIG15IHN1Z2dlc3Rpb24gaXMgdGhp cyBzaG91bGQgc3RheSBvdXQgb2YgdGhlIG1vZGVsLiBUaGUgbW9kZWwgd291bGQKc3RpbGwgc3Vw cG9ydCB0aGUgZGVzY3JpYmVkIHRleHQgYnkgYXNzdW1pbmcgdGhhdCBldGhlcmVuY2FwIGNhbiBi ZSBjb25uZWN0ZWQKdmlhIGFuIExGQi1wb3J0IHRvIEFSUCBmb3IgZXhjZXB0aW9uIGhhbmRsaW5n LiBBbmQgdGhhdCB0aGUgQVJQIHRhYmxlIGNhbgpoYXZlIHRoZXNlIGRldGFpbHMgYXMgZGVzY3Jp YmVkIGluIEwzIGFuZCBmb3J3YXJkIG9uIHRoZSBwYWNrZXQgdG8gdGhlIGhvc3QuCgpIYXZpbmcg c2FpZCB0aGF0OgpXZSBzaG91bGQgaGF2ZSB0ZXh0IGRpc2N1c3NpbmcgdGhpcyBpc3N1ZSBzbyB3 ZSBkb250IGhhdmUgdG8gZ28gc2NhbiBlbWFpbHMKbGF0ZXIgdG8gZmlndXJlIGhvdyB3ZSByZWFj aGVkIHRoZSBkZWNpc2lvbi4K --20cf3054a461b1c81804a1c0a751-- From jmh@joelhalpern.com Mon Apr 25 09:34:04 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9377FE06CC for ; Mon, 25 Apr 2011 09:34:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.424 X-Spam-Level: X-Spam-Status: No, score=-102.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bsTqMEcGTsEr for ; Mon, 25 Apr 2011 09:34:04 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes.out.tigertech.net [74.114.88.72]) by ietfc.amsl.com (Postfix) with ESMTP id 10F81E06A9 for ; Mon, 25 Apr 2011 09:34:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 8A0CA4300CB; Mon, 25 Apr 2011 09:34:03 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [192.168.1.14] (pool-96-245-82-167.phlapa.fios.verizon.net [96.245.82.167]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id B6C9B4300EF; Mon, 25 Apr 2011 09:34:02 -0700 (PDT) Message-ID: <4DB5A27A.6020004@joelhalpern.com> Date: Mon, 25 Apr 2011 12:34:02 -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: <201104221255218779523@mail.zjgsu.edu.cn> <201104250921589037174@mail.zjgsu.edu.cn> <4DB5853F.4000004@joelhalpern.com> <4DB58970.3060401@stevecrocker.com> <201104252347439979478@mail.zjgsu.edu.cn> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: forces , Chuanhuang Li , wmwang Subject: Re: [forces] NH review - general items X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 16:34:04 -0000 Commenting on your general items: 1) I agree, using downstream and upstream relative to the flow of packets makes sense. 2) is the way, as defined by the model, on e declares that a given output port from instances of a given LFB class is a group output port. Yours, Joel On 4/25/2011 12:19 PM, Jamal Hadi Salim wrote: > And here are my notes so far for NH. Please take a look at the XXX > parts as well as the other parts carefully. > > [I have a few other things i would like to move on once i can hand this > and the Etherencap over to you.] > > cheers, > jamal From hadi@mojatatu.com Mon Apr 25 09:47:07 2011 Return-Path: X-Original-To: forces@ietfc.amsl.com Delivered-To: forces@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id AF5F6E075B for ; Mon, 25 Apr 2011 09:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.528, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iRMzYcQrWpcy for ; Mon, 25 Apr 2011 09:47:07 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfc.amsl.com (Postfix) with ESMTP id E00E6E06A9 for ; Mon, 25 Apr 2011 09:47:06 -0700 (PDT) Received: by fxm15 with SMTP id 15so1735828fxm.31 for ; Mon, 25 Apr 2011 09:47:06 -0700 (PDT) Received: by 10.223.27.14 with SMTP id g14mr785885fac.129.1303750026162; Mon, 25 Apr 2011 09:47:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.21.16 with HTTP; Mon, 25 Apr 2011 09:46:46 -0700 (PDT) In-Reply-To: <4DB5A27A.6020004@joelhalpern.com> References: <201104221255218779523@mail.zjgsu.edu.cn> <201104250921589037174@mail.zjgsu.edu.cn> <4DB5853F.4000004@joelhalpern.com> <4DB58970.3060401@stevecrocker.com> <201104252347439979478@mail.zjgsu.edu.cn> <4DB5A27A.6020004@joelhalpern.com> From: Jamal Hadi Salim Date: Mon, 25 Apr 2011 12:46:46 -0400 Message-ID: To: "Joel M. Halpern" Content-Type: text/plain; charset=ISO-8859-1 Cc: forces , Chuanhuang Li , wmwang Subject: Re: [forces] NH review - general items X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 16:47:07 -0000 On Mon, Apr 25, 2011 at 12:34 PM, Joel M. Halpern wrote: > Commenting on your general items: > > 1) I agree, using downstream and upstream relative to the flow of packets > makes sense. > > 2) is the way, as defined by the model, on e > declares that a given output port from instances of a given LFB class is a > group output port. Indeed. RFC 5812 is very clear - i was being lazy. cheers, jamal From hadi@mojatatu.com Tue Apr 26 04:01:48 2011 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88F84E06B6 for ; Tue, 26 Apr 2011 04:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.148 X-Spam-Level: X-Spam-Status: No, score=-102.148 tagged_above=-999 required=5 tests=[AWL=0.829, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eobcHWxXJgGZ for ; Tue, 26 Apr 2011 04:01:47 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 337DCE06B7 for ; Tue, 26 Apr 2011 04:01:47 -0700 (PDT) Received: by fxm15 with SMTP id 15so393695fxm.31 for ; Tue, 26 Apr 2011 04:01:46 -0700 (PDT) Received: by 10.223.35.8 with SMTP id n8mr693296fad.72.1303815706138; Tue, 26 Apr 2011 04:01:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.21.16 with HTTP; Tue, 26 Apr 2011 04:01:26 -0700 (PDT) From: Jamal Hadi Salim Date: Tue, 26 Apr 2011 07:01:26 -0400 Message-ID: To: forces@ietf.org Content-Type: multipart/mixed; boundary=00151747578404578304a1d040a8 Cc: Chuanhuang Li , wmwang , "Joel M. Halpern" Subject: [forces] LFBlib readability suggestions X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 11:01:48 -0000 --00151747578404578304a1d040a8 Content-Type: text/plain; charset=ISO-8859-1 to the authors, As i have whined before, the general draft text is hard to read. I think making things a little more formal as in the example LFB in RFC 5812 section 8 will go a long way to improve readability. I have attempted to redo the EtherPHYCop section, I didnt go 100% with the RFC5812 format but please take a look in particular the "XXX" and cross reference with: - the text that exists right now in the draft - the xml (and also to make sure it is well described) - the formal scheme to describe things as i laid it out. The model draft LFB example in section 8 is a good start. cheers, jamal --00151747578404578304a1d040a8 Content-Type: text/plain; charset=US-ASCII; name="section5-comment1.txt" Content-Disposition: attachment; filename="section5-comment1.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gmyq47yz0 CjUuMS4xLiAgRXRoZXJQSFlDb3AKCkV0aGVyUEhZQ29wIExGQiBhYnN0cmFjdHMgYW4gRXRoZXJu ZXQgaW50ZXJmYWNlIHBoeXNpY2FsIGxheWVyIHdpdGgKbWVkaWEgbGltaXRlZCB0byBjb3BwZXIu Cgo1LjEuMS4xLiAgRGF0YSBIYW5kbGluZwoKICAgVGhpcyBMRkIgaXMgdGhlIGludGVyZmFjZSB0 byB0aGUgRXRoZXJuZXQgcGh5c2ljYWwgbWVkaWEuCiAgIFRoZSBMRkIgaGFuZGxlcyBldGhlcm5l dCBmcmFtZXMgY29taW5nIGluIGZyb20gb3IgZ29pbmcKICAgb3V0IG9mIHRoZSBGRS4gRXRoZXJu ZXQgZnJhbWVzIHNlbnQgYW5kIHJlY2VpdmVkIGFyZSBvZgogICB0eXBlICdFdGhlcm5ldEFsbCcg YXMgZGVmaW5lZCBpbiB0aGUgWE1MIGluIGJsYWggYmxhaC4uLi4KClhYWDogTm90ZSB0aGUgZm9y bWF0IGhlcmUgLSBJIGFtIGRlc2NyaWJpbmcgdGhlIGRpZmZlcmVudCBpbnB1dHMgYW5kIG91dHB1 dHMKaW4gYSBzbGlnaHRseSBmb3JtYWwgd2F5Li4KCiAgICogRXRoZXJuZXQgZnJhbWVzIGFyZSBy ZWNlaXZlZCBmcm9tIHRoZSBwaHlzaWNhbCBtZWRpYSBwb3J0IGFuZCBwYXNzZWQgCiAgIGRvd25z dHJlYW0gdG8gTEZCcyBzdWNoIGFzIEV0aGVyTUFDSW4gdmlhIGEgc2luZ2xldG9uIG91dHB1dCBr bm93biBhcyAKICAgIkV0aGVyUEhZT3V0Ii4gQSAnUEhZUG9ydElEJyBtZXRhZGF0YSwgdG8gaW5k aWNhdGUgd2hpY2ggcGh5c2ljYWwgcG9ydCAKICAgdGhlIGZyYW1lIGNhbWUgaW50byBmcm9tIHRo ZSBleHRlcm5hbCB3b3JsZCwgaXMgcGFzc2VkIGFsb25nIHdpdGggdGhlCiAgIGZyYW1lLgoKICAg KiBFdGhlcm5ldCBwYWNrZXRzIGFyZSByZWNlaXZlZCBieSB0aGlzIExGQiBmcm9tIHVwc3RyZWFt IExGQnMgc3VjaAogICBFdGhlck1hY091dCB2aWEgdGhlIHNpbmdsZXRvbiBpbnB1dCBrbm93biBh cyAiRXRoZXJQSFlJbiIgYmVmb3JlIGJlaW5nCiAgIHNlbnQgb3V0IG9udG8gdGhlIGV4dGVybmFs IHdvcmxkLgoKNS4xLjEuMi4gIENvbXBvbmVudHMsIENhcGFiaWxpdGllcyBhbmQgRXZlbnRzCgpY WFg6IEl0IG1heSBtYWtlIHNlbnNlIHRvIGhhdmUgZWFjaCBvZiBDb21wb25lbnRzLCBDYXBhYmls aXRpZXMgYW5kIEV2ZW50cwpvbiBpdHMgb3duIHNlY3Rpb24/CgogICBUaGUgQWRtaW5TdGF0dXMg Y29tcG9uZW50IGlzIGRlZmluZWQgZm9yIENFIHRvIGFkbWluaXN0cmF0aXZlbHkgbWFuYWdlIAog ICB0aGUgc3RhdHVzIG9mIHRoZSBMRkIuIFRoZSBDRSBtYXkgYWRtaW5zdHJhdGl2ZWx5IHN0YXJ0 dXAgb3Igc2h1dGRvd24gCiAgIHRoZSBMRkIgYnkgY2hhbmdpbmcgdGhlIHZhbHVlIG9mIEFkbWlu U3RhdHVzLiBUaGUgZGVmYXVsdCB2YWx1ZSBpcyAKICAgc2V0IHRvICdEb3duJy4KCiAgIEFuIE9w ZXJTdGF0dXMgY29tcG9uZW50IGNhcHR1cmVzIHRoZSBwaHlzaWNhbCBwb3J0IG9wZXJhdGlvbmFs IHN0YXR1cy4KICAgQSBQSFlQb3J0U3RhdHVzQ2hhbmdlZCBldmVudCBpcyBkZWZpbmVkIHNvIHRo ZSBMRkIgY2FuIHJlcG9ydCB0byB0aGUgQ0UgCiAgIHdoZW5ldmVyIHRoZXJlIGlzIGFuIG9wZXJh dGlvbmFsIHN0YXR1cyBjaGFuZ2Ugb2YgdGhlIHBoeXNpY2FsIHBvcnQuCgpYWFg6IEkgY29waWVk IHRoaXMgZnJvbSB0aGUgZHJhZnQgYnV0IGkgdGhpbmsgaXQgbWF5IGJlIHdyb25nLiBUaGUKeG1s IHNheXMgdGhpcyBjb21wb25lbnQgaXMgcmVhZC1vbmx5LiBBbmQgaSByZW1lbWJlciB3ZSBoYWQg YSB2ZXJ5CmxvbmcgZGlzY3Vzc2lvbiAocmVmZXIgdG8gaG93IG9uZSB3b3VsZCBtYXAgYSBwb3J0 IG5hbWUgdG8gdGhlIFBIWQpvbiBob3cgdGhpcyBJRCBpcyB0byBiZSB1c2VkKS4KICAgVGhlIFBI WVBvcnRJRCBjb21wb25lbnQgaXMgZGVmaW5lZCBzbyB0aGUgQ0UgY2FuIGFzc2lnbiBhbiBJRCB0 byAKICAgdGhlIHBoeXNpY2FsIHBvcnQuICBUaGUgY29tcG9uZW50IHdpbGwgYmUgdXNlZCB0byBw cm9kdWNlIG1ldGFkYXRhIAogICBhc3NvY2lhdGVkIHdpdGggZXZlcnkgRXRoZXJuZXQgcGFja2V0 IHRoZSBMRkIgcmVjZWl2ZXMgZnJvbSBtZWRpYSAKICAgYW5kIGlzIGdvaW5nIHRvIGhhbmQgdG8g bGF0ZXIgTEZCcyBmb3IgZnVydGhlciBwcm9jZXNzaW5nLgoKICAgQSBncm91cCBvZiBjb21wb25l bnRzIGFyZSBkZWZpbmVkIGZvciBsaW5rIHNwZWVkIG1hbmFnZW1lbnQuICBUaGUKICAgQWRtaW5M aW5rU3BlZWQgaXMgZm9yIENFIHRvIGNvbmZpZ3VyZSBwcm9wZXIgbGluayBzcGVlZCBmb3IgdGhl IHBvcnQKICAgYW5kIHRoZSBPcGVyTGlua1NwZWVkIGlzIGZvciBDRSB0byBxdWVyeSB0aGUgYWN0 dWFsIGxpbmsgc3BlZWQgaW4KICAgb3BlcmF0aW9uLiAgVGhlIGRlZmF1bHQgdmFsdWUgZm9yIHRo ZSBBZG1pbkxpbmtTcGVlZCBpcyBzZXQgdG8gYXV0by0KICAgbmVnb3RpYXRpb24gbW9kZS4gIEEg U3VwcG9ydGVkTGlua1NwZWVkIGNhcGFiaWxpdHkgYXR0cmlidXRlIGlzIGFsc28KICAgZGVmaW5l ZCBmb3IgQ0UgdG8gcXVlcnkgdGhlIGxpbmsgc3BlZWQgYWJpbGl0eS4gIEEgTGlua1NwZWVkQ2hh bmdlZAogICBldmVudCBpcyBkZWZpbmVkIGZvciB0aGUgTEZCIHRvIHJlcG9ydCB0byBDRSB3aGVu ZXZlciB0aGVyZSBpcyBhIGxpbmsKICAgc3BlZWQgY2hhbmdlIGR1cmluZyBvcGVyYXRpb24uCgog ICBBIGdyb3VwIG9mIGNvbXBvbmVudHMgYXJlIGRlZmluZWQgZm9yIGR1cGxleCBtb2RlIG1hbmFn ZW1lbnQuICBUaGUKICAgQWRtaW5EdXBsZXhNb2RlIGlzIGZvciBDRSB0byBjb25maWd1cmUgcHJv cGVyIGR1cGxleCBtb2RlIGZvciB0aGUKICAgcG9ydCBhbmQgdGhlIE9wZXJEdXBsZXhNb2RlIGlz IGZvciBDRSB0byBxdWVyeSB0aGUgYWN0dWFsIGR1cGxleCBtb2RlCiAgIGluIG9wZXJhdGlvbi4g IFRoZSBkZWZhdWx0IHZhbHVlIGZvciB0aGUgQWRtaW5EdXBsZXhNb2RlIGlzIHNldCB0bwogICBh dXRvLW5lZ290aWF0aW9uIG1vZGUuICBBIFN1cHBvcnRlZER1cGxleE1vZGUgY2FwYWJpbGl0eSBp cyBhbHNvCiAgIGRlZmluZWQgZm9yIENFIHRvIHF1ZXJ5IHRoZSBwb3J0IGR1cGxleCBtb2RlIGFi aWxpdHkuICBBCiAgIER1cGxleE1vZGVDaGFuZ2VkIGV2ZW50IGlzIGRlZmluZWQgZm9yIHRoZSBM RkIgdG8gcmVwb3J0IHRvIENFCiAgIHdoZW5ldmVyIHRoZXJlIGlzIGEgZHVwbGV4IG1vZGUgY2hh bmdlIGR1cmluZyBvcGVyYXRpb24uCgpYWFg6IFNob3VsZCB3ZSBiZSBkaXNjdXNzaW5nIGFsbCB0 aGUgY29tcG9uZW50cywgY2FwYWJpbGl0aWVzIGFuZCBldmVudHM/CmkuZSB3aHkgdGhlIGJyaWVm IGRlc2NyaXB0aW9uIGJlbG93PyBFaXRoZXIgdGhhdCBvciB0aGUgWE1MIHN5bm9wc2lzCm5lZWRz IHRvIGJlIGEgbG90IG1vcmUgZGVzY3JpcHRpdmUuCgogICBUaGVyZSBhcmUgYWxzbyBzb21lIG90 aGVyIGNvbXBvbmVudHMsIGNhcGFiaWxpdGllcywgZXZlbnRzIGRlZmluZWQgaW4KICAgdGhlIExG QiBmb3IgdmFyaW91cyBwdXJwb3Nlcy4gIFNlZSBzZWN0aW9uIDYgZm9yIGRldGFpbGVkIFhNTAog ICBkZWZpbml0aW9ucyBvZiB0aGUgTEZCLgoK --00151747578404578304a1d040a8-- From chuanhuang_li@mail.zjgsu.edu.cn Tue Apr 26 05:01:27 2011 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF5FBE072F for ; Tue, 26 Apr 2011 05:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.615 X-Spam-Level: * X-Spam-Status: No, score=1.615 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, J_CHICKENPOX_16=0.6, J_CHICKENPOX_25=0.6, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uTe-ScO+OIQe for ; Tue, 26 Apr 2011 05:01:27 -0700 (PDT) Received: from mail.zjgsu.edu.cn (ucmail.zjgsu.edu.cn [124.160.64.1]) by ietfa.amsl.com (Postfix) with SMTP id ADF2EE072E for ; Tue, 26 Apr 2011 05:01:26 -0700 (PDT) Received: from RobinLee (unknown [10.20.0.167]) by mailportal (Coremail) with SMTP id rBCI85D7BUCisbZNgIQeAA--.27321S2; Tue, 26 Apr 2011 19:50:58 +0800 (CST) Date: Tue, 26 Apr 2011 19:59:28 +0800 From: "Chuanhuang Li" To: "Joel" References: <201104221443545647087@mail.zjgsu.edu.cn>, <201104251018350282351@mail.zjgsu.edu.cn>, <201104252340233725747@mail.zjgsu.edu.cn> Message-ID: <201104261959280752729@mail.zjgsu.edu.cn> Organization: Zhejiang Gongshang Univercity X-mailer: Foxmail 6, 15, 201, 23 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-CM-TRANSID: rBCI85D7BUCisbZNgIQeAA--.27321S2 X-Coremail-Antispam: 1Uf129KBjDUn29KB7ZKAUJUUUUUYxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJ3UbIYCTnIWIevJa73UjIFyTuYvj4RJUUUUUUUU X-CM-SenderInfo: pfkxt0xkxd0wxbolqzhdloh6pmjv3hxhgxhubq/ Cc: forces , "Joel M. Halpern" , wmwang Subject: Re: [forces] EtherEncap review WAS(Re: BasicMetadataDispatch WAS(Re:LFB LPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 12:01:28 -0000 Hi,Joel I think that you said is the per-port-etherencap case, and a metadata dispatcher will connect after NH. Do you mean the NH output metadata "L3PortID" is no use, if all ports use an unified EtherEncap and NH connects mediaencap directlly? Jamal also asked the same question in ee-suggested.txt: "XXX: is L3PortID (from NH) consumed here or should we be using the term L2PortID for both?" Sorry, maybe I have been confused about Logical Port ID again. It seems it's inconsistent with the consensus we have reached before. In previous email, you said: Given a router, that is also bridging, and sending a packet out an itnerface which is, underneath IP, bridged across several ports, the processing order may be: IPv4LPM -> NextHopApplicator -> EthernetEncapsulator->LogcalPortOutputHandler->L2Bridging In my mind, if NH connects EtherEncap directlly, NH output metadata L3PortID will be consumed in EtherEncap. by using L3PortID, we can get VlanID and the L2PortID (If the L2PortID exists and can be decided in this LFB). If if the router has L2Bridging function, as you said, there need a LogcalPortOutputHandler LFB to settle the Logical port problem, Yours, Chuanhuang ======= 2011-04-25 23:37:31 Joel, wrote: ======= >Remember that if there are LFBs between the NH lFB and the mediaencap >LFB we will need to know which L3 port processing media encap LFB we >need to hand the packet to. As such, we need the L3 port ID as a >metadatum passed through the system. > >Yours, >Joel > >On 4/25/2011 11:40 AM, Chuanhuang Li wrote: >> Hi,Jamal >>>> These are our consideration before, and had been discussed with Joel: >>>> (Precondition: not using the "MediaEncapInfoIndex".) >>>> NH LFB will generate new metadatas: OutputLogicalPortID, NexthopIPv4Addr. >>>> In the entry which have been found, if "NexthopOption" is indicated that this >>>> packet need to be forwarded to local dirrectly connected subnet host, metadata >>>> NexthopIPv4Addr will be filled with the destination IP address of the packet. >>>> For normal forwarding, next, the packet will be sent to EtherEncapsulator LFB. >>>> EtherEncapsulator will use OutputLogicalPortID metadata as the key of LogicalPortID >>>> element to lookup VlanOutputTable to get VlanID and the new OutputLogicalPortID. >>>> Then it will use this new OutputLogicalPortID and NexthopIPv4Addr metadata to lookup >>>> ArpTable to get the output Ethernet L2 information. After processed in this LFB, >>>> metadata OutputLogicalPortID will be updated. >>>> In this simple case, EtherEncapsulator will deliver packets to the correct physical port >>>> directly. And the OutputLogicalPortID is exactly the PHYPortID information. >>>> However, if the device is doing bridging as well as routing (or bridging plus >>>> host applications >>>> like management or console services), then after the encapsulation, all that >>>> EtherEncapsulator >>>> knows is what logical port the packet is to be sent on. The packet must be handed to >>>> the bridging logic, which will use the logical output port and the destination MAC address >>>> to decide what physical port to send the frame on, including the possibility that it may need >>>> to flood the packet out several physical ports, or add additional bridging encapsulations. >>>> >>>> I think, If we use "MediaEncapInfoIndex" and merge VLAN output table into media enap table, >>>> an element, such as named "L2PortID", need to be added into the encap table. >>>> >>> We already have OutputLogicalPortID - do you mean we need to change the >>> name to L2PortID? >>> >> Exactly, I'm thinking how to know the L2PortID(or PHYPortID) , If the two tables were >> merged and the merged table was searched by "MediaEncapInfoIndex" key. Where will the L3PortID >> metadata be consumed in the simple routing case ? >> >> Yours, >> Chuanhuang >> _______________________________________________ >> forces mailing list >> forces@ietf.org >> https://www.ietf.org/mailman/listinfo/forces > From joel@stevecrocker.com Tue Apr 26 06:47:36 2011 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B505E075D for ; Tue, 26 Apr 2011 06:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.93 X-Spam-Level: X-Spam-Status: No, score=0.93 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DSL=1.129, J_CHICKENPOX_16=0.6, J_CHICKENPOX_24=0.6, J_CHICKENPOX_25=0.6, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dXe0-CtD+BqN for ; Tue, 26 Apr 2011 06:47:35 -0700 (PDT) Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by ietfa.amsl.com (Postfix) with ESMTP id A2C74E0670 for ; Tue, 26 Apr 2011 06:47:35 -0700 (PDT) Received: from [96.245.82.167] (HELO [192.168.1.14]) by execdsl.com (CommuniGate Pro SMTP 5.1.16) with ESMTPS id 19579017; Tue, 26 Apr 2011 13:48:11 +0000 Message-ID: <4DB6CCF7.8050802@stevecrocker.com> Date: Tue, 26 Apr 2011 09:47:35 -0400 From: Joel 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: Chuanhuang Li References: <201104221443545647087@mail.zjgsu.edu.cn>, <201104251018350282351@mail.zjgsu.edu.cn>, <201104252340233725747@mail.zjgsu.edu.cn> <201104261959280752729@mail.zjgsu.edu.cn> In-Reply-To: <201104261959280752729@mail.zjgsu.edu.cn> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: forces , "Joel M. Halpern" , wmwang Subject: Re: [forces] EtherEncap review WAS(Re: BasicMetadataDispatch WAS(Re:LFB LPM issue X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 13:47:36 -0000 Your first description is accurate. In principle therefore, it would at first appear that your second conclusion follows (if you use a single media encapsulator for all the ethernet ports, then the direct table index could do all the work.) However, you need to remember that even in that case the design has to allow for different media, which will need different encapsulation LFB classes. As such, given that there may be intermediate LFBs, it follows that we need a dispatcher, and the L3PortID is the correct conceptual dispatcher. (It means that in some cases we may have multiple parallel outputs from the dispatcher going to the same next LFB isntance. But that is not a problem. I do not want to encode the media type as an explicit metadatum, as there are lots of potential complications. (One example of an alternate media encapsulator which we will need to support later is a tunnel and there are multiple kinds of tunnels, with new ones being invented. If we have a media-type metadatum, we have to keep expanding it. If we use the L3PortID, it just works.) Yours, Joel On 4/26/2011 7:59 AM, Chuanhuang Li wrote: > Hi,Joel > I think that you said is the per-port-etherencap case, and a metadata dispatcher will connect > after NH. Do you mean the NH output metadata "L3PortID" is no use, if all ports use an unified > EtherEncap and NH connects mediaencap directlly? Jamal also asked the same question in > ee-suggested.txt: "XXX: is L3PortID (from NH) consumed here or should we > be using the term L2PortID for both?" > Sorry, maybe I have been confused about Logical Port ID again. It seems it's inconsistent > with the consensus we have reached before. > In previous email, you said: Given a router, that is also bridging, and sending > a packet out an itnerface which is, underneath IP, bridged across several ports, > the processing order may be: IPv4LPM -> NextHopApplicator -> > EthernetEncapsulator->LogcalPortOutputHandler->L2Bridging > > In my mind, if NH connects EtherEncap directlly, NH output metadata L3PortID will be consumed > in EtherEncap. by using L3PortID, we can get VlanID and the L2PortID (If the L2PortID exists and can > be decided in this LFB). If if the router has L2Bridging function, as you said, there need a LogcalPortOutputHandler > LFB to settle the Logical port problem, > > Yours, > Chuanhuang > > ======= 2011-04-25 23:37:31 Joel, wrote: ======= > >> Remember that if there are LFBs between the NH lFB and the mediaencap >> LFB we will need to know which L3 port processing media encap LFB we >> need to hand the packet to. As such, we need the L3 port ID as a >> metadatum passed through the system. >> >> Yours, >> Joel >> >> On 4/25/2011 11:40 AM, Chuanhuang Li wrote: >>> Hi,Jamal >>>>> These are our consideration before, and had been discussed with Joel: >>>>> (Precondition: not using the "MediaEncapInfoIndex".) >>>>> NH LFB will generate new metadatas: OutputLogicalPortID, NexthopIPv4Addr. >>>>> In the entry which have been found, if "NexthopOption" is indicated that this >>>>> packet need to be forwarded to local dirrectly connected subnet host, metadata >>>>> NexthopIPv4Addr will be filled with the destination IP address of the packet. >>>>> For normal forwarding, next, the packet will be sent to EtherEncapsulator LFB. >>>>> EtherEncapsulator will use OutputLogicalPortID metadata as the key of LogicalPortID >>>>> element to lookup VlanOutputTable to get VlanID and the new OutputLogicalPortID. >>>>> Then it will use this new OutputLogicalPortID and NexthopIPv4Addr metadata to lookup >>>>> ArpTable to get the output Ethernet L2 information. After processed in this LFB, >>>>> metadata OutputLogicalPortID will be updated. >>>>> In this simple case, EtherEncapsulator will deliver packets to the correct physical port >>>>> directly. And the OutputLogicalPortID is exactly the PHYPortID information. >>>>> However, if the device is doing bridging as well as routing (or bridging plus >>>>> host applications >>>>> like management or console services), then after the encapsulation, all that >>>>> EtherEncapsulator >>>>> knows is what logical port the packet is to be sent on. The packet must be handed to >>>>> the bridging logic, which will use the logical output port and the destination MAC address >>>>> to decide what physical port to send the frame on, including the possibility that it may need >>>>> to flood the packet out several physical ports, or add additional bridging encapsulations. >>>>> >>>>> I think, If we use "MediaEncapInfoIndex" and merge VLAN output table into media enap table, >>>>> an element, such as named "L2PortID", need to be added into the encap table. >>>>> >>>> We already have OutputLogicalPortID - do you mean we need to change the >>>> name to L2PortID? >>>> >>> Exactly, I'm thinking how to know the L2PortID(or PHYPortID) , If the two tables were >>> merged and the merged table was searched by "MediaEncapInfoIndex" key. Where will the L3PortID >>> metadata be consumed in the simple routing case ? >>> >>> Yours, >>> Chuanhuang >>> _______________________________________________ >>> forces mailing list >>> forces@ietf.org >>> https://www.ietf.org/mailman/listinfo/forces > From ehalep@ece.upatras.gr Tue Apr 26 14:06:12 2011 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9487E0812 for ; Tue, 26 Apr 2011 14:06:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jRdY2Ngf+RA1 for ; Tue, 26 Apr 2011 14:06:12 -0700 (PDT) Received: from mailgate.ece.upatras.gr (mailgate1.ece.upatras.gr [150.140.189.22]) by ietfa.amsl.com (Postfix) with ESMTP id C7DF5E080E for ; Tue, 26 Apr 2011 14:06:11 -0700 (PDT) Received: from EhalepXPS (150.140.254.18) by mailgate1 (Axigen) with ESMTPA id 2EC36D; Wed, 27 Apr 2011 00:13:25 +0300 From: "Haleplidis Evangelos" To: References: In-Reply-To: Date: Wed, 27 Apr 2011 00:06:04 +0300 Message-ID: <000901cc0455$c207e3d0$4617ab70$@upatras.gr> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_000A_01CC046E.E7551BD0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcwEAmxHOMkhxn2PRlK0dTxLplD6pQAUz/LQ Content-Language: el X-Mailman-Approved-At: Tue, 26 Apr 2011 14:34:57 -0700 Cc: "'Joel M. Halpern'" , 'Chuanhuang Li' , 'wmwang' Subject: Re: [forces] LFBlib readability suggestions X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 21:06:13 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_000A_01CC046E.E7551BD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Greetings to all, After Jamal's suggestion I took his initiative and completed the etherphycop definition. Please take a look and comment, in the meantime I'll start working on the EtherMacIn. About Jamal's comments: XXX: It may make sense to have each of Components, Capabilities and Events on its own section? I think it is more readable this way and also following the same format as the model RFC provides consistency. XXX: I copied this from the draft but i think it may be wrong. The xml says this component is read-only. And i remember we had a very long discussion (refer to how one would map a port name to the PHY on how this ID is to be used). Well, even the text says that: " is defined so the CE can assign an ID ". Since the CE can assign the ID then it must be read-write. I think we should change it in the XML. XXX: Should we be discussing all the components, capabilities and events? i.e why the brief description below? Either that or the XML synopsis needs to be a lot more descriptive. I think we should be discussing ALL components/capabilities/events. It's more readable this way. Someone not familiar with xml may want to read and understand in this way of reading instead of looking around in the xml. Also there is a typo in the xml definition of the EtherPhyCop. In the synopsis of the DuplexModeChanged there is a "speed." in the end that is not supposed to be there. Regards, Evangelos Haleplidis. > -----Original Message----- > From: forces-bounces@ietf.org [mailto:forces-bounces@ietf.org] On > Behalf Of Jamal Hadi Salim > Sent: Tuesday, April 26, 2011 2:01 PM > To: forces@ietf.org > Cc: Chuanhuang Li; wmwang; Joel M. Halpern > Subject: [forces] LFBlib readability suggestions > > to the authors, > > As i have whined before, the general draft text is hard to read. > I think making things a little more formal as in the example LFB in RFC > 5812 section 8 will go a long way to improve readability. > > I have attempted to redo the EtherPHYCop section, I didnt go 100% with > the RFC5812 format but please take a look in particular the "XXX" > and cross reference with: > - the text that exists right now in the draft > - the xml (and also to make sure it is well described) > - the formal scheme to describe things as i laid it out. The model > draft LFB example in section 8 is a good start. > > cheers, > jamal ------=_NextPart_000_000A_01CC046E.E7551BD0 Content-Type: text/plain; name="section5-etherphycop-final.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="section5-etherphycop-final.txt" =0A= 5.1.1. EtherPHYCop=0A= =0A= EtherPHYCop LFB abstracts an Ethernet interface physical layer with=0A= media limited to copper.=0A= =0A= 5.1.1.1. Data Handling=0A= =0A= This LFB is the interface to the Ethernet physical media.=0A= The LFB handles ethernet frames coming in from or going=0A= out of the FE. Ethernet frames sent and received cover all =0A= packets encapsulated with different versions of Ethernet =0A= protocols, like Ethernet V2, 802.3 RAW, IEEE 802.3/802.2,=0A= IEEE 802.3/802.2 SNAP, including packets encapsulated with=0A= varieties of LAN techniques based on Ethernet, like various =0A= VLANs, MACinMAC, etc. Therefore in the XML an EthernetAll frame=0A= type has been introduced.=0A= =0A= Ethernet frames are received from the physical media port and passed =0A= downstream to LFBs such as EtherMACIn via a singleton output known as =0A= "EtherPHYOut". A 'PHYPortID' metadata, to indicate which physical = port =0A= the frame came into from the external world, is passed along with the=0A= frame.=0A= =0A= Ethernet packets are received by this LFB from upstream LFBs such=0A= EtherMacOut via the singleton input known as "EtherPHYIn" before being=0A= sent out onto the external world.=0A= =0A= 5.1.1.2. Components=0A= =0A= The AdminStatus component is defined for CE to administratively = manage =0A= the status of the LFB. The CE may adminstratively startup or shutdown =0A= the LFB by changing the value of AdminStatus. The default value is =0A= set to 'Down'.=0A= =0A= An OperStatus component captures the physical port operational status.=0A= A PHYPortStatusChanged event is defined so the LFB can report to the = CE =0A= whenever there is an operational status change of the physical port.=0A= =0A= The PHYPortID component is defined so the CE can assign an ID to =0A= the physical port. The component will be used to produce metadata =0A= to associate every Ethernet packet this LFB receives from the media =0A= and is going to hand to later LFBs for further processing.=0A= =0A= A group of components are defined for link speed management. The=0A= AdminLinkSpeed is for CE to configure link speed for the port=0A= and the OperLinkSpeed is for CE to query the actual link speed in=0A= operation. The default value for the AdminLinkSpeed is set to auto-=0A= negotiation mode.=0A= =0A= A group of components are defined for duplex mode management. The=0A= AdminDuplexMode is for CE to configure proper duplex mode for the=0A= port and the OperDuplexMode is for CE to query the actual duplex mode=0A= in operation. The default value for the AdminDuplexMode is set to=0A= auto-negotiation mode.=0A= =0A= A CarrierStatus component captures the status of the carrier and = specifies=0A= whether the port is linked with an operational connector. The default=0A= value for the CarrierStatus is 'false'=0A= =0A= 5.1.1.3. Capabilities=0A= =0A= The capability information for this LFB includes the link speeds that = are=0A= supported by the FE (SupportedLinkSpeed) as well as the supported = duplex=0A= modes (SupportedDuplexMode).=0A= =0A= 5.1.1.4. Events=0A= =0A= This LFB is defined to be able to generate several events in which=0A= the CE may be interested. There is an event for changes in the status = of the=0A= physical port (PhyPortStatusChanged). Such an event will notify that = the =0A= the physical port status has been changed and the report will include = the new=0A= status of the physical port.=0A= =0A= Another event captures changes in the operational link speed = (LinkSpeedChanged).=0A= Such an event will notify the CE that the operational speed has been = changed and=0A= the report will include the new negotiated operational speed.=0A= =0A= A final event captures changes in the duplex mode = (DuplexModeChanged). Such an =0A= event will notify the CE that the duplex mode has been changed and = the report =0A= will include the new negotiated duplex mode.=0A= ------=_NextPart_000_000A_01CC046E.E7551BD0-- From hadi@mojatatu.com Tue Apr 26 14:43:22 2011 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D355BE079C for ; Tue, 26 Apr 2011 14:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.207 X-Spam-Level: X-Spam-Status: No, score=-102.207 tagged_above=-999 required=5 tests=[AWL=0.770, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Naek35VxfZiF for ; Tue, 26 Apr 2011 14:43:22 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1470EE079B for ; Tue, 26 Apr 2011 14:43:21 -0700 (PDT) Received: by fxm15 with SMTP id 15so868438fxm.31 for ; Tue, 26 Apr 2011 14:43:21 -0700 (PDT) Received: by 10.223.35.8 with SMTP id n8mr1433264fad.72.1303854201076; Tue, 26 Apr 2011 14:43:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.21.16 with HTTP; Tue, 26 Apr 2011 14:43:01 -0700 (PDT) In-Reply-To: <000901cc0455$c207e3d0$4617ab70$@upatras.gr> References: <000901cc0455$c207e3d0$4617ab70$@upatras.gr> From: Jamal Hadi Salim Date: Tue, 26 Apr 2011 17:43:01 -0400 Message-ID: To: Haleplidis Evangelos Content-Type: text/plain; charset=ISO-8859-1 Cc: forces@ietf.org, Chuanhuang Li , wmwang , "Joel M. Halpern" Subject: Re: [forces] LFBlib readability suggestions X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 21:43:22 -0000 Greetings Evangelos, Looks very nice! Now if we could do all the LFBs like that, the document readability would improve greatly! More comments inlined. On Tue, Apr 26, 2011 at 5:06 PM, Haleplidis Evangelos wrote: > Greetings to all, > > After Jamal's suggestion I took his initiative and completed the etherphycop > definition. > > Please take a look and comment, in the meantime I'll start working on the > EtherMacIn. > > About Jamal's comments: > > XXX: It may make sense to have each of Components, Capabilities and Events > on its own section? > > I think it is more readable this way and also following the same format as > the model RFC provides consistency. > Fine with me;-> > XXX: I copied this from the draft but i think it may be wrong. The xml says > this component is read-only. And i remember we had a very long discussion > (refer to how one would map a port name to the PHY on how this ID is to be > used). > > Well, even the text says that: " is defined so the CE can assign an ID ". > Since the CE can assign the ID then it must be read-write. I think we should > change it in the XML. > I think the CE cannot assign an ID - the FE comes up with it. The text contradicts the XML (as i was pointing out). > XXX: Should we be discussing all the components, capabilities and events? > i.e why the brief description below? Either that or the XML synopsis needs > to be a lot more descriptive. > > I think we should be discussing ALL components/capabilities/events. > It's more readable this way. Someone not familiar with xml may want to read > and understand in this way of reading instead of looking around in the xml. > Like i said above, I am fine with that approach, > Also there is a typo in the xml definition of the EtherPhyCop. In the > synopsis of the DuplexModeChanged there is a "speed." in the end that is not > supposed to be there. > I didnt catch that one, but you are right. Thanks for the effort Evangelos. cheers, jamal From chuanhuang_li@mail.zjgsu.edu.cn Tue Apr 26 18:23:46 2011 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00367E0680 for ; Tue, 26 Apr 2011 18:23:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.492 X-Spam-Level: X-Spam-Status: No, score=-0.492 tagged_above=-999 required=5 tests=[AWL=2.107, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5mZ1Dco+7OKm for ; Tue, 26 Apr 2011 18:23:45 -0700 (PDT) Received: from mail.zjgsu.edu.cn (ucmail.zjgsu.edu.cn [124.160.64.1]) by ietfa.amsl.com (Postfix) with SMTP id BCA67E0679 for ; Tue, 26 Apr 2011 18:23:43 -0700 (PDT) Received: from RobinLee (unknown [10.20.0.167]) by mailportal (Coremail) with SMTP id rBCI85Dr9TyUbbdNgIQeAA--.28712S2; Wed, 27 Apr 2011 09:12:53 +0800 (CST) Date: Wed, 27 Apr 2011 09:21:27 +0800 From: "Chuanhuang Li" To: "Haleplidis Evangelos" , "forces@ietf.org" References: Message-ID: <201104270921270289667@mail.zjgsu.edu.cn> Organization: Zhejiang Gongshang Univercity X-mailer: Foxmail 6, 15, 201, 23 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-CM-TRANSID: rBCI85Dr9TyUbbdNgIQeAA--.28712S2 X-Coremail-Antispam: 1Uf129KBjDUn29KB7ZKAUJUUUUUYxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJ3UbIYCTnIWIevJa73UjIFyTuYvj4RJUUUUUUUU X-CM-SenderInfo: pfkxt0xkxd0wxbolqzhdloh6pmjv3hxhgxhubq/ Cc: "'Joel M. Halpern'" , 'wmwang' Subject: Re: [forces] LFBlib readability suggestions X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 01:23:46 -0000 Hi, Evangelos When you are reorganizing the draft content, and if there is contradiction between text and the latest XML which i had post on list before, please use the XML as guidance. This is because after draft-03, we had discussed some contents and reached some consensuses. And I think maybe Weiming has the latest draft contents text. Thanks! Yours, Chuanhuang ======= 2011-04-27 04:58:08 Haleplidis Evangelos, wrote: ======= >Greetings to all, > >After Jamal's suggestion I took his initiative and completed the etherphycop >definition. > >Please take a look and comment, in the meantime I'll start working on the >EtherMacIn. > >About Jamal's comments: > >XXX: It may make sense to have each of Components, Capabilities and Events >on its own section? > >I think it is more readable this way and also following the same format as >the model RFC provides consistency. > >XXX: I copied this from the draft but i think it may be wrong. The xml says >this component is read-only. And i remember we had a very long discussion >(refer to how one would map a port name to the PHY on how this ID is to be >used). > >Well, even the text says that: " is defined so the CE can assign an ID ". >Since the CE can assign the ID then it must be read-write. I think we should >change it in the XML. > >XXX: Should we be discussing all the components, capabilities and events? >i.e why the brief description below? Either that or the XML synopsis needs >to be a lot more descriptive. > >I think we should be discussing ALL components/capabilities/events. >It's more readable this way. Someone not familiar with xml may want to read >and understand in this way of reading instead of looking around in the xml. > >Also there is a typo in the xml definition of the EtherPhyCop. In the >synopsis of the DuplexModeChanged there is a "speed." in the end that is not >supposed to be there. > >Regards, >Evangelos Haleplidis. > >> -----Original Message----- >> From: forces-bounces@ietf.org [mailto:forces-bounces@ietf.org] On >> Behalf Of Jamal Hadi Salim >> Sent: Tuesday, April 26, 2011 2:01 PM >> To: forces@ietf.org >> Cc: Chuanhuang Li; wmwang; Joel M. Halpern >> Subject: [forces] LFBlib readability suggestions >> >> to the authors, >> >> As i have whined before, the general draft text is hard to read. >> I think making things a little more formal as in the example LFB in RFC >> 5812 section 8 will go a long way to improve readability. >> >> I have attempted to redo the EtherPHYCop section, I didnt go 100% with >> the RFC5812 format but please take a look in particular the "XXX" >> and cross reference with: >> - the text that exists right now in the draft >> - the xml (and also to make sure it is well described) >> - the formal scheme to describe things as i laid it out. The model >> draft LFB example in section 8 is a good start. >> >> cheers, >> jamal > From wmwang2001@hotmail.com Tue Apr 26 22:33:59 2011 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA627E06A0 for ; Tue, 26 Apr 2011 22:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.154 X-Spam-Level: ** X-Spam-Status: No, score=2.154 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_28=0.6, J_CHICKENPOX_29=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_38=0.6, J_CHICKENPOX_39=0.6, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QDZzlnX2fsBg for ; Tue, 26 Apr 2011 22:33:55 -0700 (PDT) Received: from blu0-omc1-s10.blu0.hotmail.com (blu0-omc1-s10.blu0.hotmail.com [65.55.116.21]) by ietfa.amsl.com (Postfix) with ESMTP id 81EEFE0659 for ; Tue, 26 Apr 2011 22:33:55 -0700 (PDT) Received: from BLU0-SMTP215 ([65.55.116.9]) by blu0-omc1-s10.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Apr 2011 22:33:54 -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-SMTP215.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Apr 2011 22:33:51 -0700 From: "Wang,Weiming" To: "Chuanhuang Li" , "Haleplidis Evangelos" , References: <201104270921270289667@mail.zjgsu.edu.cn> Date: Wed, 27 Apr 2011 13:33:34 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_065B_01CC04DF.B4F2C950" 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: 27 Apr 2011 05:33:51.0623 (UTC) FILETIME=[B0E6D970:01CC049C] Cc: "'Joel M. Halpern'" , 'wmwang' Subject: Re: [forces] LFBlib readability suggestions X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 05:33:59 -0000 ------=_NextPart_000_065B_01CC04DF.B4F2C950 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SGkgIEV2YW5nZWxvcyBhbmQgSmFtYWwsDQoNClRoZXJlIGFyZSBzZXZlcmFsIGNoYW5nZXMgc2lu Y2UgMDMgdmVyc2lvbiBvbiB0aGUgTEZCIGRlc2NyaXB0aW9uIHNlY3Rpb24uIEF0dGFjaGVkIGlz IHRoZSBsYXRlc3QgdGV4dCB0aGF0IEkndiBiZWVuIG1haW50YWluaW5nLiBQbHMgdXNlIHRoaXMg dGV4dCBhcyB5b3VyIGJhc2UgdGV4dCB0byBtYWtlICB0aGUgbW9kaWZpY2F0aW9uLiANCg0KSSds IGluY29ycGFyYXRlIGV2ZXJ5IExGQiBkZXNjcmlwdGlvbiB0ZXh0IHNpbmNlIGl0IGhhcyBiZWVu IG1hZGUgY29uc2Vuc3VzIGJ5IHRoZSBsaXN0Lg0KDQpBbm90aGVyIHN1Z2dlc3Rpb24gaXMsIEV2 YW5nZWxvcywgcGxzIG1ha2UgYSB0aXRsZSB3aXRoIHRoZSBMRkIgbmFtZSBmb3IgZXZlcnkgdGV4 dCBtb2RpZmljYXRpb24gc28gdGhhdCB3ZSBjYW4gdHJhY2UgdGhlIGRpc2N1c3Npb25zIGVhc2ls eS4gDQoNCnRoYW5rcyBhIGxvdC4NCldlaW1pbmcNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAt LS0tLSANCkZyb206ICJDaHVhbmh1YW5nIExpIiA8Y2h1YW5odWFuZ19saUBtYWlsLnpqZ3N1LmVk dS5jbj4NCg0KPiBIaSwgRXZhbmdlbG9zDQo+ICAgICANCj4gICAgV2hlbiB5b3UgYXJlIHJlb3Jn YW5pemluZyB0aGUgZHJhZnQgY29udGVudCwgYW5kIGlmIHRoZXJlIGlzIGNvbnRyYWRpY3Rpb24g YmV0d2VlbiANCj4gdGV4dCBhbmQgdGhlIGxhdGVzdCBYTUwgd2hpY2ggaSBoYWQgcG9zdCBvbiBs aXN0IGJlZm9yZSwgcGxlYXNlIHVzZSB0aGUgWE1MIGFzIGd1aWRhbmNlLg0KPiBUaGlzIGlzIGJl Y2F1c2UgYWZ0ZXIgZHJhZnQtMDMsIHdlIGhhZCBkaXNjdXNzZWQgc29tZSBjb250ZW50cyBhbmQg cmVhY2hlZCBzb21lIGNvbnNlbnN1c2VzLg0KPiBBbmQgSSB0aGluayBtYXliZSBXZWltaW5nIGhh cyB0aGUgbGF0ZXN0IGRyYWZ0IGNvbnRlbnRzIHRleHQuDQo+IFRoYW5rcyENCj4gDQo+IFlvdXJz LA0KPiBDaHVhbmh1YW5nDQo+IA0KPiA9PT09PT09IDIwMTEtMDQtMjcgMDQ6NTg6MDggSGFsZXBs aWRpcyBFdmFuZ2Vsb3MsIHdyb3RlOiA9PT09PT09DQo+IA0KPj5HcmVldGluZ3MgdG8gYWxsLA0K Pj4NCj4+QWZ0ZXIgSmFtYWwncyBzdWdnZXN0aW9uIEkgdG9vayBoaXMgaW5pdGlhdGl2ZSBhbmQg Y29tcGxldGVkIHRoZSBldGhlcnBoeWNvcA0KPj5kZWZpbml0aW9uLg0KPj4NCj4+UGxlYXNlIHRh a2UgYSBsb29rIGFuZCBjb21tZW50LCBpbiB0aGUgbWVhbnRpbWUgSSdsbCBzdGFydCB3b3JraW5n IG9uIHRoZQ0KPj5FdGhlck1hY0luLg0KPj4NCj4+QWJvdXQgSmFtYWwncyBjb21tZW50czoNCj4+ DQo+PlhYWDogSXQgbWF5IG1ha2Ugc2Vuc2UgdG8gaGF2ZSBlYWNoIG9mIENvbXBvbmVudHMsIENh cGFiaWxpdGllcyBhbmQgRXZlbnRzDQo+Pm9uIGl0cyBvd24gc2VjdGlvbj8NCj4+DQo+PkkgdGhp bmsgaXQgaXMgbW9yZSByZWFkYWJsZSB0aGlzIHdheSBhbmQgYWxzbyBmb2xsb3dpbmcgdGhlIHNh bWUgZm9ybWF0IGFzDQo+PnRoZSBtb2RlbCBSRkMgcHJvdmlkZXMgY29uc2lzdGVuY3kuDQo+Pg0K Pj5YWFg6IEkgY29waWVkIHRoaXMgZnJvbSB0aGUgZHJhZnQgYnV0IGkgdGhpbmsgaXQgbWF5IGJl IHdyb25nLiBUaGUgeG1sIHNheXMNCj4+dGhpcyBjb21wb25lbnQgaXMgcmVhZC1vbmx5LiBBbmQg aSByZW1lbWJlciB3ZSBoYWQgYSB2ZXJ5IGxvbmcgZGlzY3Vzc2lvbg0KPj4ocmVmZXIgdG8gaG93 IG9uZSB3b3VsZCBtYXAgYSBwb3J0IG5hbWUgdG8gdGhlIFBIWSBvbiBob3cgdGhpcyBJRCBpcyB0 byBiZQ0KPj51c2VkKS4NCj4+DQo+PldlbGwsIGV2ZW4gdGhlIHRleHQgc2F5cyB0aGF0OiAiIGlz IGRlZmluZWQgc28gdGhlIENFIGNhbiBhc3NpZ24gYW4gSUQgIi4NCj4+U2luY2UgdGhlIENFIGNh biBhc3NpZ24gdGhlIElEIHRoZW4gaXQgbXVzdCBiZSByZWFkLXdyaXRlLiBJIHRoaW5rIHdlIHNo b3VsZA0KPj5jaGFuZ2UgaXQgaW4gdGhlIFhNTC4NCj4+DQo+PlhYWDogU2hvdWxkIHdlIGJlIGRp c2N1c3NpbmcgYWxsIHRoZSBjb21wb25lbnRzLCBjYXBhYmlsaXRpZXMgYW5kIGV2ZW50cz8NCj4+ aS5lIHdoeSB0aGUgYnJpZWYgZGVzY3JpcHRpb24gYmVsb3c/IEVpdGhlciB0aGF0IG9yIHRoZSBY TUwgc3lub3BzaXMgbmVlZHMNCj4+dG8gYmUgYSBsb3QgbW9yZSBkZXNjcmlwdGl2ZS4NCj4+DQo+ PkkgdGhpbmsgd2Ugc2hvdWxkIGJlIGRpc2N1c3NpbmcgQUxMIGNvbXBvbmVudHMvY2FwYWJpbGl0 aWVzL2V2ZW50cy4NCj4+SXQncyBtb3JlIHJlYWRhYmxlIHRoaXMgd2F5LiBTb21lb25lIG5vdCBm YW1pbGlhciB3aXRoIHhtbCBtYXkgd2FudCB0byByZWFkDQo+PmFuZCB1bmRlcnN0YW5kIGluIHRo aXMgd2F5IG9mIHJlYWRpbmcgaW5zdGVhZCBvZiBsb29raW5nIGFyb3VuZCBpbiB0aGUgeG1sLg0K Pj4NCj4+QWxzbyB0aGVyZSBpcyBhIHR5cG8gaW4gdGhlIHhtbCBkZWZpbml0aW9uIG9mIHRoZSBF dGhlclBoeUNvcC4gSW4gdGhlDQo+PnN5bm9wc2lzIG9mIHRoZSBEdXBsZXhNb2RlQ2hhbmdlZCB0 aGVyZSBpcyBhICJzcGVlZC4iIGluIHRoZSBlbmQgdGhhdCBpcyBub3QNCj4+c3VwcG9zZWQgdG8g YmUgdGhlcmUuDQo+Pg0KPj5SZWdhcmRzLA0KPj5FdmFuZ2Vsb3MgSGFsZXBsaWRpcy4NCj4+DQo+ Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+PiBGcm9tOiBmb3JjZXMtYm91bmNlc0Bp ZXRmLm9yZyBbbWFpbHRvOmZvcmNlcy1ib3VuY2VzQGlldGYub3JnXSBPbg0KPj4+IEJlaGFsZiBP ZiBKYW1hbCBIYWRpIFNhbGltDQo+Pj4gU2VudDogVHVlc2RheSwgQXByaWwgMjYsIDIwMTEgMjow MSBQTQ0KPj4+IFRvOiBmb3JjZXNAaWV0Zi5vcmcNCj4+PiBDYzogQ2h1YW5odWFuZyBMaTsgd213 YW5nOyBKb2VsIE0uIEhhbHBlcm4NCj4+PiBTdWJqZWN0OiBbZm9yY2VzXSBMRkJsaWIgcmVhZGFi aWxpdHkgc3VnZ2VzdGlvbnMNCj4+PiANCj4+PiB0byB0aGUgYXV0aG9ycywNCj4+PiANCj4+PiBB cyBpIGhhdmUgd2hpbmVkIGJlZm9yZSwgdGhlIGdlbmVyYWwgZHJhZnQgdGV4dCBpcyBoYXJkIHRv IHJlYWQuDQo+Pj4gSSB0aGluayBtYWtpbmcgdGhpbmdzIGEgbGl0dGxlIG1vcmUgZm9ybWFsIGFz IGluIHRoZSBleGFtcGxlIExGQiBpbiBSRkMNCj4+PiA1ODEyIHNlY3Rpb24gOCB3aWxsIGdvIGEg bG9uZyB3YXkgdG8gaW1wcm92ZSByZWFkYWJpbGl0eS4NCj4+PiANCj4+PiBJIGhhdmUgYXR0ZW1w dGVkIHRvIHJlZG8gdGhlIEV0aGVyUEhZQ29wIHNlY3Rpb24sIEkgZGlkbnQgZ28gMTAwJSB3aXRo DQo+Pj4gdGhlIFJGQzU4MTIgZm9ybWF0IGJ1dCBwbGVhc2UgdGFrZSBhIGxvb2sgaW4gcGFydGlj dWxhciB0aGUgIlhYWCINCj4+PiBhbmQgY3Jvc3MgcmVmZXJlbmNlIHdpdGg6DQo+Pj4gLSB0aGUg dGV4dCB0aGF0IGV4aXN0cyByaWdodCBub3cgaW4gdGhlIGRyYWZ0DQo+Pj4gLSB0aGUgeG1sIChh bmQgYWxzbyB0byBtYWtlIHN1cmUgaXQgaXMgd2VsbCBkZXNjcmliZWQpDQo+Pj4gLSB0aGUgZm9y bWFsIHNjaGVtZSB0byBkZXNjcmliZSB0aGluZ3MgYXMgaSBsYWlkIGl0IG91dC4gVGhlIG1vZGVs DQo+Pj4gZHJhZnQgTEZCIGV4YW1wbGUgaW4gc2VjdGlvbiA4IGlzIGEgZ29vZCBzdGFydC4NCj4+ PiANCj4+PiBjaGVlcnMsDQo+Pj4gamFtYWwNCj4+DQo+IA0KPiANCj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gZm9yY2VzIG1haWxpbmcgbGlzdA0K PiBmb3JjZXNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9mb3JjZXMNCj4= ------=_NextPart_000_065B_01CC04DF.B4F2C950 Content-Type: text/plain; name="section 5.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="section 5.txt" 5. LFB Class Description According to ForCES specifications, LFB (Logical Function Block) is a = well defined, logically separable functional block that resides in an = FE, and is a functionally accurate abstraction of the FE's processing = capabilities. An LFB Class (or type) is a template that represents a = fine-grained, logically separable aspect of FE processing. Most LFBs = are related to packet processing in the data path. LFB classes are the = basic building blocks of the FE model. Note that RFC 5810 has already = defined an 'FE Protocol LFB' which is as a logical entity in each FE to = control the ForCES protocol. RFC 5812 has already defined an 'FE Object = LFB'. Information like the FE Name, FE ID, FE State, LFB Topology in the = FE are represented in this LFB. As specified in section 3.1, this document focuses the base LFB library = for implementing typical router functions, especially for IP forwarding = functions. As a result, LFB classes in the library are all base LFBs to = implement router forwarding. 5.1. Ethernet Processing LFBs=20 As the most popular physical and data link layer protocols, Ethernets = are widely deployed. It becomes a basic requirement for a router to be = able to process various Ethernet data packets.=20 Note that there exist different versions of Ethernet protocols, like = Ethernet V2, 802.3 RAW, IEEE 802.3/802.2, IEEE 802.3/802.2 SNAP. There = also exist varieties of LAN techniques based on Ethernet, like various = VLANs, MACinMAC, etc. Ethernet processing LFBs defined here are intended = to be able to cope with all these variations of Ethernet technology.=20 There are also various types of Ethernet physical interface media. Among = them, copper and fiber media may be the most popular ones. As a base LFB = definition and a start work, the document only defines an Ethernet = physical LFB with copper media. For other media interfaces, specific = LFBs may be defined in the future versions of the library. =20 =20 5.1.1. EtherPHYCop=20 EtherPHYCop LFB abstracts an Ethernet interface at its physical layer. = It limits the physical media to copper. =20 The LFB is defined with one singleton input. The input data of the LFB = are expected to be Ethernet packets. Note that Ethernet packets here = cover all packets encapsulated with different versions of Ethernet = protocols, like Ethernet V2, 802.3 RAW, IEEE 802.3/802.2, IEEE = 802.3/802.2 SNAP. It also includes packets encapsulated with varieties = of LAN techniques based on Ethernet, like various VLANs, MACinMAC, etc. = As a result, we define various Ethernet frames as a frame name called = 'EthernetAll'. In an LFB abstracted processing path, usually the = Ethernet packets are from an upstream LFB like an EtherMACOut LFB. It is = not expected that an input Ethernet packet be associated with some = metadata. After the LFB receives the Ethernet packets, it will further = process the packets at physical layer and eventually put them on the = physical media wire for transmission. Note that the media wire = transmission process in the LFB is abstracted as a default function of = the LFB rather than an input or output interface of the LFB.=20 The LFB is also defined with one singleton output. The output data = produced are also with 'EthernetAll' frame type. Every output data = packet is associated with a 'PHYPortID' metadata to indicate later = processing LFBs of which physical port the packet is from. Note that all = the data packets are originated from media wire inside the LFB, which is = defined as a default function of the LFB. As a physical layer = abstraction module, the LFB does not possess the ability to specify = encapsulations of types of Ethernet, rather, it produces various = Ethernet types just according to what it receives from Ethernet media = wire. In an LFB-based processing path topology, packets output from the = EtherPHYCop lFB will usually go to an LFB like EtherMACIn LFB for = further Ethernet processing. Note that as a base definition, functions like multiple virtual physical = layers are not supported in this LFB version. It may be supported in the = future by defining a subclass or a new version of this LFB. Several components are defined for the LFB.=20 AdminStatus is defined for CE to administratively manage the status of = the LFB. Via the component, CE may startup or shutdown the LFB. The = default status is set to 'Down'. An OperStatus component is = specifically defined for CE to access the actual operational status of = the LFB, in case that a physical layer port may be in a failed state = that its operational status does not correctly reflect administrative = status. A PHYPortStatusChanged event is defined for the LFB to report to = CE whenever there is a port status change during operation. PHYPortID component is defined for CE to assign an ID to the physical = port. The component will be used to produce a metadata=20 associated with every Ethernet packet the LFB receives from media and is = going to hand to later LFBs for further processing.=20 A group of components are defined for link speed management. The = AdminLinkSpeed is for CE to configure proper link speed for the port and = the OperLinkSpeed is for CE to query the actual link speed in operation. = The default value for the AdminLinkSpeed is set to auto-negotiation = mode. A SupportedLinkSpeed capability attribute is also defined for CE = to query the link speed ability. A LinkSpeedChanged event is defined for = the LFB to report to CE whenever there is a link speed change during = operation. A group of components are defined for duplex mode management. The = AdminDuplexMode is for CE to configure proper duplex mode for the port = and the OperDuplexMode is for CE to query the actual duplex mode in = operation. The default value for the AdminDuplexMode is set to = auto-negotiation mode. A SupportedDuplexMode capability is also defined = for CE to query the port duplex mode ability. A DuplexModeChanged event = is defined for the LFB to report to CE whenever there is a duplex mode = change during operation. =20 There are also some other components, capabilities, events defined in = the LFB for various purposes. See section 6 for detailed XML definitions = of the LFB.=20 5.1.2. EtherMACIn =20 EtherMACIn LFB abstracts an Ethernet port at MAC data link layer. It = specifically describes Ethernet processing functions like MAC address = locality check, deciding if the Ethernet packets should be bridged, = provide Ethernet layer flow control, etc.=20 The LFB is defined with one singleton input. The input is expected to = receive all types of Ethernet packets which are usually output from some = Ethernet physical abstraction layer LFB, like an EtherPHYCop LFB. Every = input packet is associated with a metadatum indicating the physical port = ID that the packet comes.=20 Input Ethernet packets will usually be checked for locality. A = LocalMACAddresses component is defined for the LFB so that CE is able to = configure one or more Ethernet MAC addresses to the LFB for the use of = locality check. All packets that do not pass through the locality check = will be dropped in the LFB. A PromiscuousMode component in the LFB is = further defined to decide if the LFB should work in a promiscuous mode. = When in this mode, the LFB will not do the locality check and all = Ethernet packets will pass through the LFB without being dropped.=20 The LFB is defined with two separate singleton outputs. All Output = packets are in Ethernet format, possibly with various Ethernet types. = One singleton output is called NormalPathOut. It usually outputs = Ethernet packets to some LFB like an EtherClassifier LFB for further L3 = forwarding process. Metadata associated with every packet from this = output is PHYPortID, which keeps indicating which physical port the = packet is from.=20 Another singleton output is called L2BridgingPathOut. Although this LFB = library is basically defined to meet typical router functions, it is = with natural requirement that the definitions here should provide = reasonable compatibility considerations for future wider use. The = L2BridgingPathOut is defined to meet the requirement that L2 bridging = functions may be optionally supported simultaneously with L3 processing = and Some L2 bridging LFBs may be defined in the future. A Boolean flag = component called L2BridgingPathEnable is defined to make the L2 bridging = output as optional. An FE that does not support bridging will internally = set this flag to false, and additionally sets the flag property as = read-only. In this case CE then can read the flag to know that the FE = does not support bridging function and the L2 bridging output is always = disabled. An FE that supports L2 bridging will internally set the flag = property as read-write. In this case, CE then can choose to enable or = disable the L2BridgingPathOut output by setting this flag as desired. If = the flag is set to true, by also instantiating some L2 bridging LFB = instances following the L2BridgingPathOut, FE are expected to fulfill L2 = bridging functions. Whereas, in this case, the default value for the = flag is defined as false, meaning L2 bridging output is closed by = default. Note that, when enabled, l2BridgingPathOut will output packets = exactly the same as that in the NormalPathOut output(Editorial note: = need more discussions here on if the L2 output is the same as normal = output). The metadata associated with every packet is also PHYPortID.=20 Ethernet layer flow control is usually implemented cooperatively by = EtherMACIn LFB and EtherMACOut LFB. How the flow control is implemented = is vendor-specific. As an abstraction, this LFB defines two flag = components for CE to enable or disable the flow control functions. The = flow control is further distinguished by Tx flow control and Rx flow = control, separately for sending process and receiving process flow = controls. A TxFlowControl flag and a RxFlowControl flag are then = separately defined. In order for EtherMACOut LFB able to cooperatively = work for flow control, the flags are also referenced in the EtherMACOut = LFB as aliases in this LFB.=20 AdminStatus is defined for CE to administratively manage the status of = the LFB. Via the component, CE can startup or shutdown the LFB. The = default status is set to 'Down'.=20 Note that as a base definition, functions like multiple virtual MAC = layers are not supported in this LFB version. It may be supported in the = future by defining a subclass or a new version of this LFB. There are also some other components, capabilities, events defined in = the LFB for various purposes. See section 6 for detailed XML definitions = of the LFB.=20 5.1.3. EtherClassifier =20 EtherClassifier LFB abstracts the process to decapsulate Ethernet = packets and classify the data packets into various network layer data = packets according to information included in the Ethernet packets = headers.=20 Input of the LFB expects all types of Ethernet packets, including VLAN = Ethernet types. The input is a singleton input which may connect to an = upstream LFB like EtherMACIn LFB. The input is also capable of = multiplexing to allow for multiple upstream LFBs being connected. For = instance, when L2 bridging function is enabled in EtherMACIn LFB, some = L2 bridging LFBs may be applied. In this case, some Ethernet packets = after L2 processing may have to be input to EtherClassifier LFB for = classification, while simultaneously packets directly output from = EtherMACIn may also need to input to this LFB. Input of this LFB is = capable of handling this case. Usually, every input Ethernet packet is = expected to be associated with a PHYPortID metadatum, indicating the = physical port the packet comes from. In some cases, for instance, like = in an MACinMAC case, a LogicalPortID metadatum may be expected to = associate with the Ethernet packet to further indicate which logical = port the Ethernet packet belongs to. Note that PHYPortID metadata is = always expected while LogicalPortID metadata is optionally expected.=20 A VLANInputTable component is defined in the LFB to classify VLAN = Ethernet packets. According to IEEE VLAN specifications, all Ethernet = packets can be recognized as VLAN types by defining that if there is no = VLAN encapsulation in a packet, a case with VLAN tag 0 is considered. = Therefore the table actually applies to every input packet of the LFB. = The table assigns every input packet with a new LogicalPortID according = to the packet incoming port ID and the VLAN ID. A packet incoming port = ID is defined as a physical port ID if there is no logical port ID = associated with the packet, or a logical port ID if there is a logical = port ID associated with the packet. The VLAN ID is exactly the Vlan ID = in the packet if it is a VLAN packet, or 0 if it is not a VLAN packet. = Note that a logical port ID of a packet may be rewritten with a new one = by the VLANInputTable processing.=20 An EtherDispatchTable component is defined to dispatch every Ethernet = packet to a group of outputs according to the logical port ID assigned = by VLANInputTable to the packet and the Ethernet type in the Ethernet = packet header. By CE configuring the dispatch table, the LFB can be = expected to classify various network layer protocol type packets and = make them output at different output port. It is then easily expected = that the LFB classify packets according to protocols like IPv4, IPv6, = MPLS, ARP, ND, etc.=20 Output of the LFB is hence defined as a group output. Because there may = be various types of protocol packets at the output ports, the = frameproduced is defined as arbitrary for the purpose of wide = extensibility in the future. In order for downstream LFBs to use, a = bunch of metadata is produced to associate with every output packet. The = medatdata contain normal information like PHYPortID. It also contains = information on Ethernet type, source MAC address, and destination MAC = address of its original Ethernet packet. Moreover, it contains = information of logical port ID assigned by this LFB. This metadata may = be used by downstream LFBs for packet processing. Lastly, it may = conditionally contain information like VlanID and VlanPriority with the = condition that the packet is a VLAN packet. A MaxOutPutPorts is defined as the capability of the LFB to indicate how = many classification output ports the LFB is capable. /*discussion*/ Note that logical port ID and physical port ID mentioned above are all = originally configured by CE, and are globally effective within an ForCES = NE (Network Element). To distinguish a physical port ID from a logical = port ID in the incoming port ID field of the VLANInputTable, physical = port ID and logical port ID must be assigned with separate number = spaces. /*discussion */ There are also some other components, capabilities, events defined in = the LFB for various purposes. See section 6 for detailed XML definitions = of the LFB.=20 5.1.4. EtherEncapsulator=20 EtherEncapsulator LFB abstracts the process to encapsulate IP packets to = Ethernet packets.=20 Input of the LFB expects types of IP packets, including IPv4 and IPv6 = types. The input is a singleton one which may connect to an upstream LFB = like an IPv4NextHop, an IPv6NextHop, or any LFB which requires to output = packets for Ethernet encapsulation. The input is capable of multiplexing = to allow for multiple upstream LFBs being connected. For instance, an = IPv4NextHop or an IPv6NextHop may concurrently exist, and some L2 = bridging LFBs may also output packets to this LFB simultaneously. Input = of this LFB is capable of handling this case. Usually, every input = Ethernet packet is expected to be associated with an output logical port = ID and a next hop IP address as its metadata. In the case when L2 = bridging function is implemented, an input packet may also optionally = receive a VLAN priority as its metadata. In this case, default value for = this metadata is set to 0. =20 There are several outputs for this LFB. One singleton output is for = normal success packet output. Packets which have found Ethernet L2 = information and have been successfully encapsulated to an Ethernet = packet will output from this port to downstream LFB. Note that this LFB = specifies to use Ethernet II as its Ethernet encapsulation type. Success = output also produces an output logical port ID as metadatum of every = output packet for a downstream LFB to decide which logical port the = packet should go out. The downstream LFB usually dispatches the packets = based on its associated output logical port ID. Hence, a generic = dispatch LFB as defined in Section 5.6.1 may be adopted for dispatching = packets based on output logical port ID. Note that in some implementations of LFBs topology, the processing to = dispatch packets based on an output logical port ID may also take place = before an Ethernet encapsulation,i.e., packets coming into the = encapsulator LFB have already been switched to individual logical output = port paths. In this case, the EtherEncap LFB success output may be = directly connected to a downstream LFB like an EtherMACOut LFB. Another singleton output is for IPv4 packets that are unfortunately = unable to find Ethernet L2 encapsulation information by ARP table in the = LFB. In this case, a copy of the packets may need to be redirected to an = ARP LFB in the FE, or to CE if ARP function is implemented by CE. More = importantly, a next hop IP address metadata should be associated with = every packet output here. When an ARP LFB or CE receives these packets = and associated next hop IP address metadata, it may be expected to = generate ARP protocol messages based on these packets next hop IP = addresses to try to get L2 information for these packets. Refreshed L2 = information is then able to be added in ARP table in this encapsulator = LFB by ARP LFB or by CE. As a result, these packets are then able to = successfully find L2 information and be encapsulated to Ethernet = packets, and output via the normal success output to downstream LFB. = (Editorial note1: may need discussion on what more metadata this output = packets need? Note that the packets may be redirected to CE and CE = should know what the purpose of the packets for. A metadata may need to = indicate this. Editorial note2: we may adopt another way to address the = case of packets unable to do ARP. The packets may be redirected to ARP = LFB or CE without keeping a copy of them in this encapsulator LFB. We = expect that after ARP LFB or CE have processed ARP requests based on the = packets, the packets will be redirected back from ARP LFB or CE to this = encapsulator LFB for Ethernet encapsulation. At this time, it is hoped = the ARP table has been refreshed with new L2 information that will make = these packets able to find) A more singleton output is for IPv6 packets that are unfortunately = unable to find Ethernet L2 encapsulation information by Neighbor table = in the LFB. In this case, a copy of the packets may need to be = redirected to an ND LFB in the FE, or to CE if IPv6 Neighbor discovery = function is implemented by CE. More importantly, a next hop IP address = metadata should be associated with every packet output here. When the ND = LFB or CE receives these packets and associated next hop IP address = metadata, it may be expected to generate neighbor discovery protocol = messages based on these packets next hop IP addresses to try to get L2 = information for these packets. Refreshed L2 information is then able to = be added in neighbor table in this LFB by ND LFB or by CE. As a result, = these packets are then able to successfully find L2 information and be = encapsulated to Ethernet packets, and output via the normal success = output to downstream LFB.(Editorial note: may need discussion on what = more metadata this output packets need? Note that the packets may be = redirected to CE and CE should know what the purpose of the packets for. = A metadata may need to indicate this) A singleton output is specifically defined for exception packets output. = All packets that are abnormal during the operations in this LFB are = output via this port. Currently, only one abnormal case is defined, that = is, packets can not find proper information in a VLAN output table.=20 The VLAN output table is defined as the component of the LFB. The table = uses a logical port ID as an index to find a VLAN ID and a new output = logical port ID. In reality, the logical port ID applied here is the = output logical port ID received from every input packet in its = associated metadata. According to IEEE VLAN specifications, all Ethernet = packets can be recognized as VLAN types by defining that if there is no = VLAN encapsulation in a packet, a case with VLAN tag 0 is considered. = Therefore, every input IP packet actually has to look up the VLAN output = table to find out a VLAN ID and a new output logical port ID according = to its original logical port ID. The ARP table in the LFB is defined as a component of the LFB. The table = is for IPv4 packet to find its next hop Ethernet layer MAC addresses. = Input IPv4 packet will use an output logical port ID which is got by = looking up the VLAN output table, and a next hop IPv4 address which is = got by upstream next hop applicator LFB, to look up the ARP table to = find the Ethernet L2 information, i.e., the source MAC address and = destination MAC address.=20 The neighbor table is defined as another component of the LFB. The table = is for IPv6 packet to find its next hop Ethernet layer MAC addresses. = Like the ARP table, input IPv6 packet will use its output logical port = ID got from looking up the VLAN output table, and the packet next hop = IPv4 address got by upstream next hop applicator LFB, to look up the = neighbor table to find the Ethernet source MAC address and destination = MAC address. As will be described in the address resolution LFBs section (section = 5.4), Layer 2 address resolution protocols may be implemented with two = choices. One is by FE with specific address resolution LFB, like an ARP = LFB or an ND LFB. The other is to redirect address resolution protocol = messages to CE for CE to implement the function. =20 As described in section 5.4, the ARP LFB defines the ARP table in this = encapsulator LFB as its alias, and the ND LFB defines the neighbor table = as its alias. This means that the ARP table or the neighbor table will = be maintained or refreshed by the ARP LFB or the ND LFB when the LFBs = are used.=20 Note that the ARP table and the neighbor table defined in this LFB are = all with property of read-write. CE can also configure the tables by = ForCES protocol [RFC5810]. This makes possible that IPv4 ARP protocol or = IPv6 Neighbor Discovery protocol may be implemented at CE side,i.e., = after CE manages an ARP or Neighbor discovery protocol and gets address = resolution results, CE can configure them to an ARP or neighbor table in = FE. With all the information got from VLAN table and ARP or Neighbor table, = input IPv4 or IPv6 packets are then able to be encapsulated to Ethernet = layer packets. Note that according to IEEE 802.1Q, if input packets are = with non-zero VLAN priority metadata, the packets will always be = encapsulated with a VLAN tag, no matter the value of VLAN ID is zero or = not. If the VLAN priority and the VLAN ID are all zero, the packets will = be encapsulated without a VLAN tag. Successfully encapsulated packets = are then output via success output port. There are also some other components, capabilities, events defined in = the LFB for various purposes. See section 6 for detailed XML definitions = of the LFB.=20 5.1.5. EtherMACOut=20 EtherMACOut LFB abstracts an Ethernet port at MAC data link layer. It = specifically describes Ethernet packet output process. Ethernet output = functions are closely related to Ethernet input functions, therefore = many components defined in this LFB are actually alias of EtherMACIn = LFB. The LFB is defined with one singleton input(Editorial note: do we need = another input for L2 bridging input?). The input is expected to receive = all types of Ethernet packets which are usually output from some = Ethernet encapsulation LFB. Every input packet is associated with a = metadatum indicating the physical port ID that the packet will = go(Editorial note: Ethernet encapsulation LFB actually generate logical = port ID metadata, how has it been changed to physical port ID?).=20 The LFB is defined with a singleton output. All Output packets are in = Ethernet format, possibly with various Ethernet types. Downstream LFB = the output links to is usually Ethernet physical LFBs like EtherPHYcop = LFB. Metadata associated with every packet from this output is = PHYPortID, which keeps indicating which physical port the packet is to.=20 Ethernet layer flow control is usually implemented cooperatively by = EtherMACIn LFB and EtherMACOut LFB. How the flow control is implemented = is vendor-specific. As an abstraction, this LFB defines two flag = components for CE to enable or disable the flow control functions, a = TxFlowControl flag and a RxFlowControl flag, and they are all defined as = aliases of EtherMACIn LFB.=20 AdminStatus is defined for CE to administratively manage the status of = the LFB. Via the component, CE can startup or shutdown the LFB. The = default status is set to 'Down'. =20 Note that as a base definition, functions like multiple virtual MAC = layers are not supported in this LFB version. It may be supported in the = future by defining a subclass or a new version of this LFB. There are also some other components, capabilities, events defined in = the LFB for various purposes. See section 6 for detailed XML definitions = of the LFB.=20 5.2. IP Packet Validation LFBs An LFB is defined to abstract IP packet validation process. An = IPv4Validator LFB is specifically for IPv4 protocol validation and an = IPv6Validator LFB for IPv6. 5.2.1. IPv4Validator This LFB performs IPv4 packets validation according to RFC 1812.=20 Input of the LFB always expects packets which have been indicated as = IPv4 packets by an upstream LFB, like an EtherClassifier LFB. There is = no specific metadata expected by the input of the validator LFB.=20 Note that, as a default provision of RFC 5812, in FE model, all metadata = produced by upstream LFBs will pass through all downstream LFBs by = default without being specified by input port or output port. Only those = metadata that will be used(consumed) by an LFB will be explicitly marked = in input of the LFB as expected metadata. For instance, in this LFB, = even there is no specific metadata expected, metadata like PHYPortID = produced by some upstreaming PHY LFBs will always pass through this LFB. = In some cases, if some component in the LFB may use the metadata, it = actually still can use it regardless of whether the metadata has been = expected or not. Four output ports are defined to output various validation results. All = validated IPv4 unicast packets will be output at the singleton = IPv4UnicastOut port. All validated IPv4 multicast packets will be output = at the singleton IPv4MulticastOut port. There is no metadata = specifically required to be produced at these output ports.=20 A singleton ExceptionOut port is defined to output packets which have = been validated as exceptional packets. An exception ID metadata is = produced to indicate which causes it exceptional. Currently defined = exception types include cases like, packet with destination address = equal to 255.255.255.255, Packet with expired TTL, Packet with header = length more than 5 words, and packet IP head including Router Alert = options, etc. Note that even TTL is checked for validity here, actual = operation like decrease of TTL will not be made here, rather made by = followed forwarding LFB. A singleton output is defined for all packets which have failed the = packet validation. A validate error ID is associated to every failed = packet to indicate the reasons like an invalid packet size, wrong IP = protocol version, wrong checksum, etc.=20 There are also some other components defined in the LFB for various = purposes. See section 6 for detailed XML definitions of the LFB.=20 5.2.2. IPv6Validator This LFB performs IPv6 packets validation according to RFC 2460.=20 Input of the LFB always expects packets which have been indicated as = IPv6 packets by an upstream LFB like an EtherClassifier LFB. There is no = specific metadata expected by the input of the validator LFB.=20 Similar to IPv4 validator LFB, IPv6Validator LFB has also defined four = output ports to output various validation results. All validated IPv6 = unicast packets will be output at the singleton IPv6UnicastOut port. All = validated IPv6 multicast packets will be output at the singleton = IPv6MulticastOut port. There is no metadata specifically required to be = produced at these output ports. A singleton ExceptionOut port is defined to output packets which have = been validated as exceptional packets. An exception ID is produced to = indicate which causes it exceptional. Currently, exception types include = the following cases:=20 . a packet with hop limit to zero . a packet with a link-local destination address.=20 . a packet with a link-local source address. . a packet with destination all-routers. . a packet with destination all-nodes. . a packet with next header set to Hop-by-Hop. A singleton output is defined for packets which have failed the packet = validation. A validate error ID is associated to every failed packet to = indicate the reasons for the failures. The reasons may include an = invalid packet size, wrong IPv6 protocol version, wrong source or = destination IPv6 addresses, etc. There are also some other components defined in the LFB for various = purposes. See section 6 for detailed XML definitions of the LFB.=20 5.3. IP Forwarding LFBs IP Forwarding LFBs are specifically defined to abstract the IP = forwarding processes. As definitions for a base LFB library, this = document restricts its LFB definition scope for IP forwarding jobs only = to IP unicast forwarding. LFBs for jobs like IP multicast may be defined = in future versions of the document.=20 A typical IP unicast forwarding job is usually realized by looking up = some forwarding information table to find some next hop information, and = then based on the next hop information, forwarding packets to specific = output ports. It usually takes two steps to do so, firstly to look up a = forwarding information table by means of Longest Prefix Matching(LPM) = rule to find a next hop index, then to use the index to look up a next = hop information table to find enough information to submit packets to = output ports. This document abstracts the forwarding processes mainly = based on the two steps model. However, there actually exists other = models, like one which may only have a forwarding information base that = have conjoined next hop information together with forwarding = information. In this case, if ForCES technology is to be applied, some = translation work will have to be done in FE to translate attributes = defined by this document into real attributes the implementation has = actually applied.=20 Based on the IP forwarding abstraction, two kind of typical IP unicast = forwarding LFBs are defined, Unicast LPM lookup LFB and next hop = application LFB. They are further distinguished by IPv4 and IPv6 = protocols. 5.3.1. IPv4UcastLPM The LFB abstracts the process for IPv4 unicast LPM table looking up.=20 Input of the LFB always expects to receive IPv4 unicast packets. An IPv4 = prefix table is defined as a component for the LFB to provide forwarding = information for every input packet. The destination IPv4 address of = every packet is as the index to look up the table with the rule of = longest prefix matching(LPM). A hop selector is the matching result, = which will be output to downstream LFBs as an index for next hop = information.=20 Normal output of the LFB is a singleton output, which will output IPv4 = unicast packet that has passed the LPM lookup and got a hop selector as = the lookup result. The hop selector is associated with the packet as a = metadatum. Followed the normal output of the LPM LFB is usually a next = hop applicator LFB. The LFB receives packets with their next hop IDs and = based on the next hop IDs to forward the packets. A hop selector = associated with every packet from the normal output will directly act as = a next hop ID for a next hop applicator LFB.=20 The LFB is defined to provide some facilities to support users to = implement equal-cost multi-path routing (ECMP) or reverse path = forwarding (RPF). However, this LFB itself does not provide ECMP or RPF. = To implement ECMP or RPF, additional specific LFBs, like a specific ECMP = LFB, will have to be defined. This work may be done in the future = version of the document. For the LFB to support ECMP, an ECMP flag is defined in the prefix table = entries. When the flag is set to true, it indicates this table entry is = for ECMP only. In this case, the hop selector in this table entry will = be used as an index for a downstream specific ECMP LFB to find its = correspondent next hop IDs. When ECMP is applied, it will usually get = multiple next hops information.=20 To distinguish normal output from ECMP case output, a specific ECMP = output is defined. A packet, which has passed through prefix table entry = lookup with true ECMP flag, will always output from this port, with the = hop selector being its lookup result. The output will usually directly = go to a downstream ECMP processing LFB. In the ECMP LFB, based on the = hop selector, multiple next hop IDs may be found, and more ECMP = algorithms may be applied to optimize the route. As the result of the = ECMP LFB, it will output optimized one or multiple next hop IDs to its = downstream LFB that is usually a next hop applicator LFB. For the LFB to support RPF, a default route flag is defined in the = prefix table entry. When set true, the prefix entry is identified as a = default route, and also as a forbidden route for RPF. To implement = various RPF, one or more specific LFBs have to be defined. This job may = be done for the future version of the library.=20 An exception output is defined to allow some exceptional packets to = output here. Exceptions include cases like packets can not find any = routes by the prefix table.=20 There are also some other components defined in the LFB for various = purposes. See section 6 for detailed XML definitions of the LFB.=20 5.3.2. IPv4NextHop This LFB abstracts the process of next hop information application to = IPv4 packets.=20 The LFB receives an IPv4 packet with an associated next hop ID, and uses = the ID to look up a next hop table to find an appropriate output port = from the LFB. Simultaneously, the LFB also implements TTL operation and = checksum recalculation of every IPv4 packet received.=20 Input of the LFB is a singleton one which expects to receive IPv4 = unicast packets and hop selector metadata from an upstream LFB. Usually, = the upstream LFB is directly an IPv4UnicastLPM LFB=A3=ACwhile it is = possible some other upstream LFB may be applied. For instance, when ECMP = is supported, the upstream LFB may be some specific ECMP LFB.=20 The next hop ID in hop selector metadata of a packet is then used as an = index to look up a next hop table defined in the LFB. Via this table and = the next hop index, important information for forwarding the packet is = found. Every next hop table entry includes the following information:=20 . output logical port ID, which will be used by downstream LFBs to find = proper output port. . next hop option, which decides if packets with next hop of this table = entry are destinated to locally attached hosts or not. Locally attached = hosts are hosts in the same subnet with this router. Next hop option is = marked as 'forwarded to locally attached host' if the next hop entry is = for locally attached hosts delivery. All other next hop entry will be = marked with 'normal forwarding'. If a data packet passes through next = hop entries with its next hop option marked with forwarded to locally = attached host, the next hop IP address metadata associated with the data = packet when output from the LFB will be forced to set to the destination = IP address of the data packet. If a data packet passes through a next = hop entry with its option being normal forwarding, the next hop IP = address metadata at output will be set to the next hop IP address as = indicated by this next hop entry. Advantage to define this next hop = option for locally attached hosts is, in this way, the next hop entry = number may be greatly reduced in the case there are a vast number of = locally attached hosts.=20 . next hop IP address, which will be used by downstream LFB to find = proper output port IP address for this packet. Note that when next hop = option is set to 'forwarded to locally attached host', this entry field = becomes invalid. In this case the next hop IP address is assigned = directly by destination IP address of the data packet pass through this = entry check. . encapsulation output index, which is used by data packet to find = proper output of this LFB. Usually, this index can be used to indicate = which encapsulation followed the LFB may be applied to data packets pass = through this next hop entry check and to classify the packets to = different instance of a group output port. Moreover, this index can also = be used to purely indicate output port instance to act as a classifier = based on next hop IDs. For instance, a next hop table entry can be = defined with its encapsulation output index being directed to an output = port which is followed with LFBs that will redirect data packets to = Control Element(CE). A next hop entry can also be defined for some data = packets that need special local processing of the Forwarding = Element(FE). In this case it is not really acting as an encapsulation = index, rather a pure output index. As a result, the LFB is defined with two output ports. One is for = success output and another is for exception output. Success output is a = group output, with an index to indicate which output instance in the = group is adopted. The index is exactly the encapsulation output index = described above. Downstream LFBs connected to the success output group = may be various LFBs for encapsulation like LFBs for Ethernet = encapsulation and for PPP encapsulation, various LFBs for local = processing, and LFBs for redirecting packets to CE for processing. Next = hop table uses the encapsulation output index to indicate which port = instance in the output group a packet should go.=20 Every port instance of the success output group will produce metadata of = output logical port ID and next hop IP address for every output packet. = These metadata will be used by downstream LFBs to further implementing = forwarding or local processing. Note that for next hop option marked as = local host processing, the next hop IP address metadata for the packet = is exactly substituted with the destination IP address of the packet. The exception output of the LFB is a singleton output. It outputs = packets with exceptional cases. An exception ID further indicates the = exception reasons. Exception may happen when a hop selector is found = invalid, or ICMP packets need to be generated (Editorial note: more = discussions here), etc. The exception ID is also produced as a metadata = by the output to be transmitted to a downstream LFB. There are also some other components defined in the LFB for various = purposes. See section 6 for detailed XML definitions of the LFB.=20 5.3.3. IPv6UcastLPM The LFB abstracts the process for IPv6 unicast LPM table looking up.=20 Definitions of this IPv6UcastLPM LFB is very identical to IPv4UcastLPM = LFB except that all IP addresses related are changed from IPv4 addresses = to IPv6 addresses. See section 6 for detailed XML definitions of this = LFB.=20 5.3.4. IPv6NextHop This LFB abstracts the process of next hop information application to = IPv6 packets.=20 Definitions of this IPv6NextHop LFB is very identical to IPv4NextHop LFB = except that all IP addresses related are changed from IPv4 addresses to = IPv6 addresses. See section 6 for detailed XML definitions of this LFB. = 5.4. Address Resolution LFBs The address resolution LFBs abstracts the process for address resolution = functions. In the process, address resolution protocols, like ARP = protocol for IPv4 and neighbor discovery protocol for IPv6, are applied. = There exist two schema under ForCES architecture to implement address = resolution function. One is for FE to implement the address resolution = by use of address resolution LFBs as defined in this section. The other = is to offload the address resolution from FE to CE. In this case, = address resolution LFBs will not be used. All address resolution = protocol messages FE has received will be redirected to CE via ForCES = protocol [RFC5810]. CE is responsible to process the protocol messages = and generate new address resolution messages to send to outer network = via FE using ForCES prococol [RFC5810]. CE will also use ForCES protocol = to manage the address resolution tables, like the ARP table and the = neighbor table, in Ethernet encapsulator LFB.=20 According to address resolution individually for IPv4 or IPv6 packets, = an ARP LFB and an ND(neighbor discovery) LFB are defined as below. 5.4.1. ARP=20 The ARP LFB provides the function of address resolution for IPv4 nodes. = Two singleton inputs are defined for the LFB. One is for ARP protocol = packet input. The packets are usually come from upstream LFBs like an = Ethernet classifier LFB where ARP protocol messages are categorized. The = frame type hence expected is the ARP protocol message type. The other = singleton input is for IPv4 packets that usually come from Ethernet = encapsulator LFB and are unable to find L2 information to finish = encapsulation process in that LFB. The associated metadata include a = next hop IPv4 address, which is the encapsulator LFB can not find its = binding Ethernet MAC address, the logical port ID, and the VLAN ID = (Editorial note: need more discussions on what metadata these inputs = should expect.) There are two components defined in the ARP LFB. One is the ARP table. = Note that ARP table in this LFB is defined as an alias component of ARP = table in Ethernet encapsulator LFB. This means management of the ARP = table will be shared by both of the LFBs. The ARP LFB will manage the = table and refresh the table entries based on the ARP protocol messages = received. The protocol messages provide bindings of IPv4 addresses with = destination MAC addresses. The ARP table fields include destination IP = address, logical port ID, source MAC address, and destination MAC = address (Editorial note: need more discussions on what fields needed). Another component defined is the local IPv4 address table for all ports = of the FE. An FE port here is indexed by a logical port ID. Note that = every physical port may be capable of multiple logical ports with = multiple IP or MAC addresses.=20 The port IPv4 address table provides binding of a logical port to an IP = address and a MAC address (Editorial note: is it possible one logical = port binds multiple IP addresses?). The table will be used by the ARP = LFB to check locality of arrived ARP protocol messages. Usually the = table will be configured by CE via ForCES protocol.(Editorial note: need = more discussions on what fields the port IP address table needs and how = the logical port ID and MAC address take effect in the process)=20 Two singleton outputs are defined for the ARP LFB. One is for ARP = protocol message output. All ARP request and response packets are sent = out from here to downstream LFB, which usually is Ethernet encapsulation = LFB.=20 Another output is for sending all packets that are input to this LFB = because they can not find L2 encapsulation information when doing = encapsulation in an Ethernet encapsulation LFB. They are just sent back = to the LFB for encapsulation again with the expected refreshed ARP table = contents. (Editorial note: need more discussions on how the mechanism = should be defined for those packets unable to do encapsulation in = encapsulation LFB. An alternative schema is to let the ARP LFB to do = encapsulation rather than send them back to encapsulation LFB, then = output the packets directly to an LFB after the encapsulation LFB). =20 5.4.2. ND (TBD) 5.5. Redirect LFBs Redirect LFBs abstract data packets transportation process between CE = and FE. Some packets output from some LFBs may have to be delivered to = CE for further processing, and some packets generated by CE may have to = be delivered to FE and further to some specific LFBs for data path = processing. According to RFC 5810 [RFC5810], data packets and their = associated metadata are encapsulated in ForCES redirect message for = transportation between CE and FE. We define two LFBs to abstract the = process, a RedirectIn LFB and a RedirectOut LFB. Usually, in an LFB = topology of an FE, only one RedirectIn LFB instance and one RedirectOut = LFB instance exist.=20 5.5.1. RedirectIn A RedirectIn LFB abstracts the process for CE to inject data packets = into FE LFB topology so as to input data packets into FE data paths. = >From LFB topology point of view, the RedirectIn LFB acts as a source = point for data packets coming from CE, therefore the RedirectIn LFB is = defined with only one output, while without any input.=20 Output of the RedirectIn LFB is defined as a group output. Packets = produced by the output will have arbitrary frame types decided by CE = which generates the packets. Possible frames may include IPv4, IPv6, or = ARP protocol packets. CE may associate some metadata to indicate the = frame types. CE may also associate other metadata to data packets to = indicate various information on the packets. Among them, there MUST = exist a 'RedirectIndex' metadata, which is an integer acting as an = index. When CE transmits the metadata and a binging packet to a = RedirectIn LFB, the LFB will read the metadata and output the packet to = one of its group output port instance, whose port index is just as = indicated by the metadata. Detailed XML definition of the metadata is in = the XML for base type library as in Section 4.4.=20 All metadata from CE other than the 'RedirectIndex' metadata will output = from the RedirectIn LFB along with their binding packets. Note that, a = packet without a 'RedirectIndex' metadata associated will be dropped by = the LFB. There is no component defined for current version of RedirectIn LFB. = Detailed XML definitions of the LFB can be found in Section 6. 5.5.2. RedirectOut A RedirectOut LFB abstracts the process for LFBs in FE to deliver data = packets to CE. From LFB topology point of view, the RedirectOut LFB acts = as a sink point for data packets going to CE, therefore the RedirectOut = LFB is defined with only one input, while without any output.=20 Input of the RedirectOut LFB is defined as a singleton input, but it is = capable of receiving packets from multiple LFBs by multiplexing the = singleton input. Packets expected by the input will have arbitrary frame = types. All metadata associated with the input packets will be delivered = to CE via a ForCES protocol redirect message [RFC5810]. The input will = expect all types of metadata.=20 There is no component defined for current version of RedirectOut LFB. = Detailed XML definitions of the LFB can be found in Section 6. 5.6. General Purpose LFBs =20 5.6.1. BasicMetadataDispatch A basic medatata dispatch LFB is defined to abstract a process in which = a packet is dispatched to some path based on its associated metadata = value.=20 =20 The LFB is with a singleton input. Packets of arbitrary frame types can = input into the LFB. Whereas, every input packet is required to be = associated with a metadata that will be used by the LFB to do dispatch. = If a packet is not associated with such metadata, the packet will be = dropped inside the LFB. =20 A group of output is defined to output packets according to a = MetaDispatchTable as defined a component in the LFB. The table contains = the fields of a metadata ID, a metadata value, and an output port index. = A packet, if it is associated with a metadata with the metadata ID, will = be output to the group port instance with the index corresponding to the = metadata value in the table. The metadata value ussed by the table is = required with an interger data type. This means this LFB currently only = allow a metadata with an interger value to be used for dispatch.=20 =20 Moreover, the LFB is defined with only one metadata adopted for = dispatch, i.e., the metadata ID in the dispatch table is always the same = for all table rows. =20 A more complex metadata dispatch LFB may be defined in future version of = the library. In that LFB, multiple tuples of metadata may be adopted to = dispatch packets. 5.6.2. GenericScheduler=20 There exist various kinds of scheduling strategies with various = implementations. As a base LFB library, this document only defines a = preliminary generic scheduler LFB for abstracting a simple scheduling = process. The generic scheduler LFB is the one. Users may use this LFB as = a basic scheduler LFB to further construct more complex scheduler LFBs = by means of inheritance as described in RFC 5812 [RFC5812]. The LFB describes scheduling process in the following model: . It is with a group input and expects packets with arbitrary frame = types to arrive for scheduling. The group input is capable of multiple = input port instances. Each port instance may be connected to different = upstream LFB output. No metadata is expected for each input packet.=20 . Multiple queues reside at the input side, with every input port = instance connected to one queue. . Every queue is marked with a queue ID, and the queue ID is exactly the = same as the index of corresponding input port instance. . Scheduling disciplines are applied to all queues and also all packets = in the queues. . Scheduled packets are output from a singleton output port of the LFB.=20 Two LFB components are defined to further describe above model. A = scheduling discipline component is defined for CE to specify a = scheduling discipline to the LFB. Currently defined scheduling = disciplines only include FIFO and round robin(RR). For FIFO, we limit = above model that when a FIFO discipline is applied, it is require that = there is only one input port instance for the group input. If user = accidentally defines multiple input port instances for FIFO scheduling, = only packets in the input port with lowest port index will be scheduled = to output port, and all packets in other input port instances will just = ignored. We specify that if the generic scheduler LFB is defined only one input = port instance, the default scheduling discipline is FIFO. If the LFB is = defined with more than one input port instances, the default scheduling = discipline is round robin (RR). A current queue depth component is defined to allow CE to query every = queue status of the scheduler. Using the queue ID as the index, CE can = query every queue for its used length in unit of packets or bytes.=20 Several capabilities are defined for the LFB. A queue number limit is = defined which limits the scheduler maximum supported queue number, which = is also the maximum number of input port instances. Capability of = disciplines supported provides scheduling discipline types supported by = the FE to CE. Queue length limit provides the capability of storage = ability for every queue. More complex scheduler LFB may be defined with more complex scheduling = discipline by succeeding this LFB. For instance, a priority scheduler = LFB may be defined only by inheriting this LFB and define a component to = indicate priorities for all input queues.=20 See Section 6 for detailed XML definition for this LFB. ------=_NextPart_000_065B_01CC04DF.B4F2C950-- From wmwang2001@hotmail.com Wed Apr 27 06:28:58 2011 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 008F5E0764 for ; Wed, 27 Apr 2011 06:28:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.154 X-Spam-Level: ** X-Spam-Status: No, score=2.154 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_28=0.6, J_CHICKENPOX_29=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_38=0.6, J_CHICKENPOX_39=0.6, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OASEmtoWtJ8s for ; Wed, 27 Apr 2011 06:28:50 -0700 (PDT) Received: from blu0-omc2-s7.blu0.hotmail.com (blu0-omc2-s7.blu0.hotmail.com [65.55.111.82]) by ietfa.amsl.com (Postfix) with ESMTP id 43A40E069F for ; Wed, 27 Apr 2011 06:28:49 -0700 (PDT) Received: from BLU0-SMTP155 ([65.55.111.73]) by blu0-omc2-s7.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Apr 2011 06:28:48 -0700 X-Originating-IP: [220.184.223.53] X-Originating-Email: [wmwang2001@hotmail.com] Message-ID: Received: from WmwangHome ([220.184.223.53]) by BLU0-SMTP155.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Apr 2011 06:28:41 -0700 From: "Wang,Weiming" To: "Chuanhuang Li" , "Haleplidis Evangelos" , , "'Joel M. Halpern'" , "Jamal Hadi Salim" Date: Wed, 27 Apr 2011 21:28:40 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0054_01CC0522.139F0F80" 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.6090 X-OriginalArrivalTime: 27 Apr 2011 13:28:42.0724 (UTC) FILETIME=[06EBDA40:01CC04DF] Subject: [forces] Fw: LFBlib readability suggestions X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 13:28:58 -0000 ------=_NextPart_000_0054_01CC0522.139F0F80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SSdtIGZyYWlkIHRoZXJlcyBzb21ldGhpbmcgdW51c2FsIGhhcHBlbmVkIGFnYWluIHdpdGggdGhl IG1haWwgc3lzdGVtLCBzbyBwb3N0IGFnYWluLg0KDQp0aGFua3MsDQpXZWltaW5nDQoNCi0tLS0t IE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiV2FuZyxXZWltaW5nIiA8d213YW5nMjAw MUBob3RtYWlsLmNvbT4NClRvOiAiQ2h1YW5odWFuZyBMaSIgPGNodWFuaHVhbmdfbGlAbWFpbC56 amdzdS5lZHUuY24+OyAiSGFsZXBsaWRpcyBFdmFuZ2Vsb3MiIDxlaGFsZXBAZWNlLnVwYXRyYXMu Z3I+OyA8Zm9yY2VzQGlldGYub3JnPg0KQ2M6ICInSm9lbCBNLiBIYWxwZXJuJyIgPGptaEBqb2Vs aGFscGVybi5jb20+OyAiJ3dtd2FuZyciIDx3bXdhbmdAempnc3UuZWR1LmNuPg0KU2VudDogV2Vk bmVzZGF5LCBBcHJpbCAyNywgMjAxMSAxOjMzIFBNDQpTdWJqZWN0OiBSZTogW2ZvcmNlc10gTEZC bGliIHJlYWRhYmlsaXR5IHN1Z2dlc3Rpb25zDQoNCg0KPiBIaSAgRXZhbmdlbG9zIGFuZCBKYW1h bCwNCj4gDQo+IFRoZXJlIGFyZSBzZXZlcmFsIGNoYW5nZXMgc2luY2UgMDMgdmVyc2lvbiBvbiB0 aGUgTEZCIGRlc2NyaXB0aW9uIHNlY3Rpb24uIEF0dGFjaGVkIGlzIHRoZSBsYXRlc3QgdGV4dCB0 aGF0IEkndiBiZWVuIG1haW50YWluaW5nLiBQbHMgdXNlIHRoaXMgdGV4dCBhcyB5b3VyIGJhc2Ug dGV4dCB0byBtYWtlICB0aGUgbW9kaWZpY2F0aW9uLiANCj4gDQo+IEknbCBpbmNvcnBhcmF0ZSBl dmVyeSBMRkIgZGVzY3JpcHRpb24gdGV4dCBzaW5jZSBpdCBoYXMgYmVlbiBtYWRlIGNvbnNlbnN1 cyBieSB0aGUgbGlzdC4NCj4gDQo+IEFub3RoZXIgc3VnZ2VzdGlvbiBpcywgRXZhbmdlbG9zLCBw bHMgbWFrZSBhIHRpdGxlIHdpdGggdGhlIExGQiBuYW1lIGZvciBldmVyeSB0ZXh0IG1vZGlmaWNh dGlvbiBzbyB0aGF0IHdlIGNhbiB0cmFjZSB0aGUgZGlzY3Vzc2lvbnMgZWFzaWx5LiANCj4gDQo+ IHRoYW5rcyBhIGxvdC4NCj4gV2VpbWluZw0KPiANCj4gLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAt LS0tLSANCj4gRnJvbTogIkNodWFuaHVhbmcgTGkiIDxjaHVhbmh1YW5nX2xpQG1haWwuempnc3Uu ZWR1LmNuPg0KPiANCj4+IEhpLCBFdmFuZ2Vsb3MNCj4+ICAgICANCj4+ICAgIFdoZW4geW91IGFy ZSByZW9yZ2FuaXppbmcgdGhlIGRyYWZ0IGNvbnRlbnQsIGFuZCBpZiB0aGVyZSBpcyBjb250cmFk aWN0aW9uIGJldHdlZW4gDQo+PiB0ZXh0IGFuZCB0aGUgbGF0ZXN0IFhNTCB3aGljaCBpIGhhZCBw b3N0IG9uIGxpc3QgYmVmb3JlLCBwbGVhc2UgdXNlIHRoZSBYTUwgYXMgZ3VpZGFuY2UuDQo+PiBU aGlzIGlzIGJlY2F1c2UgYWZ0ZXIgZHJhZnQtMDMsIHdlIGhhZCBkaXNjdXNzZWQgc29tZSBjb250 ZW50cyBhbmQgcmVhY2hlZCBzb21lIGNvbnNlbnN1c2VzLg0KPj4gQW5kIEkgdGhpbmsgbWF5YmUg V2VpbWluZyBoYXMgdGhlIGxhdGVzdCBkcmFmdCBjb250ZW50cyB0ZXh0Lg0KPj4gVGhhbmtzIQ0K Pj4gDQo+PiBZb3VycywNCj4+IENodWFuaHVhbmcNCj4+IA0KPj4gPT09PT09PSAyMDExLTA0LTI3 IDA0OjU4OjA4IEhhbGVwbGlkaXMgRXZhbmdlbG9zLCB3cm90ZTogPT09PT09PQ0KPj4gDQo+Pj5H cmVldGluZ3MgdG8gYWxsLA0KPj4+DQo+Pj5BZnRlciBKYW1hbCdzIHN1Z2dlc3Rpb24gSSB0b29r IGhpcyBpbml0aWF0aXZlIGFuZCBjb21wbGV0ZWQgdGhlIGV0aGVycGh5Y29wDQo+Pj5kZWZpbml0 aW9uLg0KPj4+DQo+Pj5QbGVhc2UgdGFrZSBhIGxvb2sgYW5kIGNvbW1lbnQsIGluIHRoZSBtZWFu dGltZSBJJ2xsIHN0YXJ0IHdvcmtpbmcgb24gdGhlDQo+Pj5FdGhlck1hY0luLg0KPj4+DQo+Pj5B Ym91dCBKYW1hbCdzIGNvbW1lbnRzOg0KPj4+DQo+Pj5YWFg6IEl0IG1heSBtYWtlIHNlbnNlIHRv IGhhdmUgZWFjaCBvZiBDb21wb25lbnRzLCBDYXBhYmlsaXRpZXMgYW5kIEV2ZW50cw0KPj4+b24g aXRzIG93biBzZWN0aW9uPw0KPj4+DQo+Pj5JIHRoaW5rIGl0IGlzIG1vcmUgcmVhZGFibGUgdGhp cyB3YXkgYW5kIGFsc28gZm9sbG93aW5nIHRoZSBzYW1lIGZvcm1hdCBhcw0KPj4+dGhlIG1vZGVs IFJGQyBwcm92aWRlcyBjb25zaXN0ZW5jeS4NCj4+Pg0KPj4+WFhYOiBJIGNvcGllZCB0aGlzIGZy b20gdGhlIGRyYWZ0IGJ1dCBpIHRoaW5rIGl0IG1heSBiZSB3cm9uZy4gVGhlIHhtbCBzYXlzDQo+ Pj50aGlzIGNvbXBvbmVudCBpcyByZWFkLW9ubHkuIEFuZCBpIHJlbWVtYmVyIHdlIGhhZCBhIHZl cnkgbG9uZyBkaXNjdXNzaW9uDQo+Pj4ocmVmZXIgdG8gaG93IG9uZSB3b3VsZCBtYXAgYSBwb3J0 IG5hbWUgdG8gdGhlIFBIWSBvbiBob3cgdGhpcyBJRCBpcyB0byBiZQ0KPj4+dXNlZCkuDQo+Pj4N Cj4+PldlbGwsIGV2ZW4gdGhlIHRleHQgc2F5cyB0aGF0OiAiIGlzIGRlZmluZWQgc28gdGhlIENF IGNhbiBhc3NpZ24gYW4gSUQgIi4NCj4+PlNpbmNlIHRoZSBDRSBjYW4gYXNzaWduIHRoZSBJRCB0 aGVuIGl0IG11c3QgYmUgcmVhZC13cml0ZS4gSSB0aGluayB3ZSBzaG91bGQNCj4+PmNoYW5nZSBp dCBpbiB0aGUgWE1MLg0KPj4+DQo+Pj5YWFg6IFNob3VsZCB3ZSBiZSBkaXNjdXNzaW5nIGFsbCB0 aGUgY29tcG9uZW50cywgY2FwYWJpbGl0aWVzIGFuZCBldmVudHM/DQo+Pj5pLmUgd2h5IHRoZSBi cmllZiBkZXNjcmlwdGlvbiBiZWxvdz8gRWl0aGVyIHRoYXQgb3IgdGhlIFhNTCBzeW5vcHNpcyBu ZWVkcw0KPj4+dG8gYmUgYSBsb3QgbW9yZSBkZXNjcmlwdGl2ZS4NCj4+Pg0KPj4+SSB0aGluayB3 ZSBzaG91bGQgYmUgZGlzY3Vzc2luZyBBTEwgY29tcG9uZW50cy9jYXBhYmlsaXRpZXMvZXZlbnRz Lg0KPj4+SXQncyBtb3JlIHJlYWRhYmxlIHRoaXMgd2F5LiBTb21lb25lIG5vdCBmYW1pbGlhciB3 aXRoIHhtbCBtYXkgd2FudCB0byByZWFkDQo+Pj5hbmQgdW5kZXJzdGFuZCBpbiB0aGlzIHdheSBv ZiByZWFkaW5nIGluc3RlYWQgb2YgbG9va2luZyBhcm91bmQgaW4gdGhlIHhtbC4NCj4+Pg0KPj4+ QWxzbyB0aGVyZSBpcyBhIHR5cG8gaW4gdGhlIHhtbCBkZWZpbml0aW9uIG9mIHRoZSBFdGhlclBo eUNvcC4gSW4gdGhlDQo+Pj5zeW5vcHNpcyBvZiB0aGUgRHVwbGV4TW9kZUNoYW5nZWQgdGhlcmUg aXMgYSAic3BlZWQuIiBpbiB0aGUgZW5kIHRoYXQgaXMgbm90DQo+Pj5zdXBwb3NlZCB0byBiZSB0 aGVyZS4NCj4+Pg0KPj4+UmVnYXJkcywNCj4+PkV2YW5nZWxvcyBIYWxlcGxpZGlzLg0KPj4+DQo+ Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+IEZyb206IGZvcmNlcy1ib3VuY2Vz QGlldGYub3JnIFttYWlsdG86Zm9yY2VzLWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+Pj4+IEJlaGFs ZiBPZiBKYW1hbCBIYWRpIFNhbGltDQo+Pj4+IFNlbnQ6IFR1ZXNkYXksIEFwcmlsIDI2LCAyMDEx IDI6MDEgUE0NCj4+Pj4gVG86IGZvcmNlc0BpZXRmLm9yZw0KPj4+PiBDYzogQ2h1YW5odWFuZyBM aTsgd213YW5nOyBKb2VsIE0uIEhhbHBlcm4NCj4+Pj4gU3ViamVjdDogW2ZvcmNlc10gTEZCbGli IHJlYWRhYmlsaXR5IHN1Z2dlc3Rpb25zDQo+Pj4+IA0KPj4+PiB0byB0aGUgYXV0aG9ycywNCj4+ Pj4gDQo+Pj4+IEFzIGkgaGF2ZSB3aGluZWQgYmVmb3JlLCB0aGUgZ2VuZXJhbCBkcmFmdCB0ZXh0 IGlzIGhhcmQgdG8gcmVhZC4NCj4+Pj4gSSB0aGluayBtYWtpbmcgdGhpbmdzIGEgbGl0dGxlIG1v cmUgZm9ybWFsIGFzIGluIHRoZSBleGFtcGxlIExGQiBpbiBSRkMNCj4+Pj4gNTgxMiBzZWN0aW9u IDggd2lsbCBnbyBhIGxvbmcgd2F5IHRvIGltcHJvdmUgcmVhZGFiaWxpdHkuDQo+Pj4+IA0KPj4+ PiBJIGhhdmUgYXR0ZW1wdGVkIHRvIHJlZG8gdGhlIEV0aGVyUEhZQ29wIHNlY3Rpb24sIEkgZGlk bnQgZ28gMTAwJSB3aXRoDQo+Pj4+IHRoZSBSRkM1ODEyIGZvcm1hdCBidXQgcGxlYXNlIHRha2Ug YSBsb29rIGluIHBhcnRpY3VsYXIgdGhlICJYWFgiDQo+Pj4+IGFuZCBjcm9zcyByZWZlcmVuY2Ug d2l0aDoNCj4+Pj4gLSB0aGUgdGV4dCB0aGF0IGV4aXN0cyByaWdodCBub3cgaW4gdGhlIGRyYWZ0 DQo+Pj4+IC0gdGhlIHhtbCAoYW5kIGFsc28gdG8gbWFrZSBzdXJlIGl0IGlzIHdlbGwgZGVzY3Jp YmVkKQ0KPj4+PiAtIHRoZSBmb3JtYWwgc2NoZW1lIHRvIGRlc2NyaWJlIHRoaW5ncyBhcyBpIGxh aWQgaXQgb3V0LiBUaGUgbW9kZWwNCj4+Pj4gZHJhZnQgTEZCIGV4YW1wbGUgaW4gc2VjdGlvbiA4 IGlzIGEgZ29vZCBzdGFydC4NCj4+Pj4gDQo+Pj4+IGNoZWVycywNCj4+Pj4gamFtYWwNCj4+Pg0K Pj4gDQo+PiANCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+PiBmb3JjZXMgbWFpbGluZyBsaXN0DQo+PiBmb3JjZXNAaWV0Zi5vcmcNCj4+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZm9yY2VzDQo+Pg0KDQoNCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQoNCg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiBmb3JjZXMgbWFpbGluZyBsaXN0DQo+IGZvcmNlc0BpZXRmLm9yZw0K PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ZvcmNlcw0KPg== ------=_NextPart_000_0054_01CC0522.139F0F80 Content-Type: text/plain; name="section 5.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="section 5.txt" 5. LFB Class Description According to ForCES specifications, LFB (Logical Function Block) is a = well defined, logically separable functional block that resides in an = FE, and is a functionally accurate abstraction of the FE's processing = capabilities. An LFB Class (or type) is a template that represents a = fine-grained, logically separable aspect of FE processing. Most LFBs = are related to packet processing in the data path. LFB classes are the = basic building blocks of the FE model. Note that RFC 5810 has already = defined an 'FE Protocol LFB' which is as a logical entity in each FE to = control the ForCES protocol. RFC 5812 has already defined an 'FE Object = LFB'. Information like the FE Name, FE ID, FE State, LFB Topology in the = FE are represented in this LFB. As specified in section 3.1, this document focuses the base LFB library = for implementing typical router functions, especially for IP forwarding = functions. As a result, LFB classes in the library are all base LFBs to = implement router forwarding. 5.1. Ethernet Processing LFBs=20 As the most popular physical and data link layer protocols, Ethernets = are widely deployed. It becomes a basic requirement for a router to be = able to process various Ethernet data packets.=20 Note that there exist different versions of Ethernet protocols, like = Ethernet V2, 802.3 RAW, IEEE 802.3/802.2, IEEE 802.3/802.2 SNAP. There = also exist varieties of LAN techniques based on Ethernet, like various = VLANs, MACinMAC, etc. Ethernet processing LFBs defined here are intended = to be able to cope with all these variations of Ethernet technology.=20 There are also various types of Ethernet physical interface media. Among = them, copper and fiber media may be the most popular ones. As a base LFB = definition and a start work, the document only defines an Ethernet = physical LFB with copper media. For other media interfaces, specific = LFBs may be defined in the future versions of the library. =20 =20 5.1.1. EtherPHYCop=20 EtherPHYCop LFB abstracts an Ethernet interface at its physical layer. = It limits the physical media to copper. =20 The LFB is defined with one singleton input. The input data of the LFB = are expected to be Ethernet packets. Note that Ethernet packets here = cover all packets encapsulated with different versions of Ethernet = protocols, like Ethernet V2, 802.3 RAW, IEEE 802.3/802.2, IEEE = 802.3/802.2 SNAP. It also includes packets encapsulated with varieties = of LAN techniques based on Ethernet, like various VLANs, MACinMAC, etc. = As a result, we define various Ethernet frames as a frame name called = 'EthernetAll'. In an LFB abstracted processing path, usually the = Ethernet packets are from an upstream LFB like an EtherMACOut LFB. It is = not expected that an input Ethernet packet be associated with some = metadata. After the LFB receives the Ethernet packets, it will further = process the packets at physical layer and eventually put them on the = physical media wire for transmission. Note that the media wire = transmission process in the LFB is abstracted as a default function of = the LFB rather than an input or output interface of the LFB.=20 The LFB is also defined with one singleton output. The output data = produced are also with 'EthernetAll' frame type. Every output data = packet is associated with a 'PHYPortID' metadata to indicate later = processing LFBs of which physical port the packet is from. Note that all = the data packets are originated from media wire inside the LFB, which is = defined as a default function of the LFB. As a physical layer = abstraction module, the LFB does not possess the ability to specify = encapsulations of types of Ethernet, rather, it produces various = Ethernet types just according to what it receives from Ethernet media = wire. In an LFB-based processing path topology, packets output from the = EtherPHYCop lFB will usually go to an LFB like EtherMACIn LFB for = further Ethernet processing. Note that as a base definition, functions like multiple virtual physical = layers are not supported in this LFB version. It may be supported in the = future by defining a subclass or a new version of this LFB. Several components are defined for the LFB.=20 AdminStatus is defined for CE to administratively manage the status of = the LFB. Via the component, CE may startup or shutdown the LFB. The = default status is set to 'Down'. An OperStatus component is = specifically defined for CE to access the actual operational status of = the LFB, in case that a physical layer port may be in a failed state = that its operational status does not correctly reflect administrative = status. A PHYPortStatusChanged event is defined for the LFB to report to = CE whenever there is a port status change during operation. PHYPortID component is defined for CE to assign an ID to the physical = port. The component will be used to produce a metadata=20 associated with every Ethernet packet the LFB receives from media and is = going to hand to later LFBs for further processing.=20 A group of components are defined for link speed management. The = AdminLinkSpeed is for CE to configure proper link speed for the port and = the OperLinkSpeed is for CE to query the actual link speed in operation. = The default value for the AdminLinkSpeed is set to auto-negotiation = mode. A SupportedLinkSpeed capability attribute is also defined for CE = to query the link speed ability. A LinkSpeedChanged event is defined for = the LFB to report to CE whenever there is a link speed change during = operation. A group of components are defined for duplex mode management. The = AdminDuplexMode is for CE to configure proper duplex mode for the port = and the OperDuplexMode is for CE to query the actual duplex mode in = operation. The default value for the AdminDuplexMode is set to = auto-negotiation mode. A SupportedDuplexMode capability is also defined = for CE to query the port duplex mode ability. A DuplexModeChanged event = is defined for the LFB to report to CE whenever there is a duplex mode = change during operation. =20 There are also some other components, capabilities, events defined in = the LFB for various purposes. See section 6 for detailed XML definitions = of the LFB.=20 5.1.2. EtherMACIn =20 EtherMACIn LFB abstracts an Ethernet port at MAC data link layer. It = specifically describes Ethernet processing functions like MAC address = locality check, deciding if the Ethernet packets should be bridged, = provide Ethernet layer flow control, etc.=20 The LFB is defined with one singleton input. The input is expected to = receive all types of Ethernet packets which are usually output from some = Ethernet physical abstraction layer LFB, like an EtherPHYCop LFB. Every = input packet is associated with a metadatum indicating the physical port = ID that the packet comes.=20 Input Ethernet packets will usually be checked for locality. A = LocalMACAddresses component is defined for the LFB so that CE is able to = configure one or more Ethernet MAC addresses to the LFB for the use of = locality check. All packets that do not pass through the locality check = will be dropped in the LFB. A PromiscuousMode component in the LFB is = further defined to decide if the LFB should work in a promiscuous mode. = When in this mode, the LFB will not do the locality check and all = Ethernet packets will pass through the LFB without being dropped.=20 The LFB is defined with two separate singleton outputs. All Output = packets are in Ethernet format, possibly with various Ethernet types. = One singleton output is called NormalPathOut. It usually outputs = Ethernet packets to some LFB like an EtherClassifier LFB for further L3 = forwarding process. Metadata associated with every packet from this = output is PHYPortID, which keeps indicating which physical port the = packet is from.=20 Another singleton output is called L2BridgingPathOut. Although this LFB = library is basically defined to meet typical router functions, it is = with natural requirement that the definitions here should provide = reasonable compatibility considerations for future wider use. The = L2BridgingPathOut is defined to meet the requirement that L2 bridging = functions may be optionally supported simultaneously with L3 processing = and Some L2 bridging LFBs may be defined in the future. A Boolean flag = component called L2BridgingPathEnable is defined to make the L2 bridging = output as optional. An FE that does not support bridging will internally = set this flag to false, and additionally sets the flag property as = read-only. In this case CE then can read the flag to know that the FE = does not support bridging function and the L2 bridging output is always = disabled. An FE that supports L2 bridging will internally set the flag = property as read-write. In this case, CE then can choose to enable or = disable the L2BridgingPathOut output by setting this flag as desired. If = the flag is set to true, by also instantiating some L2 bridging LFB = instances following the L2BridgingPathOut, FE are expected to fulfill L2 = bridging functions. Whereas, in this case, the default value for the = flag is defined as false, meaning L2 bridging output is closed by = default. Note that, when enabled, l2BridgingPathOut will output packets = exactly the same as that in the NormalPathOut output(Editorial note: = need more discussions here on if the L2 output is the same as normal = output). The metadata associated with every packet is also PHYPortID.=20 Ethernet layer flow control is usually implemented cooperatively by = EtherMACIn LFB and EtherMACOut LFB. How the flow control is implemented = is vendor-specific. As an abstraction, this LFB defines two flag = components for CE to enable or disable the flow control functions. The = flow control is further distinguished by Tx flow control and Rx flow = control, separately for sending process and receiving process flow = controls. A TxFlowControl flag and a RxFlowControl flag are then = separately defined. In order for EtherMACOut LFB able to cooperatively = work for flow control, the flags are also referenced in the EtherMACOut = LFB as aliases in this LFB.=20 AdminStatus is defined for CE to administratively manage the status of = the LFB. Via the component, CE can startup or shutdown the LFB. The = default status is set to 'Down'.=20 Note that as a base definition, functions like multiple virtual MAC = layers are not supported in this LFB version. It may be supported in the = future by defining a subclass or a new version of this LFB. There are also some other components, capabilities, events defined in = the LFB for various purposes. See section 6 for detailed XML definitions = of the LFB.=20 5.1.3. EtherClassifier =20 EtherClassifier LFB abstracts the process to decapsulate Ethernet = packets and classify the data packets into various network layer data = packets according to information included in the Ethernet packets = headers.=20 Input of the LFB expects all types of Ethernet packets, including VLAN = Ethernet types. The input is a singleton input which may connect to an = upstream LFB like EtherMACIn LFB. The input is also capable of = multiplexing to allow for multiple upstream LFBs being connected. For = instance, when L2 bridging function is enabled in EtherMACIn LFB, some = L2 bridging LFBs may be applied. In this case, some Ethernet packets = after L2 processing may have to be input to EtherClassifier LFB for = classification, while simultaneously packets directly output from = EtherMACIn may also need to input to this LFB. Input of this LFB is = capable of handling this case. Usually, every input Ethernet packet is = expected to be associated with a PHYPortID metadatum, indicating the = physical port the packet comes from. In some cases, for instance, like = in an MACinMAC case, a LogicalPortID metadatum may be expected to = associate with the Ethernet packet to further indicate which logical = port the Ethernet packet belongs to. Note that PHYPortID metadata is = always expected while LogicalPortID metadata is optionally expected.=20 A VLANInputTable component is defined in the LFB to classify VLAN = Ethernet packets. According to IEEE VLAN specifications, all Ethernet = packets can be recognized as VLAN types by defining that if there is no = VLAN encapsulation in a packet, a case with VLAN tag 0 is considered. = Therefore the table actually applies to every input packet of the LFB. = The table assigns every input packet with a new LogicalPortID according = to the packet incoming port ID and the VLAN ID. A packet incoming port = ID is defined as a physical port ID if there is no logical port ID = associated with the packet, or a logical port ID if there is a logical = port ID associated with the packet. The VLAN ID is exactly the Vlan ID = in the packet if it is a VLAN packet, or 0 if it is not a VLAN packet. = Note that a logical port ID of a packet may be rewritten with a new one = by the VLANInputTable processing.=20 An EtherDispatchTable component is defined to dispatch every Ethernet = packet to a group of outputs according to the logical port ID assigned = by VLANInputTable to the packet and the Ethernet type in the Ethernet = packet header. By CE configuring the dispatch table, the LFB can be = expected to classify various network layer protocol type packets and = make them output at different output port. It is then easily expected = that the LFB classify packets according to protocols like IPv4, IPv6, = MPLS, ARP, ND, etc.=20 Output of the LFB is hence defined as a group output. Because there may = be various types of protocol packets at the output ports, the = frameproduced is defined as arbitrary for the purpose of wide = extensibility in the future. In order for downstream LFBs to use, a = bunch of metadata is produced to associate with every output packet. The = medatdata contain normal information like PHYPortID. It also contains = information on Ethernet type, source MAC address, and destination MAC = address of its original Ethernet packet. Moreover, it contains = information of logical port ID assigned by this LFB. This metadata may = be used by downstream LFBs for packet processing. Lastly, it may = conditionally contain information like VlanID and VlanPriority with the = condition that the packet is a VLAN packet. A MaxOutPutPorts is defined as the capability of the LFB to indicate how = many classification output ports the LFB is capable. /*discussion*/ Note that logical port ID and physical port ID mentioned above are all = originally configured by CE, and are globally effective within an ForCES = NE (Network Element). To distinguish a physical port ID from a logical = port ID in the incoming port ID field of the VLANInputTable, physical = port ID and logical port ID must be assigned with separate number = spaces. /*discussion */ There are also some other components, capabilities, events defined in = the LFB for various purposes. See section 6 for detailed XML definitions = of the LFB.=20 5.1.4. EtherEncapsulator=20 EtherEncapsulator LFB abstracts the process to encapsulate IP packets to = Ethernet packets.=20 Input of the LFB expects types of IP packets, including IPv4 and IPv6 = types. The input is a singleton one which may connect to an upstream LFB = like an IPv4NextHop, an IPv6NextHop, or any LFB which requires to output = packets for Ethernet encapsulation. The input is capable of multiplexing = to allow for multiple upstream LFBs being connected. For instance, an = IPv4NextHop or an IPv6NextHop may concurrently exist, and some L2 = bridging LFBs may also output packets to this LFB simultaneously. Input = of this LFB is capable of handling this case. Usually, every input = Ethernet packet is expected to be associated with an output logical port = ID and a next hop IP address as its metadata. In the case when L2 = bridging function is implemented, an input packet may also optionally = receive a VLAN priority as its metadata. In this case, default value for = this metadata is set to 0. =20 There are several outputs for this LFB. One singleton output is for = normal success packet output. Packets which have found Ethernet L2 = information and have been successfully encapsulated to an Ethernet = packet will output from this port to downstream LFB. Note that this LFB = specifies to use Ethernet II as its Ethernet encapsulation type. Success = output also produces an output logical port ID as metadatum of every = output packet for a downstream LFB to decide which logical port the = packet should go out. The downstream LFB usually dispatches the packets = based on its associated output logical port ID. Hence, a generic = dispatch LFB as defined in Section 5.6.1 may be adopted for dispatching = packets based on output logical port ID. Note that in some implementations of LFBs topology, the processing to = dispatch packets based on an output logical port ID may also take place = before an Ethernet encapsulation,i.e., packets coming into the = encapsulator LFB have already been switched to individual logical output = port paths. In this case, the EtherEncap LFB success output may be = directly connected to a downstream LFB like an EtherMACOut LFB. Another singleton output is for IPv4 packets that are unfortunately = unable to find Ethernet L2 encapsulation information by ARP table in the = LFB. In this case, a copy of the packets may need to be redirected to an = ARP LFB in the FE, or to CE if ARP function is implemented by CE. More = importantly, a next hop IP address metadata should be associated with = every packet output here. When an ARP LFB or CE receives these packets = and associated next hop IP address metadata, it may be expected to = generate ARP protocol messages based on these packets next hop IP = addresses to try to get L2 information for these packets. Refreshed L2 = information is then able to be added in ARP table in this encapsulator = LFB by ARP LFB or by CE. As a result, these packets are then able to = successfully find L2 information and be encapsulated to Ethernet = packets, and output via the normal success output to downstream LFB. = (Editorial note1: may need discussion on what more metadata this output = packets need? Note that the packets may be redirected to CE and CE = should know what the purpose of the packets for. A metadata may need to = indicate this. Editorial note2: we may adopt another way to address the = case of packets unable to do ARP. The packets may be redirected to ARP = LFB or CE without keeping a copy of them in this encapsulator LFB. We = expect that after ARP LFB or CE have processed ARP requests based on the = packets, the packets will be redirected back from ARP LFB or CE to this = encapsulator LFB for Ethernet encapsulation. At this time, it is hoped = the ARP table has been refreshed with new L2 information that will make = these packets able to find) A more singleton output is for IPv6 packets that are unfortunately = unable to find Ethernet L2 encapsulation information by Neighbor table = in the LFB. In this case, a copy of the packets may need to be = redirected to an ND LFB in the FE, or to CE if IPv6 Neighbor discovery = function is implemented by CE. More importantly, a next hop IP address = metadata should be associated with every packet output here. When the ND = LFB or CE receives these packets and associated next hop IP address = metadata, it may be expected to generate neighbor discovery protocol = messages based on these packets next hop IP addresses to try to get L2 = information for these packets. Refreshed L2 information is then able to = be added in neighbor table in this LFB by ND LFB or by CE. As a result, = these packets are then able to successfully find L2 information and be = encapsulated to Ethernet packets, and output via the normal success = output to downstream LFB.(Editorial note: may need discussion on what = more metadata this output packets need? Note that the packets may be = redirected to CE and CE should know what the purpose of the packets for. = A metadata may need to indicate this) A singleton output is specifically defined for exception packets output. = All packets that are abnormal during the operations in this LFB are = output via this port. Currently, only one abnormal case is defined, that = is, packets can not find proper information in a VLAN output table.=20 The VLAN output table is defined as the component of the LFB. The table = uses a logical port ID as an index to find a VLAN ID and a new output = logical port ID. In reality, the logical port ID applied here is the = output logical port ID received from every input packet in its = associated metadata. According to IEEE VLAN specifications, all Ethernet = packets can be recognized as VLAN types by defining that if there is no = VLAN encapsulation in a packet, a case with VLAN tag 0 is considered. = Therefore, every input IP packet actually has to look up the VLAN output = table to find out a VLAN ID and a new output logical port ID according = to its original logical port ID. The ARP table in the LFB is defined as a component of the LFB. The table = is for IPv4 packet to find its next hop Ethernet layer MAC addresses. = Input IPv4 packet will use an output logical port ID which is got by = looking up the VLAN output table, and a next hop IPv4 address which is = got by upstream next hop applicator LFB, to look up the ARP table to = find the Ethernet L2 information, i.e., the source MAC address and = destination MAC address.=20 The neighbor table is defined as another component of the LFB. The table = is for IPv6 packet to find its next hop Ethernet layer MAC addresses. = Like the ARP table, input IPv6 packet will use its output logical port = ID got from looking up the VLAN output table, and the packet next hop = IPv4 address got by upstream next hop applicator LFB, to look up the = neighbor table to find the Ethernet source MAC address and destination = MAC address. As will be described in the address resolution LFBs section (section = 5.4), Layer 2 address resolution protocols may be implemented with two = choices. One is by FE with specific address resolution LFB, like an ARP = LFB or an ND LFB. The other is to redirect address resolution protocol = messages to CE for CE to implement the function. =20 As described in section 5.4, the ARP LFB defines the ARP table in this = encapsulator LFB as its alias, and the ND LFB defines the neighbor table = as its alias. This means that the ARP table or the neighbor table will = be maintained or refreshed by the ARP LFB or the ND LFB when the LFBs = are used.=20 Note that the ARP table and the neighbor table defined in this LFB are = all with property of read-write. CE can also configure the tables by = ForCES protocol [RFC5810]. This makes possible that IPv4 ARP protocol or = IPv6 Neighbor Discovery protocol may be implemented at CE side,i.e., = after CE manages an ARP or Neighbor discovery protocol and gets address = resolution results, CE can configure them to an ARP or neighbor table in = FE. With all the information got from VLAN table and ARP or Neighbor table, = input IPv4 or IPv6 packets are then able to be encapsulated to Ethernet = layer packets. Note that according to IEEE 802.1Q, if input packets are = with non-zero VLAN priority metadata, the packets will always be = encapsulated with a VLAN tag, no matter the value of VLAN ID is zero or = not. If the VLAN priority and the VLAN ID are all zero, the packets will = be encapsulated without a VLAN tag. Successfully encapsulated packets = are then output via success output port. There are also some other components, capabilities, events defined in = the LFB for various purposes. See section 6 for detailed XML definitions = of the LFB.=20 5.1.5. EtherMACOut=20 EtherMACOut LFB abstracts an Ethernet port at MAC data link layer. It = specifically describes Ethernet packet output process. Ethernet output = functions are closely related to Ethernet input functions, therefore = many components defined in this LFB are actually alias of EtherMACIn = LFB. The LFB is defined with one singleton input(Editorial note: do we need = another input for L2 bridging input?). The input is expected to receive = all types of Ethernet packets which are usually output from some = Ethernet encapsulation LFB. Every input packet is associated with a = metadatum indicating the physical port ID that the packet will = go(Editorial note: Ethernet encapsulation LFB actually generate logical = port ID metadata, how has it been changed to physical port ID?).=20 The LFB is defined with a singleton output. All Output packets are in = Ethernet format, possibly with various Ethernet types. Downstream LFB = the output links to is usually Ethernet physical LFBs like EtherPHYcop = LFB. Metadata associated with every packet from this output is = PHYPortID, which keeps indicating which physical port the packet is to.=20 Ethernet layer flow control is usually implemented cooperatively by = EtherMACIn LFB and EtherMACOut LFB. How the flow control is implemented = is vendor-specific. As an abstraction, this LFB defines two flag = components for CE to enable or disable the flow control functions, a = TxFlowControl flag and a RxFlowControl flag, and they are all defined as = aliases of EtherMACIn LFB.=20 AdminStatus is defined for CE to administratively manage the status of = the LFB. Via the component, CE can startup or shutdown the LFB. The = default status is set to 'Down'. =20 Note that as a base definition, functions like multiple virtual MAC = layers are not supported in this LFB version. It may be supported in the = future by defining a subclass or a new version of this LFB. There are also some other components, capabilities, events defined in = the LFB for various purposes. See section 6 for detailed XML definitions = of the LFB.=20 5.2. IP Packet Validation LFBs An LFB is defined to abstract IP packet validation process. An = IPv4Validator LFB is specifically for IPv4 protocol validation and an = IPv6Validator LFB for IPv6. 5.2.1. IPv4Validator This LFB performs IPv4 packets validation according to RFC 1812.=20 Input of the LFB always expects packets which have been indicated as = IPv4 packets by an upstream LFB, like an EtherClassifier LFB. There is = no specific metadata expected by the input of the validator LFB.=20 Note that, as a default provision of RFC 5812, in FE model, all metadata = produced by upstream LFBs will pass through all downstream LFBs by = default without being specified by input port or output port. Only those = metadata that will be used(consumed) by an LFB will be explicitly marked = in input of the LFB as expected metadata. For instance, in this LFB, = even there is no specific metadata expected, metadata like PHYPortID = produced by some upstreaming PHY LFBs will always pass through this LFB. = In some cases, if some component in the LFB may use the metadata, it = actually still can use it regardless of whether the metadata has been = expected or not. Four output ports are defined to output various validation results. All = validated IPv4 unicast packets will be output at the singleton = IPv4UnicastOut port. All validated IPv4 multicast packets will be output = at the singleton IPv4MulticastOut port. There is no metadata = specifically required to be produced at these output ports.=20 A singleton ExceptionOut port is defined to output packets which have = been validated as exceptional packets. An exception ID metadata is = produced to indicate which causes it exceptional. Currently defined = exception types include cases like, packet with destination address = equal to 255.255.255.255, Packet with expired TTL, Packet with header = length more than 5 words, and packet IP head including Router Alert = options, etc. Note that even TTL is checked for validity here, actual = operation like decrease of TTL will not be made here, rather made by = followed forwarding LFB. A singleton output is defined for all packets which have failed the = packet validation. A validate error ID is associated to every failed = packet to indicate the reasons like an invalid packet size, wrong IP = protocol version, wrong checksum, etc.=20 There are also some other components defined in the LFB for various = purposes. See section 6 for detailed XML definitions of the LFB.=20 5.2.2. IPv6Validator This LFB performs IPv6 packets validation according to RFC 2460.=20 Input of the LFB always expects packets which have been indicated as = IPv6 packets by an upstream LFB like an EtherClassifier LFB. There is no = specific metadata expected by the input of the validator LFB.=20 Similar to IPv4 validator LFB, IPv6Validator LFB has also defined four = output ports to output various validation results. All validated IPv6 = unicast packets will be output at the singleton IPv6UnicastOut port. All = validated IPv6 multicast packets will be output at the singleton = IPv6MulticastOut port. There is no metadata specifically required to be = produced at these output ports. A singleton ExceptionOut port is defined to output packets which have = been validated as exceptional packets. An exception ID is produced to = indicate which causes it exceptional. Currently, exception types include = the following cases:=20 . a packet with hop limit to zero . a packet with a link-local destination address.=20 . a packet with a link-local source address. . a packet with destination all-routers. . a packet with destination all-nodes. . a packet with next header set to Hop-by-Hop. A singleton output is defined for packets which have failed the packet = validation. A validate error ID is associated to every failed packet to = indicate the reasons for the failures. The reasons may include an = invalid packet size, wrong IPv6 protocol version, wrong source or = destination IPv6 addresses, etc. There are also some other components defined in the LFB for various = purposes. See section 6 for detailed XML definitions of the LFB.=20 5.3. IP Forwarding LFBs IP Forwarding LFBs are specifically defined to abstract the IP = forwarding processes. As definitions for a base LFB library, this = document restricts its LFB definition scope for IP forwarding jobs only = to IP unicast forwarding. LFBs for jobs like IP multicast may be defined = in future versions of the document.=20 A typical IP unicast forwarding job is usually realized by looking up = some forwarding information table to find some next hop information, and = then based on the next hop information, forwarding packets to specific = output ports. It usually takes two steps to do so, firstly to look up a = forwarding information table by means of Longest Prefix Matching(LPM) = rule to find a next hop index, then to use the index to look up a next = hop information table to find enough information to submit packets to = output ports. This document abstracts the forwarding processes mainly = based on the two steps model. However, there actually exists other = models, like one which may only have a forwarding information base that = have conjoined next hop information together with forwarding = information. In this case, if ForCES technology is to be applied, some = translation work will have to be done in FE to translate attributes = defined by this document into real attributes the implementation has = actually applied.=20 Based on the IP forwarding abstraction, two kind of typical IP unicast = forwarding LFBs are defined, Unicast LPM lookup LFB and next hop = application LFB. They are further distinguished by IPv4 and IPv6 = protocols. 5.3.1. IPv4UcastLPM The LFB abstracts the process for IPv4 unicast LPM table looking up.=20 Input of the LFB always expects to receive IPv4 unicast packets. An IPv4 = prefix table is defined as a component for the LFB to provide forwarding = information for every input packet. The destination IPv4 address of = every packet is as the index to look up the table with the rule of = longest prefix matching(LPM). A hop selector is the matching result, = which will be output to downstream LFBs as an index for next hop = information.=20 Normal output of the LFB is a singleton output, which will output IPv4 = unicast packet that has passed the LPM lookup and got a hop selector as = the lookup result. The hop selector is associated with the packet as a = metadatum. Followed the normal output of the LPM LFB is usually a next = hop applicator LFB. The LFB receives packets with their next hop IDs and = based on the next hop IDs to forward the packets. A hop selector = associated with every packet from the normal output will directly act as = a next hop ID for a next hop applicator LFB.=20 The LFB is defined to provide some facilities to support users to = implement equal-cost multi-path routing (ECMP) or reverse path = forwarding (RPF). However, this LFB itself does not provide ECMP or RPF. = To implement ECMP or RPF, additional specific LFBs, like a specific ECMP = LFB, will have to be defined. This work may be done in the future = version of the document. For the LFB to support ECMP, an ECMP flag is defined in the prefix table = entries. When the flag is set to true, it indicates this table entry is = for ECMP only. In this case, the hop selector in this table entry will = be used as an index for a downstream specific ECMP LFB to find its = correspondent next hop IDs. When ECMP is applied, it will usually get = multiple next hops information.=20 To distinguish normal output from ECMP case output, a specific ECMP = output is defined. A packet, which has passed through prefix table entry = lookup with true ECMP flag, will always output from this port, with the = hop selector being its lookup result. The output will usually directly = go to a downstream ECMP processing LFB. In the ECMP LFB, based on the = hop selector, multiple next hop IDs may be found, and more ECMP = algorithms may be applied to optimize the route. As the result of the = ECMP LFB, it will output optimized one or multiple next hop IDs to its = downstream LFB that is usually a next hop applicator LFB. For the LFB to support RPF, a default route flag is defined in the = prefix table entry. When set true, the prefix entry is identified as a = default route, and also as a forbidden route for RPF. To implement = various RPF, one or more specific LFBs have to be defined. This job may = be done for the future version of the library.=20 An exception output is defined to allow some exceptional packets to = output here. Exceptions include cases like packets can not find any = routes by the prefix table.=20 There are also some other components defined in the LFB for various = purposes. See section 6 for detailed XML definitions of the LFB.=20 5.3.2. IPv4NextHop This LFB abstracts the process of next hop information application to = IPv4 packets.=20 The LFB receives an IPv4 packet with an associated next hop ID, and uses = the ID to look up a next hop table to find an appropriate output port = from the LFB. Simultaneously, the LFB also implements TTL operation and = checksum recalculation of every IPv4 packet received.=20 Input of the LFB is a singleton one which expects to receive IPv4 = unicast packets and hop selector metadata from an upstream LFB. Usually, = the upstream LFB is directly an IPv4UnicastLPM LFB=A3=ACwhile it is = possible some other upstream LFB may be applied. For instance, when ECMP = is supported, the upstream LFB may be some specific ECMP LFB.=20 The next hop ID in hop selector metadata of a packet is then used as an = index to look up a next hop table defined in the LFB. Via this table and = the next hop index, important information for forwarding the packet is = found. Every next hop table entry includes the following information:=20 . output logical port ID, which will be used by downstream LFBs to find = proper output port. . next hop option, which decides if packets with next hop of this table = entry are destinated to locally attached hosts or not. Locally attached = hosts are hosts in the same subnet with this router. Next hop option is = marked as 'forwarded to locally attached host' if the next hop entry is = for locally attached hosts delivery. All other next hop entry will be = marked with 'normal forwarding'. If a data packet passes through next = hop entries with its next hop option marked with forwarded to locally = attached host, the next hop IP address metadata associated with the data = packet when output from the LFB will be forced to set to the destination = IP address of the data packet. If a data packet passes through a next = hop entry with its option being normal forwarding, the next hop IP = address metadata at output will be set to the next hop IP address as = indicated by this next hop entry. Advantage to define this next hop = option for locally attached hosts is, in this way, the next hop entry = number may be greatly reduced in the case there are a vast number of = locally attached hosts.=20 . next hop IP address, which will be used by downstream LFB to find = proper output port IP address for this packet. Note that when next hop = option is set to 'forwarded to locally attached host', this entry field = becomes invalid. In this case the next hop IP address is assigned = directly by destination IP address of the data packet pass through this = entry check. . encapsulation output index, which is used by data packet to find = proper output of this LFB. Usually, this index can be used to indicate = which encapsulation followed the LFB may be applied to data packets pass = through this next hop entry check and to classify the packets to = different instance of a group output port. Moreover, this index can also = be used to purely indicate output port instance to act as a classifier = based on next hop IDs. For instance, a next hop table entry can be = defined with its encapsulation output index being directed to an output = port which is followed with LFBs that will redirect data packets to = Control Element(CE). A next hop entry can also be defined for some data = packets that need special local processing of the Forwarding = Element(FE). In this case it is not really acting as an encapsulation = index, rather a pure output index. As a result, the LFB is defined with two output ports. One is for = success output and another is for exception output. Success output is a = group output, with an index to indicate which output instance in the = group is adopted. The index is exactly the encapsulation output index = described above. Downstream LFBs connected to the success output group = may be various LFBs for encapsulation like LFBs for Ethernet = encapsulation and for PPP encapsulation, various LFBs for local = processing, and LFBs for redirecting packets to CE for processing. Next = hop table uses the encapsulation output index to indicate which port = instance in the output group a packet should go.=20 Every port instance of the success output group will produce metadata of = output logical port ID and next hop IP address for every output packet. = These metadata will be used by downstream LFBs to further implementing = forwarding or local processing. Note that for next hop option marked as = local host processing, the next hop IP address metadata for the packet = is exactly substituted with the destination IP address of the packet. The exception output of the LFB is a singleton output. It outputs = packets with exceptional cases. An exception ID further indicates the = exception reasons. Exception may happen when a hop selector is found = invalid, or ICMP packets need to be generated (Editorial note: more = discussions here), etc. The exception ID is also produced as a metadata = by the output to be transmitted to a downstream LFB. There are also some other components defined in the LFB for various = purposes. See section 6 for detailed XML definitions of the LFB.=20 5.3.3. IPv6UcastLPM The LFB abstracts the process for IPv6 unicast LPM table looking up.=20 Definitions of this IPv6UcastLPM LFB is very identical to IPv4UcastLPM = LFB except that all IP addresses related are changed from IPv4 addresses = to IPv6 addresses. See section 6 for detailed XML definitions of this = LFB.=20 5.3.4. IPv6NextHop This LFB abstracts the process of next hop information application to = IPv6 packets.=20 Definitions of this IPv6NextHop LFB is very identical to IPv4NextHop LFB = except that all IP addresses related are changed from IPv4 addresses to = IPv6 addresses. See section 6 for detailed XML definitions of this LFB. = 5.4. Address Resolution LFBs The address resolution LFBs abstracts the process for address resolution = functions. In the process, address resolution protocols, like ARP = protocol for IPv4 and neighbor discovery protocol for IPv6, are applied. = There exist two schema under ForCES architecture to implement address = resolution function. One is for FE to implement the address resolution = by use of address resolution LFBs as defined in this section. The other = is to offload the address resolution from FE to CE. In this case, = address resolution LFBs will not be used. All address resolution = protocol messages FE has received will be redirected to CE via ForCES = protocol [RFC5810]. CE is responsible to process the protocol messages = and generate new address resolution messages to send to outer network = via FE using ForCES prococol [RFC5810]. CE will also use ForCES protocol = to manage the address resolution tables, like the ARP table and the = neighbor table, in Ethernet encapsulator LFB.=20 According to address resolution individually for IPv4 or IPv6 packets, = an ARP LFB and an ND(neighbor discovery) LFB are defined as below. 5.4.1. ARP=20 The ARP LFB provides the function of address resolution for IPv4 nodes. = Two singleton inputs are defined for the LFB. One is for ARP protocol = packet input. The packets are usually come from upstream LFBs like an = Ethernet classifier LFB where ARP protocol messages are categorized. The = frame type hence expected is the ARP protocol message type. The other = singleton input is for IPv4 packets that usually come from Ethernet = encapsulator LFB and are unable to find L2 information to finish = encapsulation process in that LFB. The associated metadata include a = next hop IPv4 address, which is the encapsulator LFB can not find its = binding Ethernet MAC address, the logical port ID, and the VLAN ID = (Editorial note: need more discussions on what metadata these inputs = should expect.) There are two components defined in the ARP LFB. One is the ARP table. = Note that ARP table in this LFB is defined as an alias component of ARP = table in Ethernet encapsulator LFB. This means management of the ARP = table will be shared by both of the LFBs. The ARP LFB will manage the = table and refresh the table entries based on the ARP protocol messages = received. The protocol messages provide bindings of IPv4 addresses with = destination MAC addresses. The ARP table fields include destination IP = address, logical port ID, source MAC address, and destination MAC = address (Editorial note: need more discussions on what fields needed). Another component defined is the local IPv4 address table for all ports = of the FE. An FE port here is indexed by a logical port ID. Note that = every physical port may be capable of multiple logical ports with = multiple IP or MAC addresses.=20 The port IPv4 address table provides binding of a logical port to an IP = address and a MAC address (Editorial note: is it possible one logical = port binds multiple IP addresses?). The table will be used by the ARP = LFB to check locality of arrived ARP protocol messages. Usually the = table will be configured by CE via ForCES protocol.(Editorial note: need = more discussions on what fields the port IP address table needs and how = the logical port ID and MAC address take effect in the process)=20 Two singleton outputs are defined for the ARP LFB. One is for ARP = protocol message output. All ARP request and response packets are sent = out from here to downstream LFB, which usually is Ethernet encapsulation = LFB.=20 Another output is for sending all packets that are input to this LFB = because they can not find L2 encapsulation information when doing = encapsulation in an Ethernet encapsulation LFB. They are just sent back = to the LFB for encapsulation again with the expected refreshed ARP table = contents. (Editorial note: need more discussions on how the mechanism = should be defined for those packets unable to do encapsulation in = encapsulation LFB. An alternative schema is to let the ARP LFB to do = encapsulation rather than send them back to encapsulation LFB, then = output the packets directly to an LFB after the encapsulation LFB). =20 5.4.2. ND (TBD) 5.5. Redirect LFBs Redirect LFBs abstract data packets transportation process between CE = and FE. Some packets output from some LFBs may have to be delivered to = CE for further processing, and some packets generated by CE may have to = be delivered to FE and further to some specific LFBs for data path = processing. According to RFC 5810 [RFC5810], data packets and their = associated metadata are encapsulated in ForCES redirect message for = transportation between CE and FE. We define two LFBs to abstract the = process, a RedirectIn LFB and a RedirectOut LFB. Usually, in an LFB = topology of an FE, only one RedirectIn LFB instance and one RedirectOut = LFB instance exist.=20 5.5.1. RedirectIn A RedirectIn LFB abstracts the process for CE to inject data packets = into FE LFB topology so as to input data packets into FE data paths. = >From LFB topology point of view, the RedirectIn LFB acts as a source = point for data packets coming from CE, therefore the RedirectIn LFB is = defined with only one output, while without any input.=20 Output of the RedirectIn LFB is defined as a group output. Packets = produced by the output will have arbitrary frame types decided by CE = which generates the packets. Possible frames may include IPv4, IPv6, or = ARP protocol packets. CE may associate some metadata to indicate the = frame types. CE may also associate other metadata to data packets to = indicate various information on the packets. Among them, there MUST = exist a 'RedirectIndex' metadata, which is an integer acting as an = index. When CE transmits the metadata and a binging packet to a = RedirectIn LFB, the LFB will read the metadata and output the packet to = one of its group output port instance, whose port index is just as = indicated by the metadata. Detailed XML definition of the metadata is in = the XML for base type library as in Section 4.4.=20 All metadata from CE other than the 'RedirectIndex' metadata will output = from the RedirectIn LFB along with their binding packets. Note that, a = packet without a 'RedirectIndex' metadata associated will be dropped by = the LFB. There is no component defined for current version of RedirectIn LFB. = Detailed XML definitions of the LFB can be found in Section 6. 5.5.2. RedirectOut A RedirectOut LFB abstracts the process for LFBs in FE to deliver data = packets to CE. From LFB topology point of view, the RedirectOut LFB acts = as a sink point for data packets going to CE, therefore the RedirectOut = LFB is defined with only one input, while without any output.=20 Input of the RedirectOut LFB is defined as a singleton input, but it is = capable of receiving packets from multiple LFBs by multiplexing the = singleton input. Packets expected by the input will have arbitrary frame = types. All metadata associated with the input packets will be delivered = to CE via a ForCES protocol redirect message [RFC5810]. The input will = expect all types of metadata.=20 There is no component defined for current version of RedirectOut LFB. = Detailed XML definitions of the LFB can be found in Section 6. 5.6. General Purpose LFBs =20 5.6.1. BasicMetadataDispatch A basic medatata dispatch LFB is defined to abstract a process in which = a packet is dispatched to some path based on its associated metadata = value.=20 =20 The LFB is with a singleton input. Packets of arbitrary frame types can = input into the LFB. Whereas, every input packet is required to be = associated with a metadata that will be used by the LFB to do dispatch. = If a packet is not associated with such metadata, the packet will be = dropped inside the LFB. =20 A group of output is defined to output packets according to a = MetaDispatchTable as defined a component in the LFB. The table contains = the fields of a metadata ID, a metadata value, and an output port index. = A packet, if it is associated with a metadata with the metadata ID, will = be output to the group port instance with the index corresponding to the = metadata value in the table. The metadata value ussed by the table is = required with an interger data type. This means this LFB currently only = allow a metadata with an interger value to be used for dispatch.=20 =20 Moreover, the LFB is defined with only one metadata adopted for = dispatch, i.e., the metadata ID in the dispatch table is always the same = for all table rows. =20 A more complex metadata dispatch LFB may be defined in future version of = the library. In that LFB, multiple tuples of metadata may be adopted to = dispatch packets. 5.6.2. GenericScheduler=20 There exist various kinds of scheduling strategies with various = implementations. As a base LFB library, this document only defines a = preliminary generic scheduler LFB for abstracting a simple scheduling = process. The generic scheduler LFB is the one. Users may use this LFB as = a basic scheduler LFB to further construct more complex scheduler LFBs = by means of inheritance as described in RFC 5812 [RFC5812]. The LFB describes scheduling process in the following model: . It is with a group input and expects packets with arbitrary frame = types to arrive for scheduling. The group input is capable of multiple = input port instances. Each port instance may be connected to different = upstream LFB output. No metadata is expected for each input packet.=20 . Multiple queues reside at the input side, with every input port = instance connected to one queue. . Every queue is marked with a queue ID, and the queue ID is exactly the = same as the index of corresponding input port instance. . Scheduling disciplines are applied to all queues and also all packets = in the queues. . Scheduled packets are output from a singleton output port of the LFB.=20 Two LFB components are defined to further describe above model. A = scheduling discipline component is defined for CE to specify a = scheduling discipline to the LFB. Currently defined scheduling = disciplines only include FIFO and round robin(RR). For FIFO, we limit = above model that when a FIFO discipline is applied, it is require that = there is only one input port instance for the group input. If user = accidentally defines multiple input port instances for FIFO scheduling, = only packets in the input port with lowest port index will be scheduled = to output port, and all packets in other input port instances will just = ignored. We specify that if the generic scheduler LFB is defined only one input = port instance, the default scheduling discipline is FIFO. If the LFB is = defined with more than one input port instances, the default scheduling = discipline is round robin (RR). A current queue depth component is defined to allow CE to query every = queue status of the scheduler. Using the queue ID as the index, CE can = query every queue for its used length in unit of packets or bytes.=20 Several capabilities are defined for the LFB. A queue number limit is = defined which limits the scheduler maximum supported queue number, which = is also the maximum number of input port instances. Capability of = disciplines supported provides scheduling discipline types supported by = the FE to CE. Queue length limit provides the capability of storage = ability for every queue. More complex scheduler LFB may be defined with more complex scheduling = discipline by succeeding this LFB. For instance, a priority scheduler = LFB may be defined only by inheriting this LFB and define a component to = indicate priorities for all input queues.=20 See Section 6 for detailed XML definition for this LFB. ------=_NextPart_000_0054_01CC0522.139F0F80-- From hadi@mojatatu.com Wed Apr 27 06:41:14 2011 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E9A8E06DD for ; Wed, 27 Apr 2011 06:41:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.959 X-Spam-Level: X-Spam-Status: No, score=-101.959 tagged_above=-999 required=5 tests=[AWL=0.418, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pbxJbnez2PbX for ; Wed, 27 Apr 2011 06:41:10 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 19416E0792 for ; Wed, 27 Apr 2011 06:41:09 -0700 (PDT) Received: by fxm15 with SMTP id 15so1328183fxm.31 for ; Wed, 27 Apr 2011 06:41:09 -0700 (PDT) Received: by 10.223.91.79 with SMTP id l15mr2379980fam.53.1303911669097; Wed, 27 Apr 2011 06:41:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.21.16 with HTTP; Wed, 27 Apr 2011 06:40:49 -0700 (PDT) In-Reply-To: References: From: Jamal Hadi Salim Date: Wed, 27 Apr 2011 09:40:49 -0400 Message-ID: To: "Wang,Weiming" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: forces@ietf.org, Chuanhuang Li , Haleplidis Evangelos , "Joel M. Halpern" Subject: Re: [forces] Fw: LFBlib readability suggestions X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 13:41:14 -0000 Weiming, Your original message was received fine. Look at: http://www.ietf.org/mail-archive/web/forces/current/msg04003.html cheers, jamal On Wed, Apr 27, 2011 at 9:28 AM, Wang,Weiming wrot= e: > I'm fraid theres something unusal happened again with the mail system, so= post again. > > thanks, > Weiming > > ----- Original Message ----- > From: "Wang,Weiming" > To: "Chuanhuang Li" ; "Haleplidis Evange= los" ; > Cc: "'Joel M. Halpern'" ; "'wmwang'" > Sent: Wednesday, April 27, 2011 1:33 PM > Subject: Re: [forces] LFBlib readability suggestions > > >> Hi =A0Evangelos and Jamal, >> >> There are several changes since 03 version on the LFB description sectio= n. Attached is the latest text that I'v been maintaining. Pls use this text= as your base text to make =A0the modification. >> >> I'l incorparate every LFB description text since it has been made consen= sus by the list. >> >> Another suggestion is, Evangelos, pls make a title with the LFB name for= every text modification so that we can trace the discussions easily. >> >> thanks a lot. >> Weiming >> >> ----- Original Message ----- >> From: "Chuanhuang Li" >> >>> Hi, Evangelos >>> >>> =A0 =A0When you are reorganizing the draft content, and if there is con= tradiction between >>> text and the latest XML which i had post on list before, please use the= XML as guidance. >>> This is because after draft-03, we had discussed some contents and reac= hed some consensuses. >>> And I think maybe Weiming has the latest draft contents text. >>> Thanks! >>> >>> Yours, >>> Chuanhuang >>> >>> =3D=3D=3D=3D=3D=3D=3D 2011-04-27 04:58:08 Haleplidis Evangelos, wrote: = =3D=3D=3D=3D=3D=3D=3D >>> >>>>Greetings to all, >>>> >>>>After Jamal's suggestion I took his initiative and completed the etherp= hycop >>>>definition. >>>> >>>>Please take a look and comment, in the meantime I'll start working on t= he >>>>EtherMacIn. >>>> >>>>About Jamal's comments: >>>> >>>>XXX: It may make sense to have each of Components, Capabilities and Eve= nts >>>>on its own section? >>>> >>>>I think it is more readable this way and also following the same format= as >>>>the model RFC provides consistency. >>>> >>>>XXX: I copied this from the draft but i think it may be wrong. The xml = says >>>>this component is read-only. And i remember we had a very long discussi= on >>>>(refer to how one would map a port name to the PHY on how this ID is to= be >>>>used). >>>> >>>>Well, even the text says that: " is defined so the CE can assign an ID = ". >>>>Since the CE can assign the ID then it must be read-write. I think we s= hould >>>>change it in the XML. >>>> >>>>XXX: Should we be discussing all the components, capabilities and event= s? >>>>i.e why the brief description below? Either that or the XML synopsis ne= eds >>>>to be a lot more descriptive. >>>> >>>>I think we should be discussing ALL components/capabilities/events. >>>>It's more readable this way. Someone not familiar with xml may want to = read >>>>and understand in this way of reading instead of looking around in the = xml. >>>> >>>>Also there is a typo in the xml definition of the EtherPhyCop. In the >>>>synopsis of the DuplexModeChanged there is a "speed." in the end that i= s not >>>>supposed to be there. >>>> >>>>Regards, >>>>Evangelos Haleplidis. >>>> >>>>> -----Original Message----- >>>>> From: forces-bounces@ietf.org [mailto:forces-bounces@ietf.org] On >>>>> Behalf Of Jamal Hadi Salim >>>>> Sent: Tuesday, April 26, 2011 2:01 PM >>>>> To: forces@ietf.org >>>>> Cc: Chuanhuang Li; wmwang; Joel M. Halpern >>>>> Subject: [forces] LFBlib readability suggestions >>>>> >>>>> to the authors, >>>>> >>>>> As i have whined before, the general draft text is hard to read. >>>>> I think making things a little more formal as in the example LFB in R= FC >>>>> 5812 section 8 will go a long way to improve readability. >>>>> >>>>> I have attempted to redo the EtherPHYCop section, I didnt go 100% wit= h >>>>> the RFC5812 format but please take a look in particular the "XXX" >>>>> and cross reference with: >>>>> - the text that exists right now in the draft >>>>> - the xml (and also to make sure it is well described) >>>>> - the formal scheme to describe things as i laid it out. The model >>>>> draft LFB example in section 8 is a good start. >>>>> >>>>> cheers, >>>>> jamal >>>> >>> >>> >>> _______________________________________________ >>> 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 wmwang2001@hotmail.com Wed Apr 27 07:19:45 2011 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF47E0670 for ; Wed, 27 Apr 2011 07:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.654 X-Spam-Level: X-Spam-Status: No, score=0.654 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nx99B5Smjhf8 for ; Wed, 27 Apr 2011 07:19:41 -0700 (PDT) Received: from blu0-omc2-s5.blu0.hotmail.com (blu0-omc2-s5.blu0.hotmail.com [65.55.111.80]) by ietfa.amsl.com (Postfix) with ESMTP id 1648CE069F for ; Wed, 27 Apr 2011 07:19:41 -0700 (PDT) Received: from BLU0-SMTP136 ([65.55.111.71]) by blu0-omc2-s5.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Apr 2011 07:19:40 -0700 X-Originating-IP: [220.184.223.53] X-Originating-Email: [wmwang2001@hotmail.com] Message-ID: Received: from WmwangHome ([220.184.223.53]) by BLU0-SMTP136.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Apr 2011 07:19:38 -0700 From: "Wang,Weiming" To: "Jamal Hadi Salim" , "Haleplidis Evangelos" References: <000901cc0455$c207e3d0$4617ab70$@upatras.gr> Date: Wed, 27 Apr 2011 22:18:24 +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.6090 X-OriginalArrivalTime: 27 Apr 2011 14:19:39.0760 (UTC) FILETIME=[250E8700:01CC04E6] Cc: forces@ietf.org, Chuanhuang Li , wmwang , "Joel M. Halpern" Subject: Re: [forces] LFBlib readability suggestions X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 14:19:45 -0000 SGkgSmFtYWwgYW5kIEV2YW5nZWxvcywNCg0KSSBoYXZlIHNvbWUgbW9yZSB0aG91Z2h0cyB0byBz aGFyZSB3aXRoIHlvdSBvbiB0aGUgTEZCIGRlc2NyaXB0aW9uIHRleHQuIA0KDQpBY3R1YWxseSBJ IGFsc28gdGhpbmsgaXQgaXMgbWFkZSBlYXNpZXIgdG8gcmVhZGVyIGJ5IHN1Yi1zZWN0aW9ucyBh Y2NvcmRpbmcgdG8gdGhlIExGQiBpbmRpdmlkdWFsIHByb3BlcnRpZXMuIEluIGZhY3QgSSB0aG91 Z2h0IHRvIGRvIGxpa2UgdGhpcyBhdCBiZWdpbm5pbmcuIEkgZXZlbiB0aG91Z2h0IG9mIHR3byBv dGhlciB3YXlzIGxpa2UgMSkgd2l0aCBhIHBpY3R1cmUgdG8gc2hvdyB0aGUgaW5wdXRzIGFuZCBv dXRwdXRzLiAyKSB3aXRoIHRoZSBvdXRsaW5lIGFzIHdlIHdlcmUgZGlzY3Vzc2luZyB0aGUgTEZC IGRpZmluaXRpb25zIGFtb25nIGF1dGhvcnMgYXQgdGhlIHZlcnkgYmVnaW5uaW5nLiBUaGUgb3V0 bGluZSBjYW4gYmUgcHV0IGF0IHRoZSBMRkIgZGVzY3JpcHRpb24gc3RhcnQgcGxhY2UuICBJIGVz cGVjaWFsbHkgbGlrZSB0aGlzIGZvcm1hdCwgYmVjYXVzZSBpdCBjYW4gcHJvdmlkZSB2ZXJ5IGNs ZWFyIG92ZXJ2aWV3IG9mIGFsbCB0aGUgTEZCIGRlZmluaXRpb24gZW50aXRpZXMuIEZvciBpbnNu dGFjZSwgZm9yIHRoZSBFdGhlclBIWUNvcCBMRkIsIHRoZSBvcmlnaW5hbCBvdXRsaW5lIGlzIGxp a2UgdGhlIGZvcm1hdCBhcyAgYmVsb3cuIA0KLS0tLQ0KSW5wdXRzOg0KRXRoZXJQSFlJbiwgIHNp bmdsZSBpbnB1dA0KZnJhbWVFeHBlY3RlZDogRXRoZXJuZXRBbGwgLyphbiBldGhlcm5ldCBmcmFt ZSBkZXNjcmlwdGlvbiB0aGF0IGluY2x1ZGVzIGFsbCBraW5kcyBvZiBldGhlcm5ldCBmcmFtZSB0 eXBlcyAqLw0KbWV0YWRhdGFFeHBlY3RlZDogbm9uZSAgDQogDQpPdXRwdXRzOg0KRXRoZXJQSFlP dXQsICBzaW5nbGUgb3V0cHV0DQpmcmFtZVByb2R1Y2VkOiBFdGhlcm5ldElJIA0KbWV0YWRhdGFQ cm9kdWNlZDogUEhZUG9ydElEDQotLS0tDQpDb21wb25lbnRzOg0KKGRlZmF1bHQgYWNjZXNzIHBy b3BlcnR5IGlzIHJlYWQtd3JpdGUpDQoNCm5hbWU6IFBIWVBvcnRJRA0KdHlwZTogdWludDMyDQoN Cm5hbWU6IEFkbWluTGlua1NwZWVkIA0KdHlwZTpMQU5TcGVlZFR5cGUgICAvKmluY2x1ZGUgImF1 dG8iIGFzIHRoZSB0eXBlIHZhbHVlICovDQpkZWZhdWx0VmFsdWU6ImF1dG8iDQoNCm5hbWU6IE9w ZXJMaW5rU3BlZWQgDQp0eXBlOkxBTlNwZWVkVHlwZSANCmFjY2VzczogcmVhZC1vbmx5DQoNCm5h bWU6IEFkbWluRHVwbGV4TW9kZQ0KdHlwZTpEdXBsZXhUeXBlDQpkZWZhdWx0VmFsdWU6ImF1dG8i DQoNCm5hbWU6IE9wZXJEdXBsZXhNb2RlIA0KdHlwZTpEdXBsZXhUeXBlIA0KYWNjZXNzOiByZWFk LW9ubHkNCg0KbmFtZTogQWRtaW5TdGF0dXMNCnR5cGU6UG9ydFN0YXR1c1ZhbHVlcw0KZGVmYXVs dFZhbHVlOiJkb3duIg0KDQpuYW1lOiBDYXJyaWVyU3RhdHVzDQp0eXBlOmJvb2xlYW5UeXBlDQph Y2Nlc3M6cmVhZC1vbmx5DQpkZWZhdWx0VmFsdWU6Im5vIg0KDQpuYW1lOiBQSFlQb3J0U3RhdHMN CnR5cGU6IFBIWVBvcnRTdGF0c1R5cGUgLypwbGVhc2UgY29tbWVudCB0aGF0IGlmIGl0IGlzIG5l ZWRlZCBhbmQgaWYgaXMsIHdoYXQgc3RhdHMgbWF5IGluY2x1ZGU/Ki8NCmFjY2VzczogcmVhZC1y ZXNldA0KLS0tLQ0KQ2FwYWJpbGl0aWVzOiANCg0KbmFtZTogU3VwcG9ydGVkTGlua1NwZWVkDQp0 eXBlOiBhcnJheSBvZiBMQU5TcGVlZFR5cGVzDQoNCm5hbWU6IFN1cHBvcnRlZER1cGxleE1vZGUN CnR5cGU6IGFycmF5IG9mIER1cGxleFR5cGVzDQotLS0tDQpFdmVudHM6DQoNCm5hbWU6IFBIWVBv cnRTdGF0dXNDaGFuZ2VkDQoNCm5hbWU6IExpbmtTcGVlZENoYW5nZWQNCi0tLS0NCg0KV2hlcmVh cywgaW4gdGhlIGVuZCwgSSBnYXZlIHVwIGFib3ZlIHRob2d1dHMgYmVjYXVzZSBJIGhhdmUgYSB0 aG91Z2h0IHRoYXQgdGhlICJMRkIgZGVzY3JpcHRpb24iIGlzIG5vdCBhIHRleHQgZm9yIGVhc3kg cmVhZGFiaWxpdHkgcHVycG9zZSwgcmF0aGVyIGl0IGlzIGZvciB0aGUgZGVmaW5pdGlvbnMgb2Yg dGhlIExGQiBpdHNlbGYuIFRvIHNheSB0aGlzLCBpdCBpcyB0byBzYXkgdGhlIExGQiBkZXNjcmlw dGlvbiBzaG91bGQgYXZvaWQgYXMgbXVjaCBhcyBwb3NzaWJsZSBkdXBsaWNhdGlvbnMgb2YgIGRl ZmluaXRpb25zIGZvciB0aGUgTEZCIGFtb25nIHRoZSBkZXNjcmlwdGlvbiBhbmQgdGhlIFhNTCBm aWxlIGRlZmluaXRpb25zLiBXaXRoIHRoaXMgaW4gbWluZCwgdGhlIGN1cnJlbnQgZHJhZnQgb25s eSBkZWFscyB3aXRoIHRoZSBMRkIgZGVzY3JpcHRpb25zIHRoYXQgbW9zdGx5IG5lZWQgbW9yZSBk ZWZpbml0aW9ucyB3aXRoIHRoZSBoZWxwIG9mIHRoZSB0ZXh0LiBXaGlsZSBmb3IgIHNvbWUgdmVy eSBvYnZpb3VzIGRlZmluaXRpb25zIGxpa2UgZm9yICBzb21lIGNhcGFiaWxpdGllcyBvciBldmVu dHMsIHRoZXkgYXJlIGp1c3QgZGVmaW5lZCBpbiB0aGUgWE1MIGZpbGUuIA0KDQpJIGp1c3QgdGhv dWdodCB0aGF0IHJlYWRlcnMgYXJlIGV4cGVjdGVkIHRvIHVuZGVyc3RhbmQgdGhlIExGQiBkZWZp bml0aW9ucyBtYWlubHkgYnkgcmVhZGluZyB0aGUgWE1MIGZpbGUgYW5kIHdpdGggc3lub3BzaXMg aGVscHMuIEkgbmV2ZXIgZXhwZWN0ZWQgcmVhZGVycyB0byB1bmRlcnN0YW5kIHRoZSBkZWZpbml0 aW9ucyBieSB0aGUgZGVzY2lwdGlvbi4gSnVzdCBsaWtlIHdoZW4gd2UgcGFyc2UgYSBzb2Z0d2Fy ZSBjb2RlLCB3ZSBtYXkgbm90IGV4cGVjdCB0aGUgcHJvZ3JhbW1lciB0byBwcm92aWRlIGEgbWFu dWFsIGFzIHdlbGwgYXMgdGhlIHNvdXJjZSBjb2RlLiANCg0KQnV0LCBhbnl3YXksIEkgYWdyZWUg dG8gdXNlIHRoZSBuZXcgZm9ybWF0IGZvciB0aGUgZGVzY3JpcHRpb24gb2YgdGhlIExGQnMgaWYg eW91IGFsbCBhZ3JlZS4NCg0KdGhhbmtzLA0KV2VpbWluZw0KDQotLS0tLSBPcmlnaW5hbCBNZXNz YWdlIC0tLS0tIA0KRnJvbTogIkphbWFsIEhhZGkgU2FsaW0iIDxoYWRpQG1vamF0YXR1LmNvbT4N Cg0KPiBHcmVldGluZ3MgRXZhbmdlbG9zLA0KPiANCj4gTG9va3MgdmVyeSBuaWNlIQ0KPiBOb3cg aWYgd2UgY291bGQgZG8gYWxsIHRoZSBMRkJzIGxpa2UgdGhhdCwgdGhlIGRvY3VtZW50IHJlYWRh YmlsaXR5DQo+IHdvdWxkIGltcHJvdmUgZ3JlYXRseSENCj4gDQo+IE1vcmUgY29tbWVudHMgaW5s aW5lZC4NCj4gDQo+IE9uIFR1ZSwgQXByIDI2LCAyMDExIGF0IDU6MDYgUE0sIEhhbGVwbGlkaXMg RXZhbmdlbG9zDQo+IDxlaGFsZXBAZWNlLnVwYXRyYXMuZ3I+IHdyb3RlOg0KPj4gR3JlZXRpbmdz IHRvIGFsbCwNCj4+DQo+PiBBZnRlciBKYW1hbCdzIHN1Z2dlc3Rpb24gSSB0b29rIGhpcyBpbml0 aWF0aXZlIGFuZCBjb21wbGV0ZWQgdGhlIGV0aGVycGh5Y29wDQo+PiBkZWZpbml0aW9uLg0KPj4N Cj4+IFBsZWFzZSB0YWtlIGEgbG9vayBhbmQgY29tbWVudCwgaW4gdGhlIG1lYW50aW1lIEknbGwg c3RhcnQgd29ya2luZyBvbiB0aGUNCj4+IEV0aGVyTWFjSW4uDQo+Pg0KPj4gQWJvdXQgSmFtYWwn cyBjb21tZW50czoNCj4+DQo+PiBYWFg6IEl0IG1heSBtYWtlIHNlbnNlIHRvIGhhdmUgZWFjaCBv ZiBDb21wb25lbnRzLCBDYXBhYmlsaXRpZXMgYW5kIEV2ZW50cw0KPj4gb24gaXRzIG93biBzZWN0 aW9uPw0KPj4NCj4+IEkgdGhpbmsgaXQgaXMgbW9yZSByZWFkYWJsZSB0aGlzIHdheSBhbmQgYWxz byBmb2xsb3dpbmcgdGhlIHNhbWUgZm9ybWF0IGFzDQo+PiB0aGUgbW9kZWwgUkZDIHByb3ZpZGVz IGNvbnNpc3RlbmN5Lg0KPj4NCj4gDQo+IEZpbmUgd2l0aCBtZTstPg0KPiANCj4+IFhYWDogSSBj b3BpZWQgdGhpcyBmcm9tIHRoZSBkcmFmdCBidXQgaSB0aGluayBpdCBtYXkgYmUgd3JvbmcuIFRo ZSB4bWwgc2F5cw0KPj4gdGhpcyBjb21wb25lbnQgaXMgcmVhZC1vbmx5LiBBbmQgaSByZW1lbWJl ciB3ZSBoYWQgYSB2ZXJ5IGxvbmcgZGlzY3Vzc2lvbg0KPj4gKHJlZmVyIHRvIGhvdyBvbmUgd291 bGQgbWFwIGEgcG9ydCBuYW1lIHRvIHRoZSBQSFkgb24gaG93IHRoaXMgSUQgaXMgdG8gYmUNCj4+ IHVzZWQpLg0KPj4NCj4+IFdlbGwsIGV2ZW4gdGhlIHRleHQgc2F5cyB0aGF0OiAiIGlzIGRlZmlu ZWQgc28gdGhlIENFIGNhbiBhc3NpZ24gYW4gSUQgIi4NCj4+IFNpbmNlIHRoZSBDRSBjYW4gYXNz aWduIHRoZSBJRCB0aGVuIGl0IG11c3QgYmUgcmVhZC13cml0ZS4gSSB0aGluayB3ZSBzaG91bGQN Cj4+IGNoYW5nZSBpdCBpbiB0aGUgWE1MLg0KPj4NCj4gDQo+IEkgdGhpbmsgdGhlIENFIGNhbm5v dCBhc3NpZ24gYW4gSUQgLSB0aGUgRkUgY29tZXMgdXAgd2l0aCBpdC4gVGhlDQo+IHRleHQgY29u dHJhZGljdHMgdGhlIFhNTCAoYXMgaSB3YXMgcG9pbnRpbmcgb3V0KS4NCj4gDQo+PiBYWFg6IFNo b3VsZCB3ZSBiZSBkaXNjdXNzaW5nIGFsbCB0aGUgY29tcG9uZW50cywgY2FwYWJpbGl0aWVzIGFu ZCBldmVudHM/DQo+PiBpLmUgd2h5IHRoZSBicmllZiBkZXNjcmlwdGlvbiBiZWxvdz8gRWl0aGVy IHRoYXQgb3IgdGhlIFhNTCBzeW5vcHNpcyBuZWVkcw0KPj4gdG8gYmUgYSBsb3QgbW9yZSBkZXNj cmlwdGl2ZS4NCj4+DQo+PiBJIHRoaW5rIHdlIHNob3VsZCBiZSBkaXNjdXNzaW5nIEFMTCBjb21w b25lbnRzL2NhcGFiaWxpdGllcy9ldmVudHMuDQo+PiBJdCdzIG1vcmUgcmVhZGFibGUgdGhpcyB3 YXkuIFNvbWVvbmUgbm90IGZhbWlsaWFyIHdpdGggeG1sIG1heSB3YW50IHRvIHJlYWQNCj4+IGFu ZCB1bmRlcnN0YW5kIGluIHRoaXMgd2F5IG9mIHJlYWRpbmcgaW5zdGVhZCBvZiBsb29raW5nIGFy b3VuZCBpbiB0aGUgeG1sLg0KPj4NCj4gDQo+IExpa2UgIGkgc2FpZCBhYm92ZSwgSSBhbSBmaW5l IHdpdGggdGhhdCBhcHByb2FjaCwNCj4gDQo+PiBBbHNvIHRoZXJlIGlzIGEgdHlwbyBpbiB0aGUg eG1sIGRlZmluaXRpb24gb2YgdGhlIEV0aGVyUGh5Q29wLiBJbiB0aGUNCj4+IHN5bm9wc2lzIG9m IHRoZSBEdXBsZXhNb2RlQ2hhbmdlZCB0aGVyZSBpcyBhICJzcGVlZC4iIGluIHRoZSBlbmQgdGhh dCBpcyBub3QNCj4+IHN1cHBvc2VkIHRvIGJlIHRoZXJlLg0KPj4NCj4gDQo+IEkgZGlkbnQgY2F0 Y2ggdGhhdCBvbmUsIGJ1dCB5b3UgYXJlIHJpZ2h0Lg0KPiANCj4gVGhhbmtzIGZvciB0aGUgZWZm b3J0IEV2YW5nZWxvcy4NCj4gDQo+IGNoZWVycywNCj4gamFtYWwNCj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gZm9yY2VzIG1haWxpbmcgbGlzdA0K PiBmb3JjZXNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9mb3JjZXMNCj4= From hadi@mojatatu.com Wed Apr 27 08:33:08 2011 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF45AE07B4 for ; Wed, 27 Apr 2011 08:33:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.985 X-Spam-Level: X-Spam-Status: No, score=-101.985 tagged_above=-999 required=5 tests=[AWL=0.392, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D+j-vd0biOzB for ; Wed, 27 Apr 2011 08:33:07 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id A1669E0751 for ; Wed, 27 Apr 2011 08:33:07 -0700 (PDT) Received: by fxm15 with SMTP id 15so1419626fxm.31 for ; Wed, 27 Apr 2011 08:33:06 -0700 (PDT) Received: by 10.223.101.72 with SMTP id b8mr586117fao.15.1303918386557; Wed, 27 Apr 2011 08:33:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.21.16 with HTTP; Wed, 27 Apr 2011 08:30:21 -0700 (PDT) In-Reply-To: References: <000901cc0455$c207e3d0$4617ab70$@upatras.gr> From: Jamal Hadi Salim Date: Wed, 27 Apr 2011 11:30:21 -0400 Message-ID: To: "Wang,Weiming" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: forces@ietf.org, Chuanhuang Li , wmwang , Haleplidis Evangelos , "Joel M. Halpern" Subject: Re: [forces] LFBlib readability suggestions X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 15:33:08 -0000 On Wed, Apr 27, 2011 at 10:18 AM, Wang,Weiming wro= te: > Hi Jamal and Evangelos, > > I have some more thoughts to share with you on the LFB description text. > > Actually I also think it is made easier to reader by sub-sections accordi= ng to the LFB >individual properties. In fact I thought to do like this at = beginning. I even thought of >two other ways like 1) with a picture to show= the inputs and outputs. 2) with the >outline as we were discussing the LFB= difinitions among authors at the very >beginning. The outline can be put a= t the LFB description start place. =A0I especially like >this format, becau= se it can provide very clear overview of all the LFB definition >entities. = For insntace, for the EtherPHYCop LFB, the original outline is like the >fo= rmat as =A0below. I think the document will grow in a big way if you went this way. It is true this will be more formal - but you dont need to be 100% formal, you leave that to the xml. Look at chapter 8 in the Model RFC. >Whereas, in the end, I gave up above thoguts because I have a thought that= the >"LFB description" is not a text for easy readability purpose, rather = it is for the >definitions of the LFB itself. To say this, it is to say the= LFB description should avoid >as much as possible duplications of =A0defin= itions for the LFB among the description >and the XML file definitions. Wit= h this in mind, the current draft only deals with the >LFB descriptions tha= t mostly need more definitions with the help of the text. While >for =A0som= e very obvious definitions like for =A0some capabilities or events, they ar= e just >defined in the XML file. > > I just thought that readers are expected to understand the LFB definition= s mainly by >reading the XML file and with synopsis helps. I never expected= readers to understand >the definitions by the desciption. Just like when w= e parse a software code, we may >not expect the programmer to provide a man= ual as well as the source code. > It is tough balance. I agree with you thinking but from experience the curr= ent structuring is not working well. About everybody i had look at the document found it very hard to follow. I had to print the xml and when i was reading the document i cross reference. > But, anyway, I agree to use the new format for the description of the LFB= s if >you all agree. I will leave it upto the authors to make the final decision. I feel i will = be shepherding this document at the end - hence my efforts are purely selfish to make this readable by the reviewers so we dont waste time at that stage (it could be very consuming and frustrating). cheers, jamal From jmh@joelhalpern.com Wed Apr 27 09:42:51 2011 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCC3BE084A for ; Wed, 27 Apr 2011 09:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.712 X-Spam-Level: X-Spam-Status: No, score=-102.712 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eO-jJCShdsiP for ; Wed, 27 Apr 2011 09:42:51 -0700 (PDT) Received: from hgblob.out.tigertech.net (hgblob.out.tigertech.net [74.114.88.71]) by ietfa.amsl.com (Postfix) with ESMTP id 40770E06C9 for ; Wed, 27 Apr 2011 09:42:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 2F12A325B2B2; Wed, 27 Apr 2011 09:42:51 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-218.clppva.btas.verizon.net [71.161.51.218]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 277CD324683B; Wed, 27 Apr 2011 09:42:50 -0700 (PDT) Message-ID: <4DB84789.2060003@joelhalpern.com> Date: Wed, 27 Apr 2011 12:42:49 -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: "Wang,Weiming" References: <000901cc0455$c207e3d0$4617ab70$@upatras.gr> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: forces@ietf.org, Chuanhuang Li , wmwang , Haleplidis Evangelos Subject: Re: [forces] LFBlib readability suggestions X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 16:42:51 -0000 Let me try to describe the purpose of the and clauses of the XML. They are intended to be available to help a human being working with tools. Imagine either a tool that is helping a programmer build CE logic, or a tool that is displaying the results of extracting the LFB structure of an FE. The synopsis would appear in a tooltip. The description would appear if someone asked for help about the LFB class. Neither of those is supposed to be as extensive as the actual textual description in teh RFC< which provides all of the context, options, consideration, design issues, etc... Yours, Joel From chuanhuang_li@mail.zjgsu.edu.cn Fri Apr 29 03:53:02 2011 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82069E06AC for ; Fri, 29 Apr 2011 03:53:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.245 X-Spam-Level: X-Spam-Status: No, score=-0.245 tagged_above=-999 required=5 tests=[AWL=-0.246, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SuatMfwSOSHx for ; Fri, 29 Apr 2011 03:53:02 -0700 (PDT) Received: from mail.zjgsu.edu.cn (ucmail.zjgsu.edu.cn [124.160.64.1]) by ietfa.amsl.com (Postfix) with SMTP id 625E8E062A for ; Fri, 29 Apr 2011 03:52:59 -0700 (PDT) Received: from RobinLee (unknown [10.20.0.167]) by mailportal (Coremail) with SMTP id rBCI85D74TLylbpNgIQeAA--.35601S2; Fri, 29 Apr 2011 18:41:55 +0800 (CST) Date: Fri, 29 Apr 2011 18:50:52 +0800 From: "Chuanhuang Li" To: "Joel M. Halpern" , "Wang,Weiming" References: <000901cc0455$c207e3d0$4617ab70$@upatras.gr>, , Message-ID: <201104291850519504328@mail.zjgsu.edu.cn> Organization: Zhejiang Gongshang Univercity X-mailer: Foxmail 6, 15, 201, 23 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-CM-TRANSID: rBCI85D74TLylbpNgIQeAA--.35601S2 X-Coremail-Antispam: 1Uf129KBjDUn29KB7ZKAUJUUUUUYxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJ3UbIYCTnIWIevJa73UjIFyTuYvj4RJUUUUUUUU X-CM-SenderInfo: pfkxt0xkxd0wxbolqzhdloh6pmjv3hxhgxhubq/ Cc: forces , wmwang , Haleplidis Evangelos Subject: Re: [forces] LFBlib readability suggestions X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 10:53:02 -0000 Hi, all I'm sorry for not continuing working on the lib these days, owing to feel not well with my health. I'll complete to collate the LFB XML definition according Jamal's suggestion text file and previous discussion in the following days, and will soon post it on the list. Yours, Chuanhuang ======= 2011-04-28 00:34:49 Joel M. Halpern, wrote: ======= >Let me try to describe the purpose of the and >clauses of the XML. >They are intended to be available to help a human being working with tools. >Imagine either a tool that is helping a programmer build CE logic, or a >tool that is displaying the results of extracting the LFB structure of >an FE. The synopsis would appear in a tooltip. The description would >appear if someone asked for help about the LFB class. > >Neither of those is supposed to be as extensive as the actual textual >description in teh RFC< which provides all of the context, options, >consideration, design issues, etc... > >Yours, >Joel >. From ehalep@ece.upatras.gr Sat Apr 30 15:36:35 2011 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE38DE062A for ; Sat, 30 Apr 2011 15:36:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6B5190wNu3cW for ; Sat, 30 Apr 2011 15:36:35 -0700 (PDT) Received: from mailgate.ece.upatras.gr (mailgate1.ece.upatras.gr [150.140.189.22]) by ietfa.amsl.com (Postfix) with ESMTP id D8FDCE0593 for ; Sat, 30 Apr 2011 15:36:34 -0700 (PDT) Received: from EhalepXPS (150.140.255.186) by mailgate1 (Axigen) with ESMTPA id 22B7C4; Sun, 1 May 2011 01:44:47 +0300 From: "Haleplidis Evangelos" To: "'forces'" References: <000901cc0455$c207e3d0$4617ab70$@upatras.gr>, , <201104291850519504328@mail.zjgsu.edu.cn> In-Reply-To: <201104291850519504328@mail.zjgsu.edu.cn> Date: Sun, 1 May 2011 01:36:29 +0300 Message-ID: <004c01cc0787$0ce95760$26bc0620$@upatras.gr> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_004D_01CC07A0.3236B670" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcwGXLwhDn2hxopaR6W+T9+qo1iGawBKeYaw Content-Language: el Cc: "'Joel M. Halpern'" , 'Chuanhuang Li' , 'wmwang' Subject: [forces] EtherMACIn - LFBlib readability suggestions X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Apr 2011 22:36:35 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_004D_01CC07A0.3236B670 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Greetings to all, Here is the readability suggestion for the EtherMacIn. I hope I have more within the week. Regards, Evangelos Haleplidis. ------=_NextPart_000_004D_01CC07A0.3236B670 Content-Type: text/plain; name="section5-ethermacin-final.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="section5-ethermacin-final.txt" =0A= 5.1.1. EtherMacIn=0A= =0A= EtherMACIn LFB abstracts an Ethernet port at MAC data link layer.=0A= =0A= 5.1.1.1. Data Handling=0A= =0A= This LFB describes Ethernet processing functions like MAC address=0A= locality check, deciding if the Ethernet packets should be bridged,=0A= provide Ethernet layer flow control, etc.=0A= =0A= The LFB is expected to receive all types of Ethernet packets, via a =0A= singleton input known as "EtherMACIn", which are usually output from=0A= some Ethernet physical abstraction layer LFB, like an EtherPHYCop =0A= LFB, alongside with a metadatum indicating the physical port ID that=0A= the packet comes.=0A= =0A= The LFB is defined with two separate singleton outputs. All Output=0A= packets are in Ethernet format, as received from the physical = abstraction=0A= layer LFB and cover all types of Ethernet packets.=0A= =0A= The first singleton output is known as "NormalPathOut". It usually = outputs=0A= Ethernet packets to some LFB like an EtherClassifier LFB for further = L3=0A= forwarding process alongside with a PHYPortID metadata indicating = which =0A= physical port the packet came from.=0A= =0A= The second singleton output is known as "L2BridgingPathOut". Although = this=0A= LFB library is basically defined to meet typical router functions, it = will =0A= attempt to be forward compatible with future router functions. The=0A= "L2BridgingPathOut" is defined to meet the requirement that L2 = bridging=0A= functions may be optionally supported simultaneously with L3 = processing and=0A= some L2 bridging LFBs that may be defined in the future. If the FE = supports=0A= L2 bridging, the CE can enable or disable it. If it is enabled, by = also =0A= instantiating some L2 bridging LFB instances following the = L2BridgingPathOut, =0A= FEs are expected to fulfill L2 bridging functions. L2BridgingPathOut = will output=0A= packets exactly the same as that in the NormalPathOut output = (Editorial note: =0A= need more discussions here on if the L2 output is the same as normal = output).=0A= =0A= This LFB can be set to work in a Promiscuous Mode, allowing all = packets=0A= to pass through the LFB without being dropped. Eitherwise a locallity =0A= check will be performed based on the local MAC address. All packets = that=0A= do not pass through the locality check will be dropped.=0A= =0A= This LFB can perform Ethernet layer flow control. This is usually =0A= implemented cooperatively by the EtherMACIn LFB and the EtherMACOut = LFB.=0A= The flow control is further distinguished by Tx flow control and Rx = flow=0A= control, separately for sending process and receiving process flow=0A= control. =0A= =0A= 5.1.1.2. Components=0A= =0A= The AdminStatus component is defined for CE to administratively = manage =0A= the status of the LFB. The CE may adminstratively startup or shutdown =0A= the LFB by changing the value of AdminStatus. The default value is =0A= set to 'Down'.=0A= =0A= The LocalMACAddresses component specifies the local MAC addresses = based =0A= on which locality checks will be made. This component is an array of = MAC=0A= addresses.=0A= =0A= An L2BridgingPathEnable component captures whether the LFB is set to=0A= work as a L2 Brigde. An FE that does not support bridging will = internally =0A= set this flag to false, and additionally sets the flag property as =0A= read-only. The default value for is 'false'.=0A= =0A= The PromiscuousMode component specifies whether the LFB is set to=0A= work as in a promiscuous mode. The default value for is 'false'.=0A= =0A= The TxFlowControl component defines whether the LFB is performing = flow =0A= control on sending packets. The default value for is 'false'.=0A= =0A= The RxFlowControl component defines whether the LFB is performing flow=0A= contron on receiving packets. The default value for is 'false'. =0A= =0A= A struct component, MACInStats, defines a set of statistics for this = LFB,=0A= including the number of received packets and the number of dropped = packets. =0A= =0A= 5.1.1.3. Capabilities=0A= =0A= This LFB does not have a list of capabilities. =0A= =0A= 5.1.1.4. Events=0A= =0A= This LFB does not have any events specified. ------=_NextPart_000_004D_01CC07A0.3236B670--